US20060235758A1 - Authorization techniques - Google Patents

Authorization techniques Download PDF

Info

Publication number
US20060235758A1
US20060235758A1 US11102056 US10205605A US2006235758A1 US 20060235758 A1 US20060235758 A1 US 20060235758A1 US 11102056 US11102056 US 11102056 US 10205605 A US10205605 A US 10205605A US 2006235758 A1 US2006235758 A1 US 2006235758A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
authorization
settlement
merchant
service
buyer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11102056
Inventor
Joerg Schleicher
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PayPal Inc
Original Assignee
PayPal Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/227Payment schemes or models characterized in that multiple accounts are available to the payer
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/381Currency conversion
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403Solvency checks
    • G06Q20/4037Remote solvency checks
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce, e.g. shopping or e-commerce
    • G06Q30/02Marketing, e.g. market research and analysis, surveying, promotions, advertising, buyer profiling, customer management or rewards; Price estimation or determination
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce, e.g. shopping or e-commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Exchange, e.g. stocks, commodities, derivatives or currency exchange

Abstract

Authorization techniques are presented. A merchant and buyer interact with an authorization and settlement service. Multiple funding sources associated with the buyer are used to authorize a single transaction between the merchant and the buyer. The authorization and settlement service honors the authorization on behalf of the merchant for a configurable period of time. During this period of time, the merchant may completely or partially settle with the buyer via the network-based authorization and settlement service.

