Authorization techniques

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

The invention relates generally to transaction processing and more particularly to techniques for automated and real-time authorization processing.

BACKGROUND

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.

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.

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).

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

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.

Other features will be apparent from the accompanying drawings and from the detailed description that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

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.

FIG. 1 is a diagram of an authorization and settlement system, according to an example embodiment.

FIG. 2 is a diagram of another authorization and settlement system, according to an example embodiment.

FIG. 3 is a diagram of a method for authorization and settlement, according to an example embodiment.

FIG. 4 is a diagram of another method for authorization and settlement, according to an example embodiment.

FIG. 5 is a diagram of yet another method for authorization and settlement, according to an example embodiment.

FIG. 6 is a diagram of example network-based commerce system or facility which implements various embodiments associated with the invention.

FIG. 7 is a diagram of example applications implemented within some of the components of the network-based commerce system of FIG. 6.

FIG. 8 is a diagram of machine architecture which implements various aspects of the invention, according to an example embodiment.

DETAILED DESCRIPTION

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.

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.

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.

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.

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.).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

A number of fraud prevention applications 714 implement fraud detection and prevention mechanisms to reduce the occurrence of fraud within the commerce system 610.

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).

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.

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.

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.

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.

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.

The software 824 may further be transmitted or received over a network 826 via the network interface device 820.

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.

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.

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.

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.

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

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. 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. 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. 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. The system of claim 1, wherein the authorization and settlement service permits multiple settlements for a single authorization.

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. 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. The system of claim 7, wherein the authorization and settlement means is adapted to perform multiple settlements for a single authorization.

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. 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. 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. 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. 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. 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. 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. 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. The method of claim 15 further including, re-authorizing the amount after a configurable period of time if a settlement has not occurred.

18. The method of claim 15 further including, processing multiple settlements for different portions of the amount.

19. The method of claim 15 further including, settling above the amount.

20. The method of claim 15 further including, voiding the authorization or any reauthorization after a configurable event is detected.

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. 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. The method of claim 22, wherein honoring further includes processing risk or fraud factors for the buyer before honoring the authorization request.

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. 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. 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. 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. 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. The method of claim 27 further including, making the merchant a merchant of record for a transaction associated with the authorization request.

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.