Description

    FIELD
  • [0001]
    The invention relates generally to transaction processing and more particularly to techniques for automated and real-time authorization processing.
  • BACKGROUND
  • [0002]
    Buyers and merchants are increasingly engaging in real-time and dynamic electronic transactions over the Internet and the World-Wide Web (WWW). A typical buyer can have a variety of different funding sources for any given on-line transaction, such as a checking account, a credit card, a debit card, a gift certificate, etc. A merchant wants to seamlessly accept and to process any form of funding source which is associated with the buyer, because this provides flexibility to the buyer and increases the likelihood that the buyer will purchase a good or service from the merchant.
  • [0003]
    However, the capability associated with accepting a variety of funding sources may be beyond the technical means of the merchant. Additionally, business risks associated with attempting to accept certain types of funding sources may be too high for a particular merchant.
  • [0004]
    For example, during an on-line transaction a buyer may request a good (product) from a merchant; the merchant may not acquire payment from the buyer until the ordered good actually ships to the buyer. During the intervening period between the order and the shipment, the merchant may want some assurances that the buyer is going to be able to perform (e.g., pay for the product when shipment occurs). This assurance is generally achieved via an authorization process where funds of a buyer are locked from being used for other purposes but where the funds are not actually withdrawn from the buyer's funding source. However, some types of funding sources do not support the locking of funds for a typical authorization transaction (such as checking accounts or automated clearing house (ACH) accounts; funding source that are not credit cards, etc.). Thus, a merchant takes a risk by accepting some types of funding sources (e.g., electronic checks, ACH, etc.), such that the merchant's product may ship to buyer but that buyer may not be capable of performing (paying).
  • [0005]
    Generally, merchants are skilled in supplying their goods or services to buyers. The more merchants attempt to finance transactions or accommodate financing arrangements, the more merchants divert resources away from their core competencies.
  • SUMMARY
  • [0006]
    In an embodiment, an on-line transaction for an amount is received from a merchant. The amount is authorized against one or more funding sources. A confirmation is sent to the merchant if the authorization was successful.
  • [0007]
    Other features will be apparent from the accompanying drawings and from the detailed description that follows.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0008]
    Embodiments of the present invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements.
  • [0009]
    FIG. 1 is a diagram of an authorization and settlement system, according to an example embodiment.
  • [0010]
    FIG. 2 is a diagram of another authorization and settlement system, according to an example embodiment.
  • [0011]
    FIG. 3 is a diagram of a method for authorization and settlement, according to an example embodiment.
  • [0012]
    FIG. 4 is a diagram of another method for authorization and settlement, according to an example embodiment.
  • [0013]
    FIG. 5 is a diagram of yet another method for authorization and settlement, according to an example embodiment.
  • [0014]
    FIG. 6 is a diagram of example network-based commerce system or facility which implements various embodiments associated with the invention.
  • [0015]
    FIG. 7 is a diagram of example applications implemented within some of the components of the network-based commerce system of FIG. 6.
  • [0016]
    FIG. 8 is a diagram of machine architecture which implements various aspects of the invention, according to an example embodiment.
  • DETAILED DESCRIPTION
  • [0017]
    Methods and systems for automated authorization and settlement are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the invention. It will be evident, however, to one of ordinary skill in the art that other embodiments of the invention may be practiced without these specific details.
  • [0018]
    FIG. 1 is a diagram of an authorization and settlement system 100, according to an example embodiment. The authorization and settlement system 100 is implemented in a machine-accessible and/or readable medium and is accessible over a network. The network may be wired, wireless, or a combination of wired and wireless. In an embodiment, the authorization and settlement system 100 is implemented as an authorization and settlement service on a network server over the WWW and is accessible to and interacts with buyers and merchants for purposes of providing automated authorization and settlement techniques to the merchants and the buyers.
  • [0019]
    The authorization and settlement system 100 includes a merchant interface 101, a buyer interface 102, and a network-based authentication and settlement service 103. In an embodiment, the authorization and settlement system 100 also includes an interface to one or more financial systems 104.
  • [0020]
    The components 101-104 of the authorization and settlement system 100 interact with one another in a dynamic and real-time fashion. Buyers separately and independently interact with merchants to purchase goods or services of the merchants. During these buyer-merchant transactions, a merchant requests an authorization of the authorization and settlement system 100 via the merchant interface 101.
  • [0021]
    A merchant initiated authorization request (made via the merchant interface 101) results in an amount of currency (e.g., dollars, euros, yen, etc.) being reserved, set aside, or locked against positive funds held by a buyer, who is associated with a merchant-buyer transaction. The funds of the buyer can come from a plurality of different funding sources (e.g., checking account, credit card, positive balances held in financial accounts, debit cards, gift certificates, etc.).
  • [0022]
    The merchant interacting through the merchant interface 101 does not concern itself with the types of funding sources of the buyer. The risks and processing associated with authorization and settlement are handled exclusively by the network-based authorization and settlement service 103. In exchange for this, the network-based authorization and settlement service 103 may levy and collect fees form the merchant or from accounts of the merchant which are accessible to the network-based authorization and settlement service 103.
  • [0023]
    A settlement occurs when funds associated with funding sources of the buyer are debited and transferred to other accounts associated with the merchant. Generally, a settlement occurs once a merchant ships a good to a buyer. Authorization occurs when the buyer initially orders a good from a merchant.
  • [0024]
    A variety of different events can occur between the initial time of an original authorization and a final time associated with a settlement. For example, a settlement may never occur, such as when a merchant-buyer transaction is voided. Also, the settlement may be for an amount that exceeds the original authorization. Further, the settlement may actually be processed as a series of smaller intermediate settlements occurring at different time periods. In another circumstance, the settlement may get delayed beyond a reasonable or configurable period of elapsed time from when the original authorization was requested; consequently, a reauthorization may need to take place before a settlement is permissible.
  • [0025]
    In addition to temporal events which can be dynamically occurring between the merchant and the buyer during an authorization and settlement elapsed period of time, the funding sources of the buyer can be or can become problematic. For example, a buyer may have a primary funding source listed as a checking account (e.g., ACH, etc.); ACH or instant ACH (iACH) transactions do not permit locking of funds for purposes of authorization. Basically, just about any funding source that is not a credit card (CC) does not permit locking of funds, with the exception of a balance transaction. For example, debit cards can lock an available balance at an account holder's bank while a credit card can lock funds by decreasing the available credit limit at the issuing bank of the account holder. In addition, a buyer's CC (funding source) may have had a valid expiration date at the time of an authorization but may actually expire before a settlement is processed.
  • [0026]
    An ACH refers to an automated secure payment transfer system that connects all U.S. financial institutions. The ACH network acts as the central clearing facility for Electronic Fund Transfer (EFT) transactions that occur nationwide, representing a crucial link in the national banking system. It is here that payments linger in something akin to a holding pattern while awaiting clearance for their final banking destination. An instance ACH (iACH) does not linger in a holding pattern; rather, funds are transferred instantaneously.
  • [0027]
    The management of events and accounts (funding sources) is seamlessly handled by the network-based authorization and settlement service 103 on behalf of the merchant. This processing will now be discussed more completely in terms of the components 101-104 of the authorization and settlement system 100.
  • [0028]
    The merchant interface 101 acts as an intermediary between a merchant and the network-based authorization and settlement service 103. In an embodiment, the merchant interface 101 is implemented as a series of dynamic and real-time applets or browser pages over the WWW. In an alternative embodiment, the merchant interface 101 is implemented as a batch Application Programming Interface (API), such that a merchant may collect authorization and/or settlement requests and send them in batches to the network-based authorization and settlement service 103 for processing.
  • [0029]
    The buyer interface 102 acts as an intermediary between a buyer and the network-based authorization and settlement service 103. Similar to the merchant interface 101, the buyer interface 102 may be WWW-based or API-based, and may be dynamic or batch oriented. Although, unlike the merchant interface 101, a buyer is less likely to use an API-based interface and is more likely to use a WWW-based interface.
  • [0030]
    The merchant and buyer may initially interact with one another independent of the network-based authorization and settlement service 103. For example, a buyer may browse a website of the merchant and select items for purchase. In some cases, the merchant may enlist other third-party services to provide interfaces to the buyer to purchase a good or service. In an embodiment, the third-party service that permits the purchase of goods and services of a merchant may be the network-based authorization and settlement service 103. If during a purchasing transaction, the merchant attempts to perform an authorization for a given merchant-buyer transaction, then the merchant uses the merchant interface 101 to make an authorization request of the network-based authorization and settlement service 103 and/or redirects a buyer to the buyer interface 102.
  • [0031]
    The network-based authorization and settlement service 103 may be implemented as an enhanced feature of existing banking or payment services. For example, the network-based authorization and settlement service 103 may be implemented as an enhanced feature of PayPal® or eBay® of San Jose, Calif. In other embodiments, the network-based authorization and settlement service may be implemented as a new and customized payment or banking service.
  • [0032]
    The network-based authorization and settlement service 103 maintains a variety of account information for merchants and buyers. The account information may be viewed from one or more financial systems 104. The financial systems 104 may include one or more data stores (e.g., directories, databases, data warehouses, electronic files, or various combinations of the same). The financial systems 104 may include internal account information for merchants and buyers and may also include external interfaces to external funding sources, such as ACH, iACH, CC, and the like.
  • [0033]
    The network-based authorization and settlement service 103 maintains at least two funding sources for a buyer. A primary funding source and a backup funding source (BUFS). Again, a funding source may be an ACH account (checking account or bank account), an iACH account, a CC, a gift certificate, a positive balance account, etc.
  • [0034]
    A positive balance account is an account maintained by the network-based authorization and settlement service 103 or by a merchant that is being managed via the network-based authorization and settlement service 103. For example, a buyer may return an item to a merchant and acquire an in-store credit; this would be viewed as a positive balance account. Alternatively, a buyer may deposit funds into or receive funds from other sources into a network-based authorization and settlement service 103 accounts, such as a PayPal® account. For example, suppose a buyer is also occasionally also a seller on eBay® and receives payment via CC into a PayPal® account from a different buyer on eBay®. In this example, the PayPal® account has a positive balance and may be viewed as an account within the network-based authorization and settlement service 103.
  • [0035]
    The authorization and settlement system 100 provides novel authorization and settlement services to merchants over a network. These services permit the merchants to offload authorization and settlement processing and optionally decide whether to assume risks for a given transaction or delegate risks to the authorization and settlement system 100. These services will now be discussed.
  • [0036]
    A merchant initiates an authorization request for a merchant-buyer transaction via the merchant interface 101. In response to this, the network-based authorization and settlement service 103 identifies the buyer and accounts (funding sources) associated with the buyer from the financial systems 104. If a particular buyer lacks account information with the network-based authorization and settlement service 103, then the merchant interface 101 may be used to direct the merchant to redirect the buyer to the buyer interface 102. The buyer interface 102 may then be used by the network-based authorization and settlement service 103 to register and acquire funding source information for any previously unknown buyer.
  • [0037]
    The network-based authorization and settlement service 103 provides an honor period for a merchant after a successful authorization has taken place. This means that during a valid honor period the network-based authorization and settlement service 103 will most probably ensure payment or settlement to a merchant if the merchant requests settlement. In some cases, exceptions to honoring payment or settlement may be present in which case payment or settlement may not be guaranteed. The arrangement of honoring may be viewed as equivalent to open-to-buy-hold of credit card transactions; however it can be achieved against funding sources which are not credit cards. This can effectively divert risks associated with actual payment from a merchant to the network-based authorization and settlement service 103. The network-based authorization and settlement service 103 may elect to assess a small fee to a merchant for such a risk assumption. Risks can occur if the primary funding source of a buyer for a transaction is a checking account (ACH or iACH) and the checking account lacks funds at the time of settlement to make good on the transaction. Risks can also occur when a CC is used as a funding source and which becomes expired or cancelled before a settlement issues.
  • [0038]
    One technique to minimize the risks assumed by the network-based authorization and settlement service 103 is for the network-based authorization and settlement service 103 to require a backup funding source (BUFS) for a given authorization request. For example, if the primary funding source of a buyer is a checking account, then the network-based authorization and settlement service 103 may not permit an authorization request unless that same buyer includes a valid CC as a BUFS to the checking account. In this manner if a subsequent settlement attempt fails against the checking account, then the network-based authorization and settlement service 103 may still process the settlement through use of the CC (BUFS). Conventional authorization techniques do not permit authorization against checking accounts; however, as is demonstrated above the network-based authorization and settlement service 103 does effectively achieve authorization against a funding source not capable of authorization, such as a checking account. This is done partially by the network-based authorization and settlement service assuming some risks and through the use of a BUFS for an authorization.
  • [0039]
    Another novel feature of the network-based authorization and settlement service 103 is that it may provide and authorization and/or settlement from multiple funding sources. In other words, suppose a merchant (M) wants to authorize $100 for a given buyer (B), suppose further that the B has two funding sources a positive balance account of $50 and a CC. The network-based authorization and settlement service 103 may lock the $50 (since this is within the control of the network-based authorization and settlement service 103) and then lock via traditional CC processing services $50 against the CC. Although the above-provided example used two funding sources, it should be apparent that more than two funding sources may be used for a single authorization. In fact, various combinations of different funding sources may be used to perform authorization with the network-based authorization and settlement service 103.
  • [0040]
    In still other processing circumstances, the network-based authorization and settlement service 103 may periodically void an existing authorization of a merchant. This can occur for a variety of reasons. The authorization may be voided affirmatively by the merchant or it may be voided by the authorization and settlement service 103 after an elapsed period of time during which no settlement request is received. In this latter situation, the risk associated with settlement can be minimized by the network-based authorization and settlement service 103 by providing time frames during which a settlement should occur.
  • [0041]
    A voided authorization or an authorization that is modified before a settlement occurs can also be reauthorized via the network-based authorization and settlement service 103. The period of time during which a reauthorization is permissible may be referred to as an authorization period and may be configured within the network-based authorization and settlement service 103 as a parameter or as a profile associated with specific merchants. Reauthorization is a beneficial feature that permits merchants to obtain another honor period and to increase or decrease the amount of the amount to be settled when conditions change, such as when a substantial increase in a settlement amount occurs after an initial authorization. During an authorization period if a settlement occurs the network-based authorization and settlement system allows the merchant to request a settlement. A reauthorization can fail many times with no consequence, which means that the merchant just does not get another honor period.
  • [0042]
    In still another embodiment, the network-based authorization and settlement service 103 is adapted to receive and process settlement requests issued by the merchant for a previous authorization request having a valid authorization period during which the settlement requests are honored by the network-based authorization and settlement service 103. In an embodiment, the authorization and settlement service 103 may be dynamically configured with two parameters. The first parameter defines an authorization period during which settlements may be permitted. The second parameter includes an honor period during which a settlement is honored. In some other embodiments, a parameter may be used to communicate a hard limit on the number of reauthorizations which are permissible during an authorization period.
  • [0043]
    A single authorization maybe used by a merchant with multiple settlement requests that occur at different time intervals. For example, a merchant may have payment arrangements with a buyer such that on authorization 20% is paid, when the product ships 50% more is paid, and when the product is received or delivered the remaining 30% is paid. In such a situation, the network-based authorization and settlement service 103 permits an initial authorization for N amount. After authorization, the merchant may use the merchant interface 101 to request a settlement of 0.2×N. Later, when the product ships the merchant requests another settlement of 0.5×N. Finally, when a courier service provides evidence of delivery to the buyer, the merchant makes a third settlement request of 0.3×N. This example was presented for purposes of illustration only, since in a more likely scenario a single purchase by a buyer may include multiple merchant products where each product is settled when each individual product ships.
  • [0044]
    Furthermore, a single authorization may support settlement amounts that are less than the initial authorization request or more than the initial authorization request. For example, a merchant may use the merchant interface 101 to request an authorization for a buyer via the network-based authentication and settlement service 103 for an amount of N. Later, the buyer may add on a warranty for the product or request an expedited delivery mechanism which adds expense to N. In these cases, a configurable amount Z above N may be permissible allowed with a settlement request to account for such unforeseen but practical circumstances. The additional configurable amount Z may or may not be pre-locked against funds of the buyer, but such an amount can still be honored by the network-based authorization and settlement service 103. In a like manner, conditions may exist such that N is reduced at settlement, the network-based authorization and settlement service 103 permits reduced settlement requests as well.
  • [0045]
    In some cases, a settlement may fail such as in fraudulent situations. In these cases, the network-based authentication and settlement service 103 may dynamically contact the buyer via the buyer interface 102 and receive dynamic changes to the account.
  • [0046]
    In some embodiments, the network-based authentication and settlement service 103 and the merchant may desire to have risks associated with settlement to be assumed by a merchant. In these cases, the merchant may be voluntarily assuming risks and may desire to be the merchant of record on the merchant-buyer transactions. Thus, should a settlement fail because of change conditions or funding sources, then the network-based authentication and settlement service 103 would not have to honor the payment, since the network-based authentication and settlement service 103 and the merchant mutually agreed to permit the merchant to assume the risks.
  • [0047]
    It is now appreciated how the authentication and settlement system 100 is flexibly implemented and enabled in a dynamic environment for purposes of capturing practical conditions that may occur with merchant-buyer transactions and with buyer finding sources. These conditions are accounted for and addressed in novel manners to provide flexibility to merchants and buyers to further enhance seamless online transactions and financing.
  • [0048]
    FIG. 2 is a diagram of another authorization and settlement system 200, according to an example embodiment. The authorization and settlement system 200 is implemented in a machine-accessible and/or readable medium and is accessible over a network. The authorization and settlement system 200 presents an alternative arrangement of the authorization and settlement system 100 presented above with respect to FIG. 1.
  • [0049]
    The authorization and settlement system 200 includes a merchant data store 201, a buyer data store 202, and an authorizer and settler 203. The authorization and settlement system 200 is accessible over a network 210 and interacts or facilitates financial transactions between buyers 211 and merchants 212. The network 210 interaction and interfaces associated with the buyers 211 and the 212 were discussed above with respect to the authorization and settlement system 100 of FIG. 1 and the merchant interface 101 and the buyer interface 102.
  • [0050]
    The merchant data store 201 maintains profile and configuration information associated with merchants that are serviced by the authorizer and settler 203. In addition, the information regarding funding sources and financial accounts for merchants may be maintained within the merchant data store. The profile and configuration information may identify a variety of information that drives authorization and settlement processing by the authorizer and settler 203.
  • [0051]
    For example, an honor period (period during which settlements are honored) may be established for merchants 212 along with an authorization period (period during which reauthorizations may occur). Configuration and profile information may also indicate whether a merchant 212 is assuming risks for settlements or whether such a risk is being assumed by the authorizer and settler 203. Still other information may indicate what fees are being accessed by the authorizer and settler 203 for the authorization and settlement services that it provides to the merchants 212.
  • [0052]
    In a similar manner, the buyer data store 202 may include account information and configurations and profiles for buyers 211. A buyer's information may be dynamically established and housed in the buyer data store 202 during any given merchant-buyer transaction. This may occur when a merchant 212 redirects a buyer 211 to the authorizer and settler 203 over the network 210 and the buyer data store 202 has no record or information about that particular buyer 211. Some information associated with a buyer 211 may include account specific information for funding sources, such as a CC number, expiration date for a CC, checking or bank account number, etc. The buyer 211 may also have positive balance accounts with the authorizer and settler 203 where positive funds are available for use. Alternatively, the buyer 211 may have positive balance accounts with a merchant 212 which is being managed by the authorizer and settlers 203. Moreover, in some cases the buyer 211 may have loyalty points or gift certificates that may be used as currency for a given merchant-buyer transaction. This type of funds is treated similar to positive balance accounts, which were discussed above.
  • [0053]
    The authorizer and settler 203 is implemented as an authorizer and settler means within software instructions installed and executing on one or more machines. The authorizer and settler means interact with merchants 212 over the network 210 to acquire authorization and settlement requests from merchant-buyer transactions.
  • [0054]
    Authorization requests and reauthorization requests may be handled in the manners discussed above with respect to the authorization and settlement system 100 of FIG. 1. Similarly, the settlement requests may be handled in the manners discussed above with respect to the authorization and settlement system 100 of FIG. 1. In addition to interacting and managing information within the merchant data store 201 and the buyer data store 202, the authorizer and settler means may interact with a plurality of external financial systems or services for purposes of locking and/or moving currency from various funding sources associated with the merchants 212 and the buyers 211.
  • [0055]
    In an embodiment, the authorization and settlement means is implemented within a payment service, such as PayPal®. The payment service may also be used by merchants 212 to offload on-line purchasing associated with buyers 211 of the merchants 212. The payment service will also provide the authorization and settlement services described herein. Furthermore, the payment service may be dynamic such as when implemented through browser interfaces or the payment service may be batched enabled such as when a plurality of transactions are batched and periodically communicated to the payment service via an API.
  • [0056]
    FIG. 3 is a diagram of a method 300 for authorization and settlement, according to an example embodiment. The method 300 (herein after “authorization and settlement service”) is implemented in a machine-accessible and/or readable medium and is accessible over a network. In an embodiment, the authorization and settlement service may be implemented as the network-based authorization and settlement service 103 of FIG. 1 and/or the authorizer and settler means of the authorization and settlement system 200 of FIG. 2.
  • [0057]
    At 310, the authorization and settlement service receives an authorization transaction request from a merchant. The transaction is associated with an amount for a merchant-buyer transaction. In some cases, the request may be the result of a merchant forwarding a potential buyer to interfaces associated with the authorization and settlement service during a buyer's attempt to purchase a good or service from the merchant. The amount may be currency, such as money (e.g., dollars, euros, yens, etc.). Alternatively, the amount may be loyalty points associated with buyer-loyalty programs.
  • [0058]
    At 320, the authorization and settlement service attempts to authorize the amount against one or more funding sources associated with a buyer to a merchant-buyer transaction. Funding sources include CC accounts, bank saving accounts, checking accounts, debit card accounts, loyalty accounts, gift certificate positive balances, and positive balance accounts. Information regarding the funding sources is retained by the authorization and settlement service. If a particular buyer has no such information then the information is dynamically obtained in real-time from the buyer or the information is sent from the merchant in batch to the authorization and settlement service.
  • [0059]
    The authorization and settlement service may authorize portions of the amount from one funding source (such as a positive balance account) and authorize the remaining portions of the amount from a different funding source (such as a CC). In addition, the authorization and settlement service may permit an authorization to occur or appear to occur for a merchant even when the primary funding source of the buyer is associated with a funding source that is not capable of being locked or reserved, such as an ACH, iACH, or checking account. In these situations, the authorization and settlement service assumes the risk that a settlement will be successful. It should also be noted that the selection of funding sources can dynamically change during a reauthorization and/or during a settlement. In this manner any available positive funds can be acquired if previous identified funding sources associated with an authorization do not have any funds or lack funds to sufficiently permit a settlement.
  • [0060]
    If an authorization is successful, then, at 330, the authorization and settlement service sends a confirmation to the merchant that the authorization was successful. This confirmation permits the merchant to begin processing the order of the buyer to hopefully eventually consummate the merchant-buyer transaction. If an authorization is not successful, then, at 330, the authorization and settlement service notifies the merchant of such a failure.
  • [0061]
    Once initial authorization is successfully achieved, a variety of events or conditions may occur which may warrant that a reauthorization be attempted, at 340. Some of these events or conditions may be affirmatively dictated by the merchants, such as when the merchant wants to charge significantly more for a good or service based on a variety of circumstances (e.g., changed order of buyer, etc.). Moreover, some of the events or conditions may be dictated by agreed policies or configurations of the authorization and settlement service with respect to a particular merchant, such as when the intervening period between an initial authorization and a settlement request exceeds a configurable period of time (e.g., 3 days, etc.). The number of reauthorizations that may be attempted and the conditions and events for which reauthorizations occur may be dictated by policies or profiles.
  • [0062]
    In an embodiment, at 341, an authorization or reauthorization may be voided after a configurable event is detected. For example, a merchant may void a pending transaction. The authorization and settlement service may detect that a primary funding source of the buyer in a transaction is invalid or become invalid. In fact a variety of situations may be defined and detected which may warrant terminating an authorization.
  • [0063]
    During a valid authorization period, the authorization and settlement service honors any submitted settlement request received from the merchant. This assumes that the settlement request confirms to certain parameters, such as being within a certain percentage of the original agreed amount used for authorization, and the like. This also assumes that the merchant has not asked to voluntarily assume the risk for settlement of its own merchant-buyer transactions. The honor period may be defined and agreed upon between the merchant and the authorization and settlement service. Moreover, an honor period and its conditions for one merchant may be different than an honor period and its conditions for another merchant.
  • [0064]
    When a settlement is processed, the authorization and settlement service transfers currency or loyalty points from funding sources of a buyer to accounts of the merchant. The merchant sends settlement requests to the authorization and settlement service during valid authorization periods and assuming honor conditions are met, the actual transfer takes place. To achieve this, the authorization and settlement service may include one or more external interfaces to financial or payment services, such as ACH, iACH, CC processing services, etc. In some embodiments, the authorization and settlement service may also have an interface to loyalty services for purposes of crediting and debiting loyalty points from loyalty accounts.
  • [0065]
    In an embodiment, at 350, the authorization and settlement service settles for the initial authorization amount from two or more different funding sources associated with a buyer after the authorization and settlement service receives a settlement request. In another embodiment, at 360, the authorization and settlement service may honor and process multiple settlement requests occurring at different time intervals against the initial authorization. In yet another embodiment, at 370, the authorization and settlement service may settle at an amount above the initial authorization amount. The final settlement may also be made at an amount that is less than the initial requested authorization amount. In fact, any combination of the embodiments expressed in 340-380 may be processed by the authorization and settlement service.
  • [0066]
    At 380, and according to another embodiment, the authorization and settlement service may detect upon attempting a settlement that a failure has occurred with one or more of the buyer's funding sources. In such a situation, the authorization and settlement service may dynamically permit the buyer to alter the mix of funding sources and/or to correct information associated with an incorrect funding source. In this manner, the settlement may still occur even when an error occurs with one or more of the funding sources.
  • [0067]
    FIG. 4 is a diagram of another method 400 for authorization and settlement, according to an example embodiment. The method 400 (hereinafter “authorization service”) is implemented in a machine-accessible and/or readable medium and is accessible over a network. The authorization service permits a merchant to lock funds for buyer transactions against funding sources that traditionally do not support fund locking, such as ACH, iACH, and/or checking accounts.
  • [0068]
    Actually, the merchant believes that he/she has locked funds that are not traditionally capable of being locked; but, the authorization service manages funding sources and assumes risks to ensure an authorization is honored. Thus, from the merchant's perspective he receives an authorization like he/she would with a CC and the merchant is not concerned about the funding source since the authorization service manages this and assumes the risk (unless the merchant voluntarily and affirmatively elects to assume the risk, as was discussed above). The authorization service achieves a degree of true locking by using a backup funding source for an authorization, such as a CC.
  • [0069]
    At 410, the authorization service receives from a merchant an authorization request for a buyer. In some cases, the request is acquired from the buyer who was redirected to the authorization service from interactions with the merchant. At 420, the authorization service detects that the request is associated with a checking account. A checking account does not traditionally include electronic mechanisms to lock or reserve funds for purposes of performing an authorization.
  • [0070]
    Consequently, at 430, the authorization service acquires a CC as a backup funding source (BUFS) to the checking account. The CC may exist within the information associated with the buyer or may be dynamically acquired directly from the buyer as a BUFS. The BUFS is used by the authorization service to minimize risks that the authorization service assumes by permitting an authorization where the buyer supplies a primary funding source as a checking account or electronic check.
  • [0071]
    At 440, the authorization service honors the authorization and notifies the merchant of the same if a valid CC is obtained as a BUFS to the checking account. In an embodiment, at 450, the authorization service may further attempt to minimize its risk exposure to any subsequent settlement by processing a variety of fraud and/or risk factors or algorithms with respect to the pending merchant-buyer transaction and the buyer.
  • [0072]
    In some embodiments, the authorization service may also support settlement processing. Additionally, at 460, the authorization amounts or settlement amounts may be dynamically modified after an initial valid authorization occurs. The funding source mixes and amounts may be dynamically modified via reauthorizations or during settlement attempts.
  • [0073]
    For example, at 470, the authorization service may receive a settlement request from the merchant. At 471, a first portion of the settlement amount may be directly acquired by using an ACH or iACH interface to transfer the first portion out of the buyer's checking account. Concurrently, or subsequent to 471, at 472, the authorization service acquires a second portion of the settlement amount from the CC account. At 473, the first and second portions are transferred or credited to an account associated with the merchant. That account for the merchant may be an external bank or may be an internal account managed by the authorization service on behalf of the merchant.
  • [0074]
    As another example, at 474, the authorization service may acquire all or various portions of the settlement from a plurality of funding sources, such as CC accounts, positive balance accounts, loyalty points, gift certificates, bank accounts, and the checking account.
  • [0075]
    FIG. 5 is a diagram of yet another method 500 for authorization and settlement, according to an example embodiment. The method 500 (hereinafter “alternative authorization service”) is implemented in a machine-accessible and/or readable medium and is accessible over a network. The alternative authorization service provides a different or alternative perspective of the authorization service's processing represented by the method 400 of FIG. 4. With this alternative perspective, the merchant assumes risks associated with a settlement that may not be capable of being obtained when requested.
  • [0076]
    It is to be understood, that the features of the alternative authorization service may be another processing mode of the authorization service presented in FIG. 4. Thus, the processing of the two services does not have to be mutually exclusive. In fact, the processing of the two services may be implemented as a single service with a different configuration or different run-time determined modes of operation.
  • [0077]
    At 510, the alternative authorization service receives an authorization request associated with a buyer. At 520, the primary funding source of the buyer is one that does not support locking of funds for purposes of authorization. For example, at 521, the primary funding source may be a checking account, ACH, or iACH account. In addition, a backup funding source (BUFS) for the buyer is acquired for the buyer. At 521, that BUFS may be a CC account of the buyer.
  • [0078]
    At 530, the alternative authorization service honors the authorization request by letting the merchant assume the risk for the transaction. That is, the merchant may assume the risks associated with its operations. This may be particularly useful to large merchants.
  • [0079]
    In addition, if the risk of non payment at settlement is assumed by the merchant, then the merchant will be designated as the merchant of record for a transaction, as depicted at 540. Any service fee assessed by the alternative authorization service may be reduced in situations where the merchant is the merchant of record, since in these situations the merchant assumes risk of non payment and the alternative authorization service does not have an honor period. The processing of the alternative authorization service is still useful to the merchant of record, because it is outsourced to the alternative authorization service and because it permits authorization for funding sources that traditionally do not include interfaces that allow funds to be locked during an authorization.
  • [0080]
    The methods 300, 400, and 500 may be implemented as instructions on machine-accessible media. The instructions are adapted to process the methods 300, 400, and 500 when accessed by a machine. The media may be removable and portable, such that when it is interfaced to a media bay of a machine it is uploaded to the machine, loaded, and processed. Alternatively, the instructions may reside on a remote machine or storage media and be downloaded over a network to a machine and processed. In still other embodiments, the instructions may be prefabricated within the memory and/or storage of a machine.
  • [0081]
    FIGS. 6-8 are now presented as example implementations of the authorization and settlement techniques presented herein. It is understood that these example architectures and arrangements are presented for purposes of illustration only and are not intended to limit other implementations of the teachings presented.
  • [0082]
    FIG. 6 is a diagram of example network-based commerce system or facility 600 which implements various embodiments associated with the invention. A commerce system 600, in the example form of a network-based marketplace, provides server-side functionality, via a network 620 (e.g., the Internet) to one or more clients.
  • [0083]
    FIG. 6 illustrates, for example, a web client 641 (e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Wash. State), and a programmatic client 631 executing on respective client machines 640 and 630.
  • [0084]
    An API server 611 and a web server 612 are coupled to, and provide programmatic and web interfaces respectively to, one or more application servers 613. The application servers 613 host one or more marketplace applications 614 and payment applications 615. The application servers 613 are, in turn, shown to be coupled to one or more databases servers 616 that facilitate access to one or more databases 617.
  • [0085]
    The marketplace applications 614 provide a number of marketplace functions and services to users that access the commerce system 610. The payment applications 615 likewise provide a number of payment services and functions to users. The payment applications 615 may allow users to accumulate value (e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”) in accounts, and then later to redeem the accumulated value for products (e.g., goods or services) that are made available via the marketplace applications 614. While the marketplace and payment applications 614 and 615 are shown in FIG. 6 to both form part of the commerce system 610, it will be appreciated that, in alternative embodiments, the payment applications 615 may form part of a payment service that is separate and distinct from the commerce system 610.
  • [0086]
    Further, while the system 600 shown in FIG. 6 employs a client-server architecture, the present invention is of course not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, architecture system for example. The various marketplace and payment applications 614 and 615 could also be implemented as standalone software programs, which do not necessarily have networking capabilities.
  • [0087]
    The web client 641 accesses the various marketplace and payment applications 614 and 615 via the web interface supported by the web server 612. Similarly, the programmatic client 631 accesses the various services and functions provided by the marketplace and payment applications 614 and 615 via the programmatic interface provided by the API server 611. The programmatic client 631 may, for example, be a seller application (e.g., the TurboLister application developed by eBay Inc., of San Jose, Calif.) to enable sellers to author and manage listings on the commerce system 610 in an off-line manner, and to perform batch-mode communications between the programmatic client 631 and the network-based commerce system 610.
  • [0088]
    FIG. 6 also illustrates a third party application 651, executing on a third party server machine 650, as having programmatic access to the network-based commerce system 610 via the programmatic interface provided by the API server 611. For example, the third party application 651 may, utilizing information retrieved from the network-based commerce system 610, support one or more features or functions on a website hosted by the third party. The third party website may, for example, provide one or more promotional, marketplace or payment functions that are supported by the relevant applications of the network-based commerce system 610.
  • [0089]
    FIG. 7 is a diagram of example applications 700 implemented within some of the marketplace applications 614 of the network-based commerce system 610 of FIG. 6. The applications 700 may be hosted on dedicated or shared server machines (not shown) that are communicatively coupled to enable communications between server machines. The architecture of one such example server machine is provided below. The applications themselves are communicatively coupled (e.g., via appropriate interfaces) to each other and to various data sources, so as to allow information to be passed between the applications or so as to allow the applications to share and access common data.
  • [0090]
    The authorization and settlement applications 701 provide the novel authorization and settlement services described herein. These applications 701 are coupled or interfaced with a variety of other applications in a commerce system 610.
  • [0091]
    The commerce system 610 may provide a number of listing and price-setting mechanisms whereby a seller may list (or publish information concerning) goods or services for sale, a buyer can express interest in or indicate a desire to purchase such goods or services, and a price can be set for a transaction pertaining to the goods or services. To this end, the marketplace applications 700 are shown to include one or more auction applications 702 which support auction-format listing and price setting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions etc.). The various auction applications 702 may also provide a number of features in support of such auction-format listings, such as a reserve price feature whereby a seller may specify a reserve price in connection with a listing and a proxy-bidding feature whereby a bidder may invoke automated proxy bidding.
  • [0092]
    A number of fixed-price applications 703 support fixed-price listing formats (e.g., the traditional classified advertisement-type listing or a catalogue listing) and buyout-type listings. Specifically, buyout-type listings (e.g., including the Buy-It-Now (BIN) technology developed by eBay Inc., of San Jose, Calif.) may be offered in conjunction with an auction-format listing, and allow a buyer to purchase goods or services, which are also being offered for sale via an auction, for a fixed-price that is typically higher than the starting price of the auction.
  • [0093]
    Store applications 704 allow sellers to group their listings within a “virtual” store, which may be branded and otherwise personalized by and for the sellers. Such a virtual store may also offer promotions, incentives and features that are specific and personalized to a relevant seller.
  • [0094]
    Reputation applications 705 allow parties that transact utilizing the network-based commerce system 610 to establish, build, and maintain reputations, which may be made available and published to potential trading partners. Consider that where, for example, the network-based commerce system 610 supports person-to-person trading, users may have no history or other reference information whereby the trustworthiness and credibility of potential trading partners may be assessed. The reputation applications 705 allow a user, for example through feedback provided by other transaction partners, to establish a reputation within the network-based commerce system 610 over time. Other potential trading partners may then reference such a reputation for the purposes of assessing credibility and trustworthiness.
  • [0095]
    Personalization applications 706 allow users of the commerce system 610 to personalize various aspects of their interactions with the commerce system 610. For example a user may, utilizing an appropriate personalization application 706, create a personalized reference page at which information regarding transactions to which the user is (or has been) a party may be viewed. Further, a personalization application 706 may enable a user to personalize listings and other aspects of their interactions with the commerce system 610 and other parties.
  • [0096]
    The network-based commerce system 610 may support a number of marketplaces that are customized, for example, for specific geographic regions. A version of the commerce system 610 may be customized for the United Kingdom, whereas another version of the commerce system 610 may be customized for the United States. Each of these versions may operate as an independent marketplace, or may be customized (or internationalized) presentations of a common underlying marketplace. These are represented as the internationalization applications 707 in FIG. 7.
  • [0097]
    Navigation of the network-based commerce system 610 may be facilitated by one or more navigation applications 708. For example, a search application enables key word searches of listings published via the commerce system 610. A browse application allows users to browse various category, catalogue, or inventory data structures according to which listings may be classified within the commerce system 610. Various other navigation applications may be provided to supplement the search and browsing applications.
  • [0098]
    In order to make listings, available via the network-based commerce system 610, as visually informing and attractive as possible, the marketplace applications 700 may include one or more imaging applications 709 utilizing which users may upload images for inclusion within listings. An imaging application 709 also operates to incorporate images within viewed listings. The imaging applications 709 may also support one or more promotional features, such as image galleries that are presented to potential buyers. For example, sellers may pay an additional fee to have an image included within a gallery of images for promoted items.
  • [0099]
    Listing creation applications 710 allow sellers conveniently to author listings pertaining to goods or services that they wish to transact via the commerce system 610 and listing management applications 711 allow sellers to manage such listings. Specifically, where a particular seller has authored and/or published a large number of listings, the management of such listings may present a challenge. The listing management applications 711 provide a number of features (e.g., auto-re-listing, inventory level monitors, etc.) to assist the seller in managing such listings. One or more post-listing management applications 712 also assist sellers with a number of activities that typically occurs post-listing. For example, upon completion of an auction facilitated by one or more auction applications 702, a seller may wish to leave feedback regarding a particular buyer. To this end, a post-listing management application 712 may provide an interface to one or more reputation applications 705, so as to allow the seller conveniently to provide feedback regarding multiple buyers to the reputation applications 705.
  • [0100]
    Dispute resolution applications 713 provide mechanisms whereby disputes arising between transacting parties may be resolved. For example, the dispute resolution applications 713 may provide guided procedures whereby the parties are guided through a number of steps in an attempt to settle a dispute. In the event that the dispute cannot be settled via the guided procedures, the dispute may be escalated to a third party mediator or arbitrator.
  • [0101]
    A number of fraud prevention applications 714 implement fraud detection and prevention mechanisms to reduce the occurrence of fraud within the commerce system 610.
  • [0102]
    Messaging applications 715 are responsible for the generation and delivery of messages to users of the network-based commerce system 610, such messages for example advising users regarding the status of listings at the commerce system 610 (e.g., providing “outbid” notices to bidders during an auction process or to provide promotional and merchandising information to users).
  • [0103]
    Merchandising applications 716 support various merchandising functions that are made available to sellers to enable sellers to increase sales via the commerce system 610. The merchandising applications 716 also operate the various merchandising features that may be invoked by sellers, and may monitor and track the success of merchandising strategies employed by sellers.
  • [0104]
    The network-based commerce system 610 itself, or one or more parties that transact via the commerce system 610, may operate loyalty programs that are supported by one or more loyalty/promotions applications 717. For example, a buyer may earn loyalty or promotions points for each transaction established and/or concluded with a particular seller, and may be offered a reward for which accumulated loyalty points can be redeemed.
  • [0105]
    FIG. 8 is a diagram of machine architecture 800 which implements various aspects of the invention, according to an example embodiment. The machine includes a set of instructions, which when executed on the machine cause the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
  • [0106]
    The example computer architecture 800 includes a processor 802 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory 804 and a static memory 806, which communicate with each other via a bus 808. The architecture 800 may further include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The architecture 800 also includes an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse), a disk drive unit 816, a signal generation device 818 (e.g., a speaker) and a network interface device 820.
  • [0107]
    The disk drive unit 816 includes a machine-readable medium 822 on which is stored one or more sets of instructions (e.g., software 824) embodying any one or more of the methodologies or functions described herein. The software 824 may also reside, completely or at least partially, within the main memory 804 and/or within the processor 802 during execution thereof by the architecture 800, the main memory 804 and the processor 802 also constituting machine-readable media.
  • [0108]
    The software 824 may further be transmitted or received over a network 826 via the network interface device 820.
  • [0109]
    While the machine-readable medium 822 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
  • [0110]
    Thus, a method and system to provide novel authorization and settlement have been described. Although the present invention has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
  • [0111]
    The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of ordinary skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
  • [0112]
    The Abstract is provided to comply with 37 C.F.R. §1.72(b) and will allow the reader to quickly ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.
  • [0113]
    In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate example embodiment.

Claims (30)

  1. 1. A system, including:
    a merchant interface;
    a buyer interface; and
    a network-based authorization and settlement service that interacts with the merchant interface and the buyer interface, and wherein the network-based authorization and settlement service uses one or more combinations of multiple disparate funding sources associated with buyers via the buyer interface to perform authorizations for merchants that interact through the merchant interface.
  2. 2. The system of claim 1, wherein the authorization and settlement service permits at least one of authorization via a checking account and authorization from a positive balance associated with the network-based authorization and settlement service.
  3. 3. The system of claim 1, wherein the authorization and settlement service automatically performs one or more re-authorizations after a configurable period of time.
  4. 4. The system of claim 1, wherein the authorization and settlement service settles previously authorized transactions after receiving notice from the merchants through the merchant interface.
  5. 5. The system of claim 1, wherein the authorization and settlement service permits multiple settlements for a single authorization.
  6. 6. The system of claim 1, wherein the authorization and settlement service accesses a fee to at least one of the buyers and the merchants for settlement transactions processed after the authorizations.
  7. 7. A system, including:
    a merchant data store;
    a buyer data store; and
    an authorization and settlement means that interacts with merchants to acquire authorization and settlement policies and that interacts with the buyer data store to acquire funding sources for authorizations and settlements.
  8. 8. The system of claim 7, wherein the authorization and settlement means is adapted to perform multiple settlements for a single authorization.
  9. 9. The system of claim 7, wherein the authorization and settlement means is adapted to use one or more of the funding sources from the buyer data store for a single authorization.
  10. 10. The system of claim 7, wherein the authorization and settlement means is adapted to settle above an amount of a single authorization based on a number of the authorization and settlement policies.
  11. 11. The system of claim 7, wherein the authorization and settlement means is adapted to perform one or more re-authorizations in response to conditions in the authorization and settlement policies.
  12. 12. The system of claim 7, wherein the authorization and settlement means is adapted to interact with a buyer to receive updates to a number of the funding sources in the buyer data store.
  13. 13. A system of claim 7, wherein the authorization and settlement means is adapted to terminate pending authorizations in response to interactions with the merchants.
  14. 14. The system of claim 7, wherein the authorization and settlement means is adapted to debit and credit the funding sources in the buyer data store in response to settlements and refunds.
  15. 15. A method, including:
    receiving a transaction from a merchant for an amount;
    authorizing the amount against one or more funding sources; and
    sending a confirmation to the merchant if the authorization was successful.
  16. 16. The method of claim 15 further including, settling the amount from at least two of the one or more funding sources after receiving a notice from the merchant to settle.
  17. 17. The method of claim 15 further including, re-authorizing the amount after a configurable period of time if a settlement has not occurred.
  18. 18. The method of claim 15 further including, processing multiple settlements for different portions of the amount.
  19. 19. The method of claim 15 further including, settling above the amount.
  20. 20. The method of claim 15 further including, voiding the authorization or any reauthorization after a configurable event is detected.
  21. 21. The method of claim 15 further including:
    receiving a correction to one of the one or more funding sources after authorization after a settlement attempt fails; and
    settling the amount after the correction is received.
  22. 22. A method, including:
    receiving an authorization request from a merchant for a buyer;
    detecting that the authorization request is associated with a checking account of the buyer;
    acquiring a credit card as a backup to the checking account; and
    honoring the authorization request.
  23. 23. The method of claim 22, wherein honoring further includes processing risk or fraud factors for the buyer before honoring the authorization request.
  24. 24. The method of claim 22 further including,
    receiving a settlement request from the merchant;
    acquiring a portion of a settlement as an electronic transfer from the checking account;
    acquiring another portion of the settlement from the credit card; and
    transferring the portions to an account associated with the merchant.
  25. 25. The method of claim 22 further including:
    receiving a settlement request from a merchant;
    acquiring a settlement amount to satisfy the settlement request from a funding source, wherein the funding source includes acquiring the settlement from at least one of the credit card account, a positive balance associated with an authorization and settlement service account, and the checking account; and
    crediting the settlement amount to a merchant account associated with the merchant.
  26. 26. The method of claim 22 further including, modifying the settlement amount and combinations of the funding source in response to a reauthorization request or modified settlement request.
  27. 27. A method, including:
    receiving an authorization request associated with a buyer;
    detecting that a funding source associated with the authorization request does not permit locking funds; and
    honoring the authorization request for the funding source using a backup funding source and assigning a risk for the authorization to the merchant.
  28. 28. The method of claim 27 further including, determining that the funding source is an electronic check associated with a bank account and that the backup funding source is a credit card.
  29. 29. The method of claim 27 further including, making the merchant a merchant of record for a transaction associated with the authorization request.
  30. 30. A machine readable medium embodying instructions that, when executed by a machine, cause the machine to perform any one of the claims 15, 22, or 26.
US11102056 2005-04-08 2005-04-08 Authorization techniques Abandoned US20060235758A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11102056 US20060235758A1 (en) 2005-04-08 2005-04-08 Authorization techniques

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US11102056 US20060235758A1 (en) 2005-04-08 2005-04-08 Authorization techniques
US11376848 US7734544B2 (en) 2005-04-08 2006-03-16 Authorization and capture with multiple currencies
PCT/US2006/013016 WO2006110525A3 (en) 2005-04-08 2006-04-05 Authorization techniques
US12778904 US20100223178A1 (en) 2005-04-08 2010-05-12 Authorization and capture with multiple currencies
US15177475 US20160292654A1 (en) 2005-04-08 2016-06-09 Authorization and capture with multiple currencies

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11376848 Continuation US7734544B2 (en) 2005-04-08 2006-03-16 Authorization and capture with multiple currencies

Publications (1)

Publication Number Publication Date
US20060235758A1 true true US20060235758A1 (en) 2006-10-19

Family

ID=37084229

Family Applications (4)

Application Number Title Priority Date Filing Date
US11102056 Abandoned US20060235758A1 (en) 2005-04-08 2005-04-08 Authorization techniques
US11376848 Active 2026-02-24 US7734544B2 (en) 2005-04-08 2006-03-16 Authorization and capture with multiple currencies
US12778904 Abandoned US20100223178A1 (en) 2005-04-08 2010-05-12 Authorization and capture with multiple currencies
US15177475 Pending US20160292654A1 (en) 2005-04-08 2016-06-09 Authorization and capture with multiple currencies

Family Applications After (3)

Application Number Title Priority Date Filing Date
US11376848 Active 2026-02-24 US7734544B2 (en) 2005-04-08 2006-03-16 Authorization and capture with multiple currencies
US12778904 Abandoned US20100223178A1 (en) 2005-04-08 2010-05-12 Authorization and capture with multiple currencies
US15177475 Pending US20160292654A1 (en) 2005-04-08 2016-06-09 Authorization and capture with multiple currencies

Country Status (2)

Country Link
US (4) US20060235758A1 (en)
WO (1) WO2006110525A3 (en)

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060178999A1 (en) * 2005-02-10 2006-08-10 Rust Langbourne W Fee determination device
US20070230371A1 (en) * 2006-03-30 2007-10-04 Obopay Inc. Data Communications Over Voice Channel With Mobile Consumer Communications Devices
US20070255620A1 (en) * 2006-03-30 2007-11-01 Obopay Inc. Transacting Mobile Person-to-Person Payments
US20070255662A1 (en) * 2006-03-30 2007-11-01 Obopay Inc. Authenticating Wireless Person-to-Person Money Transfers
US20070260555A1 (en) * 2005-08-03 2007-11-08 Tp Lab System, method and apparatus for conducting a secure transaction over a call
US20070265961A1 (en) * 2006-05-12 2007-11-15 Ebay Inc. Methods and apparatus for funding transactions
US20080032741A1 (en) * 2006-03-30 2008-02-07 Obopay Programmable Functionalities for Mobile Consumer Communications Devices with Identification-Modules
US20080183590A1 (en) * 2007-01-29 2008-07-31 Antoni Drudis Methods for providing secure eCommerce transactions
US20080189164A1 (en) * 2007-02-01 2008-08-07 Microsoft Corporation Reputation assessment via karma points
US20080270302A1 (en) * 2007-04-27 2008-10-30 American Express Travel Related Services Co., Inc. User experience on mobile phone
US20080270300A1 (en) * 2007-04-27 2008-10-30 American Express Travel Related Services Company, Inc. System and method for performing person-to-person funds transfers via wireless communications
US20080268811A1 (en) * 2007-04-27 2008-10-30 American Express Travel Related Services Co., Inc. Payment application download to mobile phone and phone personalization
US20080270301A1 (en) * 2007-04-27 2008-10-30 American Express Travel Related Services Co., Inc. Mobile payment system and method
US20090119190A1 (en) * 2006-03-30 2009-05-07 Obopay Inc. Virtual Pooled Account for Mobile Banking
US20100036770A1 (en) * 2008-08-07 2010-02-11 Mastercard International, Inc. Method for providing a credit cardholder with multiple funding options
US7734544B2 (en) 2005-04-08 2010-06-08 Ebay Inc. Authorization and capture with multiple currencies
US20100332351A1 (en) * 2009-06-30 2010-12-30 Ebay Inc. Same screen quick pay button
US20110167002A1 (en) * 2002-06-12 2011-07-07 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US20130103583A1 (en) * 2011-10-25 2013-04-25 Bank Of America Corporation Universal Cash Account
US20130198074A1 (en) * 2012-02-01 2013-08-01 Mastercard International, Inc. System and method for pre-purchasing gasoline
US20130218728A1 (en) * 2008-08-10 2013-08-22 Rick Dan Hashop Virtual on-line pre-shopping system and method
US20130238457A1 (en) * 2012-03-12 2013-09-12 Turkcell Teknoloji Arastirma Ve Gelistirme Anonim Sirketi Remote Payment System and Method
US8650118B2 (en) 2002-06-12 2014-02-11 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US8762210B2 (en) 2008-06-03 2014-06-24 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
US20140304143A1 (en) * 2008-09-11 2014-10-09 Certegy Check Services, Inc. Electronic check cashing system
US9710806B2 (en) 2013-02-27 2017-07-18 Fiserv, Inc. Systems and methods for electronic payment instrument repository
US9721253B2 (en) 2015-05-06 2017-08-01 Forter Ltd. Gating decision system and methods for determining whether to allow material implications to result from online activities

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080154789A1 (en) * 2006-09-06 2008-06-26 Lehman Brothers Inc. Method for executing a single tranche synthetic abs derivative transaction
WO2008052340A8 (en) 2006-11-02 2009-06-04 Digifonica Int Ltd Producing routing messages for voice over ip communications
US8281370B2 (en) * 2006-11-27 2012-10-02 Therap Services LLP Managing secure sharing of private information across security domains
EP2090024A4 (en) 2006-11-29 2012-12-05 Digifonica Int Ltd Intercepting voice over ip communications and other data communications
WO2008116296A1 (en) 2007-03-26 2008-10-02 Digifonica (International) Limited Emergency assistance calling for voice over ip communications systems
US8660893B2 (en) 2007-07-23 2014-02-25 Visa U.S.A. Inc. Multi-vendor multi-loyalty currency program
US8818872B2 (en) * 2007-11-07 2014-08-26 At&T Intellectual Property I, L.P. Point of sale transaction processing
EP2232749A4 (en) * 2008-01-04 2012-02-22 Planet Payment Inc Merchant rate lookup
CN101655947A (en) * 2008-08-21 2010-02-24 阿里巴巴集团控股有限公司 Online transaction method and online transaction system for realizing off-shore transaction
CA2812174C (en) 2009-09-17 2018-05-15 Digifonica (International) Limited Uninterrupted transmission of internet protocol transmissions during endpoint changes
US20120023015A1 (en) * 2010-07-21 2012-01-26 Aji Mathai Consolidated Payment and Bank Error Correction
US8606687B2 (en) * 2011-07-21 2013-12-10 Chicago Mercantile Exchange, Inc. Modification of multi-laterally traded contracts based on currency unavailability condition
US9076183B2 (en) 2011-07-21 2015-07-07 Chicago Mercantile Exchange Inc. Multi-laterally traded contract settlement mode modification
US9460436B2 (en) 2012-03-16 2016-10-04 Visa International Service Association Systems and methods to apply the benefit of offers via a transaction handler
US20160148186A1 (en) * 2013-04-30 2016-05-26 Rakuten, Inc. Information processing system, control method of information processing system, and information processing program
US20150363769A1 (en) * 2014-06-16 2015-12-17 Bank Of America Corporation Cryptocurrency Real-Time Conversion System
US20150363778A1 (en) * 2014-06-16 2015-12-17 Bank Of America Corporation Cryptocurrency electronic payment system

Citations (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5724424A (en) * 1993-12-16 1998-03-03 Open Market, Inc. Digital active advertising
US6038552A (en) * 1997-12-10 2000-03-14 The Chase Manhattan Bank Method and apparatus to process combined credit and debit card transactions
US6189785B1 (en) * 1998-04-14 2001-02-20 International Check Services Demand deposit account data processing system
US20010032878A1 (en) * 2000-02-09 2001-10-25 Tsiounis Yiannis S. Method and system for making anonymous electronic payments on the world wide web
US20010034702A1 (en) * 2000-02-04 2001-10-25 Mockett Gregory P. System and method for dynamically issuing and processing transaction specific digital credit or debit cards
US6324525B1 (en) * 1996-06-17 2001-11-27 Hewlett-Packard Company Settlement of aggregated electronic transactions over a network
US20020026365A1 (en) * 2000-08-29 2002-02-28 Rony Natanzon Method and system for electronic payment and check guarantee
US20020040344A1 (en) * 2000-10-04 2002-04-04 Preiser Randall F. Check guarantee, verification, processing, credit reports and collection system and method awarding purchase points for usage of checks
US20020046169A1 (en) * 1999-10-01 2002-04-18 Cardinalcommerce Corporation Secure and efficient payment processing system
US20020062286A1 (en) * 1998-06-29 2002-05-23 Tedesco Daniel E. Method and apparatus for processing checks to reserve funds
US20020065774A1 (en) * 1999-11-30 2002-05-30 Alan Young System and method for performing an electronic transaction using a transaction proxy with an electronic wallet
US20020099652A1 (en) * 1999-04-15 2002-07-25 Rapid Prototypes, Inc. Electronically transmitted payment system
US20020099656A1 (en) * 2000-11-14 2002-07-25 Poh Wong Kenneth Tien Electronic funds transfer system for processing multiple currency transactions
US20020103753A1 (en) * 2001-01-31 2002-08-01 Michael Schimmel Charge splitter application
US20020120559A1 (en) * 2001-02-26 2002-08-29 O'mara Timothy L. Tiered processing method and system for identifying and mitigating merchant risk
US20020128917A1 (en) * 2001-03-06 2002-09-12 Electronic Data Systems Corporation Method and apparatus for processing financial transactions
US20020133412A1 (en) * 1997-03-07 2002-09-19 David M. Oliver System for management of transactions on networks
US20020138445A1 (en) * 2001-01-24 2002-09-26 Laage Dominic P. Payment instrument authorization technique
US6473500B1 (en) * 1998-10-28 2002-10-29 Mastercard International Incorporated System and method for using a prepaid card
US20020175207A1 (en) * 1998-08-06 2002-11-28 Forough Kashef Terminal software architecture for use with smart cards
US20030023549A1 (en) * 2001-06-27 2003-01-30 American Express Travel Related Services Company, Inc. Consolidated payment account system and method
US6601033B1 (en) * 2000-10-24 2003-07-29 Richard F. Sowinski Pollution credit method using electronic networks
US20030144935A1 (en) * 2002-01-30 2003-07-31 Sobek Michael F. Methods and systems for processing, accounting, and administration of stored value cards
US20030163432A1 (en) * 2002-02-26 2003-08-28 Cannon, Thomas Calvin System for inexpensively executing online purchases
US20030200184A1 (en) * 2002-04-17 2003-10-23 Visa International Service Association Mobile account authentication service
US20030208440A1 (en) * 2000-05-01 2003-11-06 Robert Harada International payment system and method
US6647376B1 (en) * 1998-10-09 2003-11-11 Henry C. Farrar System and method for point-of-sale check authorization
US20040034583A1 (en) * 2002-08-15 2004-02-19 Lanier Cheryl Lynn Systems and methods for performing electronic check commerce
US20040049452A1 (en) * 2002-09-09 2004-03-11 First Data Corporation Multiple credit line presentation instrument
US20040073509A1 (en) * 2000-05-15 2004-04-15 Sid Haddad Network communication electronic commerce system
US6732919B2 (en) * 2002-02-19 2004-05-11 Hewlett-Packard Development Company, L.P. System and method for using a multiple-use credit card
US20040167854A1 (en) * 2003-02-21 2004-08-26 Knowles W. Jeffrey System and method of currency conversion in financial transaction process
US20040210531A1 (en) * 2002-02-11 2004-10-21 Total System Services, Inc. System and method for single event authorization control of transactions
US20050075980A1 (en) * 2003-10-06 2005-04-07 Fontana Ralph G Check Assurance Protection System
US20050080728A1 (en) * 2002-01-30 2005-04-14 Sobek Michael F. Methods and systems for processing, accounting, and administration of stored value cards
US20050086169A1 (en) * 2001-12-07 2005-04-21 Wells Jonathan B. Electronic purchasing method and apparatus for performing the same
US6892184B1 (en) * 2000-06-19 2005-05-10 E4X Inc. System and method for multiple currency transactions
US20050177447A1 (en) * 2004-02-11 2005-08-11 Tradebeam, Inc. Systems and methods to support approval to settle an international trade from a credit facility, such as a line of credit or a demand deposit account
US20050203843A1 (en) * 2004-03-12 2005-09-15 Wood George L. Internet debit system
US20050228750A1 (en) * 2004-04-13 2005-10-13 Hugo Olliphant Method and system for facilitating merchant-initiated online payments
US6999943B1 (en) * 2000-03-10 2006-02-14 Doublecredit.Com, Inc. Routing methods and systems for increasing payment transaction volume and profitability
US20060036538A1 (en) * 2004-08-12 2006-02-16 Wanda Griffis Systems and methods for improved merchant processing
US7006993B1 (en) * 1999-05-28 2006-02-28 The Coca-Cola Company Method and apparatus for surrogate control of network-based electronic transactions
US20060229977A1 (en) * 2005-04-08 2006-10-12 Ebay Inc. Authorization and capture with multiple currencies
US20080052235A1 (en) * 2004-04-28 2008-02-28 First Data Corporation Methods And Systems For Providing Guaranteed Merchant Transactions
US7383223B1 (en) * 2000-09-20 2008-06-03 Cashedge, Inc. Method and apparatus for managing multiple accounts
US7401731B1 (en) * 2005-05-27 2008-07-22 Jpmorgan Chase Bank, Na Method and system for implementing a card product with multiple customized relationships
US7546945B1 (en) * 2005-12-09 2009-06-16 Capital One Financial Corporation System and method for managing transactions
US20090265249A1 (en) * 1999-11-05 2009-10-22 American Express Travel Related Services Company, Inc. Systems and methods for split tender transaction processing
US7610233B1 (en) * 1999-12-22 2009-10-27 Accenture, Llp System, method and article of manufacture for initiation of bidding in a virtual trade financial environment
US7729984B1 (en) * 2002-09-27 2010-06-01 Abas Enterprises Llc Effecting financial transactions
US7890422B1 (en) * 2001-07-24 2011-02-15 Jpmorgan Chase Bank, N.A. Multiple account advanced payment card and method of routing card transactions
US8099361B1 (en) * 2003-08-04 2012-01-17 Amazon.Com, Inc. Transaction processing system that applies user-specified rules to divide payment amounts among multiple payment instruments
US20140012760A1 (en) * 1999-10-01 2014-01-09 Cardinalcommerce Corporation Secure and efficient payment processing system

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0949596A3 (en) * 1998-03-30 2003-01-08 Citibank, N.A. Method and system to perform electronic value exchange and settlement among heterogeneous payment schemes with heterogeneous currencies
US20020102917A1 (en) * 2001-01-30 2002-08-01 Chih-Hung Lee Polishing method using dynamic feedback recipe

Patent Citations (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5724424A (en) * 1993-12-16 1998-03-03 Open Market, Inc. Digital active advertising
US6324525B1 (en) * 1996-06-17 2001-11-27 Hewlett-Packard Company Settlement of aggregated electronic transactions over a network
US20020133412A1 (en) * 1997-03-07 2002-09-19 David M. Oliver System for management of transactions on networks
US6038552A (en) * 1997-12-10 2000-03-14 The Chase Manhattan Bank Method and apparatus to process combined credit and debit card transactions
US6189785B1 (en) * 1998-04-14 2001-02-20 International Check Services Demand deposit account data processing system
US20020062286A1 (en) * 1998-06-29 2002-05-23 Tedesco Daniel E. Method and apparatus for processing checks to reserve funds
US20020175207A1 (en) * 1998-08-06 2002-11-28 Forough Kashef Terminal software architecture for use with smart cards
US6808111B2 (en) * 1998-08-06 2004-10-26 Visa International Service Association Terminal software architecture for use with smart cards
US6647376B1 (en) * 1998-10-09 2003-11-11 Henry C. Farrar System and method for point-of-sale check authorization
US6473500B1 (en) * 1998-10-28 2002-10-29 Mastercard International Incorporated System and method for using a prepaid card
US20020099652A1 (en) * 1999-04-15 2002-07-25 Rapid Prototypes, Inc. Electronically transmitted payment system
US7006993B1 (en) * 1999-05-28 2006-02-28 The Coca-Cola Company Method and apparatus for surrogate control of network-based electronic transactions
US20120191609A1 (en) * 1999-10-01 2012-07-26 Cardinalcommerce Corporation Secure and efficient payment processing system
US20140012760A1 (en) * 1999-10-01 2014-01-09 Cardinalcommerce Corporation Secure and efficient payment processing system
US20020046169A1 (en) * 1999-10-01 2002-04-18 Cardinalcommerce Corporation Secure and efficient payment processing system
US20090265249A1 (en) * 1999-11-05 2009-10-22 American Express Travel Related Services Company, Inc. Systems and methods for split tender transaction processing
US20020065774A1 (en) * 1999-11-30 2002-05-30 Alan Young System and method for performing an electronic transaction using a transaction proxy with an electronic wallet
US7610233B1 (en) * 1999-12-22 2009-10-27 Accenture, Llp System, method and article of manufacture for initiation of bidding in a virtual trade financial environment
US20010034702A1 (en) * 2000-02-04 2001-10-25 Mockett Gregory P. System and method for dynamically issuing and processing transaction specific digital credit or debit cards
US20010032878A1 (en) * 2000-02-09 2001-10-25 Tsiounis Yiannis S. Method and system for making anonymous electronic payments on the world wide web
US6999943B1 (en) * 2000-03-10 2006-02-14 Doublecredit.Com, Inc. Routing methods and systems for increasing payment transaction volume and profitability
US20030208440A1 (en) * 2000-05-01 2003-11-06 Robert Harada International payment system and method
US20040073509A1 (en) * 2000-05-15 2004-04-15 Sid Haddad Network communication electronic commerce system
US6892184B1 (en) * 2000-06-19 2005-05-10 E4X Inc. System and method for multiple currency transactions
US20020026365A1 (en) * 2000-08-29 2002-02-28 Rony Natanzon Method and system for electronic payment and check guarantee
US7383223B1 (en) * 2000-09-20 2008-06-03 Cashedge, Inc. Method and apparatus for managing multiple accounts
US20020040344A1 (en) * 2000-10-04 2002-04-04 Preiser Randall F. Check guarantee, verification, processing, credit reports and collection system and method awarding purchase points for usage of checks
US6601033B1 (en) * 2000-10-24 2003-07-29 Richard F. Sowinski Pollution credit method using electronic networks
US20020099656A1 (en) * 2000-11-14 2002-07-25 Poh Wong Kenneth Tien Electronic funds transfer system for processing multiple currency transactions
US20020138445A1 (en) * 2001-01-24 2002-09-26 Laage Dominic P. Payment instrument authorization technique
US20020103753A1 (en) * 2001-01-31 2002-08-01 Michael Schimmel Charge splitter application
US20020120559A1 (en) * 2001-02-26 2002-08-29 O'mara Timothy L. Tiered processing method and system for identifying and mitigating merchant risk
US20020128917A1 (en) * 2001-03-06 2002-09-12 Electronic Data Systems Corporation Method and apparatus for processing financial transactions
US20030023549A1 (en) * 2001-06-27 2003-01-30 American Express Travel Related Services Company, Inc. Consolidated payment account system and method
US7890422B1 (en) * 2001-07-24 2011-02-15 Jpmorgan Chase Bank, N.A. Multiple account advanced payment card and method of routing card transactions
US20050086169A1 (en) * 2001-12-07 2005-04-21 Wells Jonathan B. Electronic purchasing method and apparatus for performing the same
US20030144935A1 (en) * 2002-01-30 2003-07-31 Sobek Michael F. Methods and systems for processing, accounting, and administration of stored value cards
US20050080728A1 (en) * 2002-01-30 2005-04-14 Sobek Michael F. Methods and systems for processing, accounting, and administration of stored value cards
US20040210531A1 (en) * 2002-02-11 2004-10-21 Total System Services, Inc. System and method for single event authorization control of transactions
US6732919B2 (en) * 2002-02-19 2004-05-11 Hewlett-Packard Development Company, L.P. System and method for using a multiple-use credit card
US20030163432A1 (en) * 2002-02-26 2003-08-28 Cannon, Thomas Calvin System for inexpensively executing online purchases
US20030200184A1 (en) * 2002-04-17 2003-10-23 Visa International Service Association Mobile account authentication service
US20040034583A1 (en) * 2002-08-15 2004-02-19 Lanier Cheryl Lynn Systems and methods for performing electronic check commerce
US20040049452A1 (en) * 2002-09-09 2004-03-11 First Data Corporation Multiple credit line presentation instrument
US7729984B1 (en) * 2002-09-27 2010-06-01 Abas Enterprises Llc Effecting financial transactions
US20040167854A1 (en) * 2003-02-21 2004-08-26 Knowles W. Jeffrey System and method of currency conversion in financial transaction process
US8099361B1 (en) * 2003-08-04 2012-01-17 Amazon.Com, Inc. Transaction processing system that applies user-specified rules to divide payment amounts among multiple payment instruments
US20050075980A1 (en) * 2003-10-06 2005-04-07 Fontana Ralph G Check Assurance Protection System
US20050177447A1 (en) * 2004-02-11 2005-08-11 Tradebeam, Inc. Systems and methods to support approval to settle an international trade from a credit facility, such as a line of credit or a demand deposit account
US20050203843A1 (en) * 2004-03-12 2005-09-15 Wood George L. Internet debit system
US20050228750A1 (en) * 2004-04-13 2005-10-13 Hugo Olliphant Method and system for facilitating merchant-initiated online payments
US20080052235A1 (en) * 2004-04-28 2008-02-28 First Data Corporation Methods And Systems For Providing Guaranteed Merchant Transactions
US20060036538A1 (en) * 2004-08-12 2006-02-16 Wanda Griffis Systems and methods for improved merchant processing
US7734544B2 (en) * 2005-04-08 2010-06-08 Ebay Inc. Authorization and capture with multiple currencies
US20100223178A1 (en) * 2005-04-08 2010-09-02 Joerg Schleicher Authorization and capture with multiple currencies
US20060229977A1 (en) * 2005-04-08 2006-10-12 Ebay Inc. Authorization and capture with multiple currencies
US7401731B1 (en) * 2005-05-27 2008-07-22 Jpmorgan Chase Bank, Na Method and system for implementing a card product with multiple customized relationships
US7546945B1 (en) * 2005-12-09 2009-06-16 Capital One Financial Corporation System and method for managing transactions

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
1995 Software Guide: Conveying the Message Faster, More Efficiently. July 1995. Direct Marketing. Volume 58 Issue 3 Page 38 *
Alaska Financial Systems Reconciler Documentation. March 2004. http://www.alaska.edu/financial-systems/ua-procurement-card/recon.pdf *
FutureQuest Inc FAQ Website. 03 August 2001.http://web.archive.org/web/20010803104746/http://www.futurequest.net/Services/Guarantee/ *
Kasavana, Michael. Technical Support: The Point of Club Point of Sale Systems. October 2001. Club Management. Volume 80 Issue 5 page 92 *
Pearson Australia Chapter 4 Answers for Course entitled Heinemann Information Processes and Technology; HSC Course. 03 June 2003. http://wayback.archive.org/web/20030815000000*/http://www.hi.com.au/infoprocess/pdf/Ansch04.doc *
Power, Denise. Gift Cards: A Mixed Blessing? 08 December 2004. Women's Wear Daily. Volumne 188 Issue 119 Page 16 *

Cited By (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110167002A1 (en) * 2002-06-12 2011-07-07 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US20140081863A1 (en) * 2002-06-12 2014-03-20 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US8645266B2 (en) * 2002-06-12 2014-02-04 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US8650118B2 (en) 2002-06-12 2014-02-11 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US20060178999A1 (en) * 2005-02-10 2006-08-10 Rust Langbourne W Fee determination device
US7272582B2 (en) 2005-02-10 2007-09-18 Data Gater, Llc Fee determination device
US7734544B2 (en) 2005-04-08 2010-06-08 Ebay Inc. Authorization and capture with multiple currencies
US20100223178A1 (en) * 2005-04-08 2010-09-02 Joerg Schleicher Authorization and capture with multiple currencies
US8671061B2 (en) * 2005-08-03 2014-03-11 Tp Lab, Inc. System, method and apparatus for conducting a secure transaction over a call
US20070260555A1 (en) * 2005-08-03 2007-11-08 Tp Lab System, method and apparatus for conducting a secure transaction over a call
US9460430B1 (en) * 2005-08-03 2016-10-04 Tp Lab, Inc. System, method and apparatus for conducting secure transaction over a call
US7873573B2 (en) 2006-03-30 2011-01-18 Obopay, Inc. Virtual pooled account for mobile banking
US20070230371A1 (en) * 2006-03-30 2007-10-04 Obopay Inc. Data Communications Over Voice Channel With Mobile Consumer Communications Devices
US20070255620A1 (en) * 2006-03-30 2007-11-01 Obopay Inc. Transacting Mobile Person-to-Person Payments
US20080032741A1 (en) * 2006-03-30 2008-02-07 Obopay Programmable Functionalities for Mobile Consumer Communications Devices with Identification-Modules
US20070255653A1 (en) * 2006-03-30 2007-11-01 Obopay Inc. Mobile Person-to-Person Payment System
US20090119190A1 (en) * 2006-03-30 2009-05-07 Obopay Inc. Virtual Pooled Account for Mobile Banking
US20070255662A1 (en) * 2006-03-30 2007-11-01 Obopay Inc. Authenticating Wireless Person-to-Person Money Transfers
US8532021B2 (en) 2006-03-30 2013-09-10 Obopay, Inc. Data communications over voice channel with mobile consumer communications devices
US7702559B2 (en) * 2006-05-12 2010-04-20 Ebay Inc. Methods and apparatus for funding transactions
US7765154B2 (en) * 2006-05-12 2010-07-27 Ebay Inc. Methods and apparatus for funding transactions using debit cards issued by one institution and funds from accounts at other institutions
US20100205097A1 (en) * 2006-05-12 2010-08-12 Shah Dimple B Methods and apparatus for funding transactions using debit cards issued by one institution and funds from accounts at other institutions
US20140149284A1 (en) * 2006-05-12 2014-05-29 Ebay Inc. Methods and apparatus for funding transactions using debit cards issued by one institution and funds from accounts at other institutions
US8666889B2 (en) * 2006-05-12 2014-03-04 Ebay, Inc. Methods and apparatus for funding transactions using debit cards issued by one institution and funds from accounts at other institutions
US20080162342A1 (en) * 2006-05-12 2008-07-03 Ebay Inc. Methods and apparatus for funding transactions using debit cards issued by one institution and funds from accounts at other institutions
US20070265961A1 (en) * 2006-05-12 2007-11-15 Ebay Inc. Methods and apparatus for funding transactions
US8249987B2 (en) * 2006-05-12 2012-08-21 Ebay Inc. Methods and apparatus for funding transactions using debit cards issued by one institution and funds from accounts at other institutions
US20120317031A1 (en) * 2006-05-12 2012-12-13 Ebay Inc. Methods and apparatus for funding transactions using debit cards issued by one institution and funds from accounts at other institutions
US8392328B2 (en) * 2006-05-12 2013-03-05 Ebay Inc. Methods and apparatus for funding transactions using debit cards issued by one institution and funds from accounts at other institutions
US20080183590A1 (en) * 2007-01-29 2008-07-31 Antoni Drudis Methods for providing secure eCommerce transactions
US8108266B2 (en) 2007-01-29 2012-01-31 Hewlett-Packard Development Company, L.P. Methods for providing secure eCommerce transactions
US20080189164A1 (en) * 2007-02-01 2008-08-07 Microsoft Corporation Reputation assessment via karma points
US8620822B2 (en) * 2007-02-01 2013-12-31 Microsoft Corporation Reputation assessment via karma points
US20080270301A1 (en) * 2007-04-27 2008-10-30 American Express Travel Related Services Co., Inc. Mobile payment system and method
US9307341B2 (en) 2007-04-27 2016-04-05 Iii Holdings 1, Llc Payment application download to mobile phone and phone personalization
US20080270302A1 (en) * 2007-04-27 2008-10-30 American Express Travel Related Services Co., Inc. User experience on mobile phone
US8543496B2 (en) 2007-04-27 2013-09-24 American Express Travel Related Services Company, Inc. User experience on mobile phone
US8620260B2 (en) 2007-04-27 2013-12-31 American Express Travel Related Services Company, Inc. Payment application download to mobile phone and phone personalization
US20080270300A1 (en) * 2007-04-27 2008-10-30 American Express Travel Related Services Company, Inc. System and method for performing person-to-person funds transfers via wireless communications
US8688570B2 (en) 2007-04-27 2014-04-01 American Express Travel Related Services Company, Inc. System and method for performing person-to-person funds transfers via wireless communications
US20080268811A1 (en) * 2007-04-27 2008-10-30 American Express Travel Related Services Co., Inc. Payment application download to mobile phone and phone personalization
US9866989B2 (en) 2007-04-27 2018-01-09 Iii Holdings 1, Llc Payment application download to mobile phone and phone personalization
US8762210B2 (en) 2008-06-03 2014-06-24 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
US20100036770A1 (en) * 2008-08-07 2010-02-11 Mastercard International, Inc. Method for providing a credit cardholder with multiple funding options
US9858554B2 (en) * 2008-08-07 2018-01-02 Mastercard International, Inc. Method for providing a credit cardholder with multiple funding options
US20130218728A1 (en) * 2008-08-10 2013-08-22 Rick Dan Hashop Virtual on-line pre-shopping system and method
US20140304143A1 (en) * 2008-09-11 2014-10-09 Certegy Check Services, Inc. Electronic check cashing system
US20100332351A1 (en) * 2009-06-30 2010-12-30 Ebay Inc. Same screen quick pay button
US20130103583A1 (en) * 2011-10-25 2013-04-25 Bank Of America Corporation Universal Cash Account
US20130198074A1 (en) * 2012-02-01 2013-08-01 Mastercard International, Inc. System and method for pre-purchasing gasoline
US20130238457A1 (en) * 2012-03-12 2013-09-12 Turkcell Teknoloji Arastirma Ve Gelistirme Anonim Sirketi Remote Payment System and Method
US9710806B2 (en) 2013-02-27 2017-07-18 Fiserv, Inc. Systems and methods for electronic payment instrument repository
US9721253B2 (en) 2015-05-06 2017-08-01 Forter Ltd. Gating decision system and methods for determining whether to allow material implications to result from online activities

Also Published As

Publication number Publication date Type
US20160292654A1 (en) 2016-10-06 application
US7734544B2 (en) 2010-06-08 grant
US20100223178A1 (en) 2010-09-02 application
US20060229977A1 (en) 2006-10-12 application
WO2006110525A3 (en) 2007-11-08 application
WO2006110525A2 (en) 2006-10-19 application

Similar Documents

Publication Publication Date Title
US6892184B1 (en) System and method for multiple currency transactions
US7593898B1 (en) Method and system for payment transactions and shipment tracking over the internet
US6609113B1 (en) Method and system for processing internet payments using the electronic funds transfer network
US6704714B1 (en) Virtual private lock box
US7177836B1 (en) Method and system for facilitating financial transactions between consumers over the internet
US20050283416A1 (en) Method and system for providing assurance and financing services
US20020069122A1 (en) Method and system for maximizing credit card purchasing power and minimizing interest costs over the internet
US20070239556A1 (en) System and method for facilitating transactions through a network portal
US20050144071A1 (en) Method and apparatus to facilitate the electronic accumulation and redemption of a value in an account
US20050108104A1 (en) Integrating third party shopping cart applications with an online payment service
US20100114733A1 (en) Party Payment System
US7698240B1 (en) System and method for providing electronic financial transaction services
US6932268B1 (en) Dual mode credit card based payment technique
US20080120218A1 (en) Method and system for using payment history for conducting commercial transactions
US20070118476A1 (en) System and method to automate payment for a commerce transaction
US20030212609A1 (en) Method of facilitating a transaction between a buyer and at least one seller
US20120158654A1 (en) Receipt storage in a digital wallet
US20020161707A1 (en) Method and system for multi-currency escrow service for web-based transactions
US7499875B1 (en) Method and apparatus for facilitating online payment transactions in a network-based transaction facility using multiple payment instruments
US20060143109A1 (en) Method and system of listing an item in a fixed-price section
US20080162347A1 (en) System and method for effecting auction item payments through a network portal
US20120166333A1 (en) Digital wallet
US7689487B1 (en) Computer-assisted funds transfer system
US7426492B1 (en) Systems and methods for facilitating commercial transactions between parties residing at remote locations
US20120011063A1 (en) Virtual wallet account with automatic-loading

Legal Events

Date Code Title Description
AS Assignment

Owner name: PAYPAL INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SCHLEICHER, JOERG;REEL/FRAME:016461/0328

Effective date: 20050408