Online exchange for payment transaction auctions

Disclosed are method and apparatus that host auctions for completing payment transactions that benefit a party of the transactions. The technique transmits bidding invitations for completing a payment transaction to multiple payment processors. Among the received auction bids, the technique selects a winning bid from an individual payment processor that offers a best benefit to a party involved in the payment transaction (e.g., a consumer or a merchant). Through the auction process, the technique enables a cost-effective routing for completing the payment transaction.

BACKGROUND

The traditional manner of paying a merchant using a payment account (e.g., a credit card) is inefficient and costly to both merchants and consumers. For instance, when a consumer wishes to pay for an item at a merchant's place of business by using a credit card, the consumer typically runs the credit card through a card reader at the merchant's point-of-sale (POS) terminal. The merchant's POS terminal submits a transaction request to an acquirer, who authorizes or declines the transaction. The merchant typically stores all of the day's authorized transactions in a batch, and sends the batch to the acquirer at the end of the day to receive payment. The acquirer sends the batch to a card network (e.g., VISA or MasterCard), which distributes the transactions to credit card issuers. The credit card issuers transfer the transaction amounts through the card network to the acquirer, who in turn pays the merchant.

Through the credit card transaction process, the acquirer, the card network and the credit card issuers may charge fees (e.g., interchange fees, assessment fees, or discount fees) for executing the transactions. The merchant ultimately receives a payment that has these fees subtracted from the corresponding total transaction amounts. This places a financial burden on the merchant for accepting credit card payments. The merchant has no ability to reduce the fees because he has little control on how the credit card transactions are routed and executed. The merchant therefore typically transfers at least some of the financial burden to the consumer by factoring the fees into the product price.

DETAILED DESCRIPTION

Introduced here is a technique that enables more efficient execution of payment transactions by use of an auction mechanism. The technique provides cost-effective processing of payment transactions, by encouraging payment processors to offer competing bidding proposals for executing the payment transactions. The bidding proposals from the payment processors have flexibility not only on the processing fee rate or reward incentives, but also on choosing the processing route of the payment transactions. For instance, to minimize the processing fee, a bidding proposal may propose executing a payment transaction by transferring funds from a particular payment account of the payer to a particular account of the payee, where both accounts are issued by the same financial institute.

According to the technique introduced here, a payment exchange server selects a winner from among one or more bidding proposals from one or more payment processors, based on the benefit to a party involved in the payment transaction (e.g., the payer, the payee, or an entity operating or owning the payment exchange server). For instance, the payment exchange server can select the bid of a payment processor who offers to charge the lowest processing fee. After receiving an authorization from the payment exchange server, the winning payment processor executes the payment transaction as proposed (an operation referred to as “clear” or “complete”). As a result, the payee (e.g., a merchant) of the transaction receives the payment and benefits from the reduced processing fee. The technique introduced here can be implemented by, for example, a mobile device for online payment, a dedicated server for routing payment transactions, a cloud server acting as a market maker for payment transaction auctions, or a combination thereof.

In the following description, the example of a customer purchasing a product from a retailer is discussed, for illustrative purpose only, to explain various aspects of the technique. Note, however, that the technique introduced here is not limited in applicability to a retailer or to any other particular kind of business. Additionally, the technique introduced here is not limited to use with payment cards. The technique can be employed with essentially any transaction that traditionally would be initiated by or involve the use of a card or a financial account. Hence, the term “transaction” refers to any type of payment-oriented transaction, including a lease or rental for example, and is not limited to an actual purchase. Note also that in this description, the term “user” generally refers to a customer or a consumer (as opposed to a merchant), except where otherwise indicated, and except that the term “user interface” does not necessarily refer to an interface used by a customer, as will be apparent from the context. Additionally, the term “sale”, such as in “point-of-sale” (POS), refers to any type of payment-oriented transaction, including a lease or rental for example, and is not limited to an actual purchase.

In certain embodiments, the technique introduced here involves the following sequence of actions, as described more fully below. Initially, a customer visits a retailer and tries to purchase a product by swiping a payment card (e.g., a credit card) through a card reader of the POS system of the retailer. The POS system transfers metadata of the purchase transaction including, e.g., product price, sales tax amount, customer identification (e.g., name, card number, social security number, or phone number), retailer identification, to a payment exchange server. The payment exchange server identifies available payment accounts of the customer based on the customer identification information, as well as available receiving accounts of the retailer based on the retailer identification information. The payment exchange server sets up and manages an auction for executing the purchase transaction, including sending bidding invitations to various payment processors. The bidding invitations can include some of the metadata sent by the POS system, and/or the payment accounts and the receiving accounts identified by the payment exchange server.

Based on a bidding invitation, a payment processor decides whether to bid and accordingly may send a bid to the payment exchange server. The bid proposes a routing of the purchase transaction from a particular payment account of the customer to a particular receiving account of the retailer. The bid specifies the amount of processing fee (which can be zero) that the payment processor will charge for completing the transaction. The bid may further propose an additional reward incentive, such as offering loyalty points or a rebate to the retailer or the customer.

The payment exchange server collects the bids from the payment processors within a specific limited time period. The payment exchange server can select, as the winning bid, the bid that offers to charge the least amount of processing fee among the received bids, for example. If the winning bid proposes to charge a payment account of the customer that is not associated with the payment card being swiped, the payment exchange server may instruct the POS system to prompt the customer to decide whether to use that payment account for the purchase. The POS system may additionally present a reward incentive proposed by the winning bid, to encourage the customer to use the payment account proposed by the winning bid (instead of using an account associated with the swiped payment card). The payment exchange server then proceeds to authorize the winning payment processor to execute the purchase transaction.

Once the purchase transaction is successfully executed, the payment exchange server forwards a confirmation message from the payment processor to the POS system. The whole auction and execution process can happen in a short time period, such as three seconds, so that the customer may finish the purchase like a traditional credit card transaction without perceiving any delay.

In alternative embodiments, the payment exchange server can select a winning bid based on the benefit to a party other than the retailer. For instance, the payment exchange server can select a winning bid that offers a reward incentive that interests the customer, based on the value of the reward incentive and the customer's history of purchasing. For example, a customer may be particularly interested in accumulating frequent flyer program miles, such that the winning bid may be a bid that offers double miles for the purchase transaction.

FIG. 1illustrates an environment in which the payment transaction auction exchange technology can be implemented. The environment includes a merchant point-of-sale (POS) system104of a merchant100and a mobile device102of a user101(also referred to as “customer” or “consumer”). The mobile device102can be, for example, a smart phone, tablet computer, notebook computer, or any other form of mobile processing device. A mobile payment application120runs on the consumer's mobile device102. The environment also includes a computer system108of a payment exchange organization (hereinafter “payment exchange system108”), and computer systems114,116and118of various payment processors (hereinafter “payment processor systems114,116and118”). Each of the aforementioned computer systems can include one or more distinct physical computers and/or other processing devices which, in the case of multiple devices, can be connected to each other through one or more wired and/or wireless networks.

The POS system104and the mobile device102can be coupled to the payment exchange system108through an internetwork106, which can be or include the Internet and one or more wireless networks (e.g., a WiFi network and or a cellular telecommunications network). The payment processor systems114,116and118can be coupled to the payment exchange system108through the internetwork106as well. Alternatively, the payment processor systems114,116and118can be coupled to the payment exchange system108through one or more dedicated networks, such as the Automated Clearing House (ACH) network.

The environment illustrated inFIG. 1can accommodate both traditional payment card transactions (i.e., those involving reading of physical card of the customer at the merchant's location), as well as cardless transactions that are authorized on electronic devices. In a traditional credit or debit card transaction, for example, the merchant swipes the user's credit or debit card through a card reader at the POS system104. The POS system104sends data read from the card (e.g., the cardholders name, credit card number, expiration date and card verification value (CVV) or debit card password) and transaction information (e.g., transaction amount, merchant identification, purchasing item, transaction limitation, etc.) to the payment exchange system108.

Alternatively, a cardless transaction can be authorized by using the consumer's mobile device102. Using the mobile payment application120running on the consumer's mobile device102, the consumer101can specify the details of the transaction (e.g., merchant identification, transaction amount, purchasing item, payment method preference, etc.) and authorize the transaction payment. The mobile device102can communicate with the payment exchange system108over internetwork106. Information about the transaction (i.e., transaction metadata or “transaction information”) is transferred to the payment exchange system108.

In response to the transaction information, the payment exchange system108sends bidding invitations for the payment transaction to various payment processor systems114,116and118. The bidding invitations can include some or all of the card data and transaction information. The payment exchange system180receives bids from at least some of the payment processor systems114,116and118, and determines a winning bid from among the bids received. The payment exchange system180then sends an authorization for executing the payment transaction to the winning payment processor. The winning payment processor of the auction executes to complete (i.e., clear) the payment transaction.

The payment exchange system108can include one or more server computers programmed to stage payment transaction auctions. The payment exchange system108can also store information such as credit card numbers, debit card numbers, bank accounts, other user accounts, user identifying information or other sensitive information. The payment exchange system108can also be responsible for storing information about merchants who have accounts with the payment exchange system108.

FIG. 2illustrates an embodiment of the payment exchange system. Note that certain components that are not germane to this description may not be shown. The payment exchange system200includes a transaction intake and confirmation interface202, a database204, an auction staging module206, and a bidding and authorization interface208. The transaction intake and confirmation interface202communicates with the POS system104and/or mobile device102to receive metadata of the payment transaction between the consumer101and the merchant100. The metadata of the payment transaction can include information regarding the consumer101, the merchant100and the transaction itself. The metadata received may be in a format that is standard to the financial industry or the e-business industry, such as Open Financial Exchange (OFX), Interactive Financial Exchange (IFX), or eXtensible Business Reporting Language (XBRL). The transaction intake and confirmation interface202can include a format conversion module203for converting the received metadata into a format that is set as a standard format for the payment exchange system200. Alternatively, the format conversion module203can be part of the auction staging module206.

The payment transaction metadata (e.g., converted metadata) are stored in the database204. The database204can include data other than the transaction metadata. For instance, the database204can store information for payment accounts of the consumer101, such as credit card numbers, debit card numbers, bank accounts, online money transfer accounts, or home equity line of credit accounts. The database204can further store information regarding financial institutions or organizations that have conducted business or likely will conduct business with the consumer101. For instance, the database204may store information regarding that the consumer101has an automobile loan with a credit union, or that the consumer101has obtained umbrella insurance from an insurance company.

The database204can also store information regarding various payment processors. The database204may store information regarding the types of payment transactions a payment processor can handle. For instance, the payment processor of the system114may only be interested or specialized in executing payment transactions between U.S. merchants and German citizens residing in U.S.

In accordance with the technology introduced here, the auction staging module206(also referred to as “decision module”) sets up an auction for executing the payment transaction. The auction staging module206may specify rules of the auction. For instance, the rules can include a time period within which the payment processors can bid on the auction by responding to the bidding invitations, an upper or lower limit on processing fee that can be charged for executing the payment transaction, or a requirement that only payment processors that have existing business relationships with the consumer101can submit bids for a transaction involving the consumer101. Alternatively, a user or operator of the payment exchange system may specify the rules. The specified rules may be stored in a database (e.g., database204or a separate database) within the payment exchange system200.

The auction staging module206or a user of the payment exchange system200can decide the amount of information to be included in the bidding invitations. Depending on the requests from the merchant100, consumer101and the payment processors, the auction staging module206may decide to disclose minimal information that are necessary for the payment processors to bid on the auction, or enough information for the payment processors to clear the payment transaction, or even to disclose certain valuable information regarding the merchant100or the consumer101to attract bidding from the payment processors. The auction staging module206can also specify rules on what information will be available to the winning bidder. Thus, a payment processor may lower its processing fee or offer extra incentives to receive extra details of the transaction for business purposes such as marketing analysis.

In the illustrated embodiment, the auction staging module206includes a processor filtering module207. The processor filtering module207filters out payment processors that do not conform to the rules specified by the auction staging module206. For instance, if the auction staging module206specifies allowing bids only from the payment processors that have existing business relationships with the consumer101, payment processors that have no existing business relationships with the consumer101are filtered out. Similarly, if the auction staging module206specifies allowing bids only from banks with which the consumer101have accounts, other banks or institutes are filtered out from the auction. The processor filtering module207may directly select payment processors instead. The rules for filtering out or selecting payment processors may be instructed by the merchant100or the consumer101. For instance, the consumer101can set a requirement that the consumer only wants to pay for the transaction using one of his existing accounts (instead of, e.g., accepting an offer for opening a new financial account for paying the transaction). Accordingly the auction staging module206can set up a rule allowing bids only from payment processors that are capable of handling existing accounts of the consumer101.

Although the transaction intake and confirmation interface202and the bidding and authorization interface208are separate in the illustrated embodiment, alternatively the interfaces202and208can be implemented as a single interface, e.g., a networking interface.

The bidding and authorization interface208sends out bidding invitations to the remaining available payment processors that survive the filtering process. In response to the bidding invitations, one or more payment processors send back their bids to the bidding and authorization interface208. An auction bid can include a processing fee proposal for executing the payment transaction. An auction bid can also include an incentive proposal that offers an extra incentive (e.g., rebate, frequent flyer miles, coupon, discount, loyalty program points, gift, or a combination thereof) to the consumer101or the merchant100. The auction bid can also specify the routing to clear the payment transaction. For instance, the auction bid may propose to use one of the consumer's existing financial institute account to pay for the transaction, or propose to offer the consumer an new financial account (e.g., a credit account or loan account) to pay for the transaction.

The auction staging module206can specify or access an auction rule on how to decide the winning bidder. For instance, the auction staging module206may specify that the bid benefiting the consumer101the most wins, or that the bid benefiting the merchant100the most wins. Alternatively, the auction staging module206may specify that the bid benefiting an entity owning or operating the payment exchange system200the most wins. The auction staging module206may also specify an auction rule that consider the benefits of multiple parties including, e.g., the merchant100, the consumer101, or the owner or operator of the payment exchange system200. The bidding payment processors may or may not be aware of this auction rule, and therefore are not discouraged from bidding by the auction rule.

The auction staging module206may confirm the winning bid with the consumer101or merchant100. For instance, the payment exchange system200sends the winning bid to the POS system104or the mobile device102through the transaction intake and confirmation interface202. The consumer101or the merchant100can confirm and authorize the payment method proposed by the winning bid through the mobile device102or the POS system104.

Alternatively, the auction staging module206can allow the consumer101or the merchant100to decide the winning bid. The payment exchange system200sends the bids to the POS system104or the mobile device102through the transaction intake and confirmation interface202. The POS system104or the mobile device102can list the bids with the processing fee proposal, incentive proposal or other information regarding the bids. The consumer101or the merchant100can select a winning bid from the list. The POS system104or the mobile device102sends the choice of the winning bid back to the payment exchange system200through the interface202.

The auction staging module206proceeds to authorize the winning payment processor to execute the payment transaction according to the proposal of the winning bid. Once the payment transaction is cleared, the winning bidder (i.e., payment processor) confirms the successful payment transaction completion with the payment exchange system200through the bidding and authorization interface208. The payment exchange system200can forward the confirmation to the POS system104or the mobile device102.

The payment exchange system200can be implemented as a server or a computing device (e.g., a mobile device). For instance, when a mobile device functions as a payment exchange system, the mobile device may further include a user interface (e.g., interface400illustrated inFIG. 4) interacting with the consumer or the merchant.

FIG. 3illustrates an example of a process of initiating and setting up a payment transaction auction benefiting a consumer, according to a first embodiment of the technology introduced here. The process involves relationships between a computing device302, a payment exchange system304, and payment processors306,308and310. The payment exchange system304can be configured to send and receive communications to and from the computing device302. The communications can be encrypted using secure protocols built into the computing device302and the payment exchange system304.

The computing device302can be owned or operated, e.g., a consumer or a merchant. The payment transaction may be initiated by a consumer or a merchant interacting with the computing device302. The computing device302can be, e.g., a mobile device.

Initially, the computing device302creates a request for a purchase transaction (step310). The request may be created automatically, for example, when a button of a payment application on the computing device302is clicked. The request can include an identity of the merchant and an identity of the product that the consumer is purchasing.

The consumer can identify himself by entering identification information on the computing device302(step315). For instance, the consumer can log into a user account on the computing device302. Alternatively, the consumer can enter certain personal information, e.g., drive license number or social security number, into the computing device302to identify the consumer. Then the computing device320adds the consumer identification information to the request (step320).

Subsequently, the computing device302prompts the consumer to select a preferred payment method that is known to the computing device302(step325). The available payment methods can be previously stored in a user account accessible by the computing device302, for example. If the consumer selects a preferred payment method, the computing device302adds the information of the preferred payment method to the request. The computing device302may further provide the consumer options to decline, ignore, or skip the prompt.

The computing device302sends the request for the purchase transaction to the payment exchange system304(step330). The request may include existing payment methods of the consumer. Alternatively, the payment exchange system304has stored the existing payment methods of the consumer.

The payment exchange system determines whether there are available payment processors capable of handling payment methods of the consumer (step335). If there is no payment processor capable of handling the payment methods of the consumer, the payment exchange system304can send an error message to the computing device302indicative that the transaction request cannot be processed (step340).

When multiple payment processor are available to handle the request, the payment exchange system304sends bidding invitations to the payment processors306,308,310(step345). The bidding invitations may include metadata regarding the purchase transaction, such as the purchase price, item name, consumer identification and/or merchant identification.

Each of the payment processor306,308and310determines whether to bid on the auction for executing the payment transaction (step350). If a payment processor determines to bid, the payment processor generates a bid for the purchase transaction (step355). If the payment processor determines not to bid, the payment processor simply ignores the bidding invitation (step357). The bid proposes a payment method for the consumer involving a specific payment account of the consumer and a specific merchant account for receiving the payment for the merchant. The bid specifies the amount of processing fee or offers zero processing fee for executing the payment transaction. The bid can further propose an incentive, such as doubling the frequent flyer miles or offering a rebate. Note that the specific format and communication protocol of the bid are unimportant, as long as they are understood by the payment processors and the payment exchange system; that is, any known or convenient data format and/or communication protocol can be used.

The specific payment account of the consumer can be an existing account of the consumer, or a new payment account being offered by an entity associated with the payment processor. Similarly, the specific merchant account of the merchant can be an existing account of the merchant, or a new account being offered by an entity associated with payment processor.

Subsequently, the payment exchange system304receives the bids from the payment processors (step360). The payment exchange system304determines a winning bid from which the consumer benefits the most (step362). For example, the winning bid may be the bid that offers the consumer the largest amount of rebate, or the most frequent flyer miles, or the most loyalty program points.

The payment exchange system304then requests confirmation of the payment method of the winning bid with the consumer through the computing device302(step365). The consumer can confirm and authorize the payment method of the winning bid on the computing device302(step370). Additionally, the merchant may also confirm the merchant account proposed by the winning bid for receiving the payment on the computing device302. In case that the winning bid proposes offering a new account to the consumer or the merchant, the payment exchange system604may forward the offer to the computing system302so that the consumer or the merchant can decide whether to open the new account.

The payment exchange system304authorizes the winning payment processor to execute the purchase transaction (step375). Then the winning payment processor executes the purchase transaction (step380). The execution of the purchase transaction may involve, e.g., transferring the fund from a consumer account to a merchant account, charging the processing fee from the merchant (alternatively, from the consumer or the payment exchange system), and realizing the promised incentive.

The winning payment processor may confirm the execution of the purchase transaction with the payment exchange system304. The payment exchange system304may further forward the confirmation to the computing device302.

The steps can be performed in a short time period such that the consumer finishes the transaction instantly, i.e., in essentially the same amount of time that a traditional credit card transaction would take. For example, after the consumer logs into an account on the computing device302, the computing device302can immediately list various credit card account, debit card accounts and bank accounts that the consumer can use to make the purchase, along with the incentives proposed by the payment processors. The consumer chooses one of the accounts by clicking on the screen of the computing device302. The computing device302immediately confirms that the purchase transaction has been completed and that the incentive has been realized.

FIG. 4illustrates an example of a graphical user interface showing a list of payment methods along with incentives offered by payment processors. The top portion of the interface400shows various information regarding the purchase, such as product name or description, price, sales tax, and total amount. The interface400lists five buttons410,420,430,440and440for a consumer to determine the payment method. For instance, interface400shows a button410“My Black Credit Card (Recommended!)” along with a promotion message412“Double Your Frequent Flyer Miles!” The button410and the promotion message412correspond to a winning bid that proposes to execute the payment transaction by extracting funds from a credit card account (“My Black Credit Card”) and to offer double frequent flyer miles as an incentive for the consumer to choose the payment method.

Similarly, the button420“My Checking Account” and the promotion message422“10 Loyalty Program Pointes” correspond to a bid that proposes to execute the payment transaction by extracting funds from a checking account and to offer loyalty points as incentive. The button430“My HELOC Account” and the promotion message432“$0.20 Cash Rebate!” correspond to a bid that proposes to execute the payment transaction by extracting funds from a home equity line of credit (HELOC) account and to offer cash rebate as incentive. The button440“My Store Credit and Gift Card Account” and the promotion message442“Buy 1 Get 1 Coupon for Balloons!” correspond to a bid that proposes to execute the payment transaction by extracting funds from a store credit or gift card account and to offer a coupon as incentive. The button450“Open a New Loan Account” and the promotion message452“Interest Free for 12 Months!” correspond to a bid that proposes to execute the payment transaction by opening a new loan account and extracting funds from the loan account. The payment processor that proposes opening the new loan account further offers zero interests as incentive for the consumer to choose the payment method.

The consumer can click any of the buttons410,420,430,440and450to choose a payment method proposed by one of the bids. If the consumer clicks the button410, the computing device302sends a message back to the payment exchange system304to confirm executing the payment transaction according to the winning bid. If the consumer clicks a button other than the button410, the computing device302sends a message to the payment exchange system304to overwrite the winning bid, i.e., instructing the payment exchange system304to send authorization for executing the payment transaction to a payment processor that proposed a bid corresponding to the clicked button. The user interface may offer a specific time period for the consumer to respond. After the time period expires, the computing device302may either cancel the payment transaction request, or automatically confirm the winning bid.

FIG. 5Aillustrates an example of a transaction auction process that can be performed by the payment exchange system, according to the first embodiment. The process500illustrated inFIG. 5Acan be executed by, e.g., the payment exchange system304ofFIG. 3. The process500begins when the payment exchange system304receives a request for executing a payment transaction from the computing device302(step505). The request can include various metadata regarding the consumer, the merchant, and the product or service involved in the transaction. For instance, the metadata of the request can include a consumer identity, a merchant identity, a transaction identification, payment card information, purchasing item information, price, expiration time, currency, geographic location of the consumer, geographic location of the merchant, a consumer transaction history, or a risk estimation of the payment transaction.

The request is in response to a consumer action, e.g., swiping a consumer's payment card or initiating a payment authorization from a mobile payment application running on the computing device302. The payment card can be, e.g., a credit card, a debit card, or a proxy card associated with multiple payment accounts of the consumer. The payment authorization can be generated, for example, from a metacard or a virtual wallet. The mobile payment application can establish a virtual wallet for the consumer to store various payment accounts including, e.g., credit cards, debit cards, loyalty cards and gift cards. Similarly, the mobile payment application can establish a metacard for the consumer. A consumer can dynamically switch between payment accounts that are represented by the metacard.

After receiving the request for executing the payment transaction, the payment exchange system304identifies one or more payment accounts of the consumer based on the consumer identity and one or more receiving accounts of the merchant based on the merchant identity (step510). Then, the payment exchange system304determines whether the payment transaction satisfies criteria set by a particular payment processor (step515). If the payment transaction does not fit the criteria, the process500disregards the current payment processor and proceeds to identify the next payment processor (step520). If the payment transaction satisfies the criteria, the payment exchange server304generates and transmits a bidding invitation for the payment transaction to the particular payment processor (step525). This criteria mechanism allows payment processors that specializes in particular areas to participate the payment transaction auctions. For instance, a payment processor company may be specializing in high-risk payments because of their fraud detection system and high-return collection process. The payment processor company can set criteria to accept bidding invitations for high-risk payment transactions only. Thus, a market gap is filled, since otherwise likely no other processors want to handle these high-risk payment transactions.

The bidding invitation includes a subset of metadata that is enough for the payment processor to decide whether to bid on the payment transaction. The bidding invitation can further include the identified payment accounts of the consumer or the identified receiving accounts of the merchant. The payment processors may be represented by endpoint systems associated with payment processor entities, such as payment processing platforms, credit card companies, credit card networks, banks, or loan companies.

The process500proceeds to determine whether there are more payment processors potentially can participate the bidding (step530). If there are more payment processors, the process500proceeds to step520to identify the next payment processor for sending out more bidding invitations. When there are no more payment processors left for generating bidding invitations, the process500proceeds to step535. The bid invitations can be sent out sequentially or concurrently. For instance, the bidding invitations for different payment transactions can be transmitted to the payment processors in concurrent real-time data streams.

The payment exchange server304collects bids from the payment processors (step535). The bids can include proposals regarding processing fees and/or rewarding incentives relating to the payment transaction. A bid can further include a proposal of executing a payment transaction by transferring a fund from a particular payment account of the consumer to a particular receiving account of the merchant. The particular payment account may be one of the identified payment accounts of the consumer, or a new payment account being offered in the bid by the payment processor. Similarly, the particular receiving account may be one of the identified receiving accounts of the merchant, or a new receiving account being offered in the bid by the payment processor.

If the payment exchange server304determines that a specific time period for collecting bids has expired (step537), the process500stops collecting bids and proceeds to step540.

The payment exchange server304can further determine whether one of the identified payment accounts is issued by an operator (or owner) of the payment exchange system (step540). If there is an identified payment account issued by the operator, the payment exchange system can generate a bid for the payment transaction on behalf of the operator (step545). In this way, the operator of the payment exchange system can participate in the auction as a bidder as well.

The payment exchange server304determines a winning bid from among the collected bids based on a benefit to the consumer (step550). The benefit to the consumer can be measured by, e.g., the reward incentives proposed by the bids. For instance, a winning bid can be selected by determining a reward incentive that is likely to be of greatest interest to the consumer, based on a history of user inputs in response to bids of past payment transactions. In some alternative embodiments, the winning bid can be determined based on a benefit to another party involved in the payment transaction (e.g., the merchant or the operator), or based on a combination of the benefits to multiple parties.

The payment exchange server304forwards the winning bid to the computing device302to solicit a confirmation from the consumer (step555). The computing device302may present a recommendation based on the winning bid on a user interface component of the computing device302, along with other bids accompanied with the proposed rewarding incentives. The consumer may confirm the winning bid by clicking on the user interface component.

If a consumer confirmation of the winning bid is received (step560), the payment exchange server304sends an authorization for executing the payment transaction to the winning payment processor (step565).

FIG. 5Billustrates an example of a failure recovery process that can be performed by the payment exchange system, according to the first embodiment. The payment exchange server304receives a message from the winning payment processor that proposed the winning bid (step570). The payment exchange server304determines whether the message is a failure message or a success message, indicating a failure or success of executing the payment transaction, respectively (step575).

If the message is a failure message indicative of a failure of executing the payment transaction, the payment exchange server304excludes the original winning bid from further selection (step580). Then the payment exchange server304determines a second winning bid from among the collected bids based on a benefit to the consumer (585) and authorizes a payment processor that proposes the second winning bid to execute the payment transaction (590).

If the message is a success message, which is indicative of a success of executing the payment transaction, the payment exchange server304forwards the success message to the computing device302(step595).

FIG. 6illustrates an example of a process of initiating and setting up a payment transaction auction benefiting a merchant, according to a second embodiment of the technology introduced here. The process involves relationships between the merchant's POS system602, the payment exchange system604, and the payment processors606,608and610.

Initially, the merchant inputs the transaction information to the POS system602by, e.g., scanning a barcode of a product that the consumer is purchasing (step610). A display of the POS system602may visualize the name and the price of the product. Then a consumer can authorize the purchasing transaction and identifies himself by swiping his payment card through the POS system602(step615). The payment card can be a credit card, a debit card, a proxy card, or an identification card that identifies the consumer.

The POS system then generates a request of executing a payment transaction between the consumer and the merchant (step620). The request includes information identifying the consumer and the merchant and specifying the payment amount. The request may further include details of the transaction, e.g., the name or description of the product. The POS system602sends the request to the payment exchange system604(step625).

Additionally, the payment exchange system604generates auction rules (step630). For example, if the consumer prefers paying the transaction using credit cards, the auction rules may only allow participations of payment processors that are capable of handling credit card payments. The payment exchange system604selects candidate payment processors based on the auction rules (step640). For example, payment processors specializing in bank transferring or debit card processing may be excluded based on the auction rules if the consumer prefers credit card payment. Similarly, the payment exchange system604may exclude payment processors that cannot handle the merchant's payment accounts.

The payment exchange system604sends bidding invitations to the candidate payment processors (e.g., payment processors606,608and610) (step645). The bidding invitations do not necessarily include all information that the payment exchange system604receives from the POS system602. For example, the payment exchange system604may decide to send to the payment processors minimal information that is enough for the processors to bid on the auction. Alternatively, the payment exchange system604may decide to send to the payment processors details of the transaction, in order to attract more processors to bid on the auction. The bidding invitations can include information regarding existing accounts of the consumer and/or the merchant.

Each of the payment processor606,608and610determines whether to bid on the payment transaction auction (step650). If a payment processor determines to bid, the payment processor generates a bid for the auction (step655). The bid proposes executing the transaction by transferring a fund from a specific payment account of the consumer and a specific merchant account of the merchant.

The bid specifies the amount of processing fee (or even offers zero processing fee) based on the payment processor's ability of handling the fund transferring between these two specific account. For example, a bank account among the consumer's payment accounts and a bank account among the merchant accounts may be associated with the same bank. A payment processor associated with the same bank may be able to charge a low or even zero processing fee because of the low cost of transferring a fund between accounts within the same bank.

The payment exchange system604receives the bids from the payment processors (step658). The payment exchange system604then determines a winning bid from which the merchant benefits the most (step660). For example, the winning bid may be the bid that proposes to charge the merchant the least amount of processing fee (or zero processing fee). In some embodiments, the payment exchange system604may charge an additional commission fee to the payment processor, the merchant, the consumer, or multiple parties thereof.

The payment exchange system604may automatically authorize the winning payment processor to execute the payment transaction, without seeking further confirmation from the merchant or the consumer (step665). Alternatively, the payment exchange system604can seek confirmation of the winning bid from the merchant or the consumer through the POS system602. In case that the winning bid offers a new payment account, the payment exchange system604may forward the offer to the POS system602so that the consumer can decide whether to open the new account.

In response to the authorization from the payment exchange system604, the winning payment processor executes the payment transaction (step670). The execution of the payment transaction may involve, e.g., transferring a payment fund from a consumer account to a merchant account as proposed by the winning bid, charging the processing fee if there is one (e.g., by deducting the processing fee from the payment fund), and/or paying a commission fee to the payment exchange system604.

The winning payment processor may confirm the execution of the purchase transaction with the payment exchange system604. The payment exchange system304may forward the confirmation to the POS system602to acknowledge the completion of the payment transaction.

FIG. 7Aillustrates an example of a transaction auction process that can be performed by the payment exchange system, according to the second embodiment. The process700illustrated inFIG. 7Acan be executed by, e.g., the payment exchange system604ofFIG. 6. The process700begins when the payment exchange system604receives a request for executing a payment transaction from the POS system602(step705).

The payment exchange system604selects candidate payment processors from the available payment processors (step710). The payment transaction satisfies the criteria set by the candidate payment processors. The payment exchange server604generates bidding invitations for the payment transaction and transmits the bidding invitations to the candidate payment processors (step715). The bidding invitation can include a subset of metadata of the request that is enough for the payment processor to decide whether to bid on the payment transaction. The bidding invitations can further indicate that additional metadata of the payment transaction will be available to the winning payment processor. This gives the payment processors incentives to bid because the payment processors may have business interests in acquiring the additional metadata (e.g., for marketing research).

The payment exchange server604collects bids from the candidate payment processors within a time period (step720). The bids can include proposals regarding processing fees and/or rewarding incentives relating to the payment transaction. After the time period expires, the payment exchange server604determines a winning bid from among the collected bids based on a benefit to the merchant (step725). The benefit to the merchant can be measured by, e.g., the processing fees proposed by the bids. A bid proposing the least amount of processing fee can be selected as the winning bid.

In some alternative embodiments, the winning bid can be determined based on a benefit to another party involved in the payment transaction (e.g., the consumer or an owner of the payment exchange server604).

Then the payment exchange server604sends to the winning payment processor an authorization for executing the payment transaction to the winning payment processor (step730). If the payment exchange server604promised in the bidding invitations to supply additional metadata (step735), the payment exchange server604can transmit additional metadata regarding the purchase transaction to the wining payment processor (step740). The additional metadata may have business values to the winning payment processor (e.g. for marketing or consumer behavior research purposes).

FIG. 7Billustrates an example of an auction priority adjustment process that can be performed by the payment exchange system, according to the second embodiment. The consumer, the merchant or the payment exchange server604may set an upper limit for the number of bidding invitations being sent to the payment processors, for reasons such as efficiency or market regulation. When the upper limit is less than the number of available payment processors, payment processors with lower priorities may not get the chances to receive the bidding invitations. Thus, priorities of the payment processors for receiving bidding invitations sometimes dictate whether the payment processors are able to receive the invitations or not.

The process750begins when the payment exchange server604creates a classification database for storing information regarding priorities of the payment processors for receiving bidding invitations (step755). The payment exchange server604then records higher priorities for payment processors that have existing business relationships with the owner of the payment exchange system (step760). The payment exchange server604further records lower priorities for payment processors that have no existing business relationships with the owner of the payment exchange system (step765).

If the payment exchange server604receives an failure message indicative of a failure of executing a payment transaction by a payment processor (step770), the payment exchange server604lowers the priority of that payment processor for receiving bidding invitations (step775).

In some other embodiments, the payment exchange server604can set up priorities in different ways. For instance, the payment exchange server604may set higher priorities for payment processors having larger business. Alternatively, the payment exchange server604may set higher priorities for payment processors achieve less processing time for completing the payment transactions.

In some alternative embodiments, a payment exchange system can handle routing of payment transactions in non-bidding situations. For instance, a POS terminal can send a request for completing a payment transaction to the payment exchange system, when the POS terminal reads information of a payment card. Multiple financial institutes can be linked to the payment card via a hardware proxy service or a software proxy server.

The payment exchange system receives the request for completing the payment transaction. In response to the request, the system sends invitations for completing the payment transaction to the financial institutes, and receives proposals for completing the payment transaction from one or more of the financial institutes. A decision module of the system selects a proposal and generates an authorization for a financial institute that proposed the selected proposal to complete the payment transaction.

The proposals can include incentives benefiting various parties. For instance, an incentive can benefit a party of the payment transaction (e.g., the consumer) by offering, e.g., a promotional offer that relates to the payment transaction, an offer of reward points for the payment transaction, or a processing rate offer (meaning less fee charged by the merchant). Alternatively, an incentive can benefit a party operating the payment exchange system by offering, e.g., a processing rate offer, or a processing time quote. An incentive can include a combination of the offers.

The request for completing the payment transaction can include metadata that help the financial institutes in making decisions regarding the proposals. The metadata can include, e.g., a credit profile of a party of the payment transaction; an identification of a party of the payment transaction; information regarding whether a party of the payment transaction is physically present at the location where the request is generated by a POS terminal; information collected by a POS terminal that generates the request; or a combination thereof.

FIG. 8is a high-level block diagram showing an example of a processing device800that can represent any of the devices described above, such as the mobile device102, POS system104, payment exchange system108, payment processor system114,116or118, computing device302or payment exchange server304. As noted above, any of these systems may include two or more processing devices such as represented inFIG. 8, which may be coupled to each other via a network or multiple networks.

In the illustrated embodiment, the processing system800includes one or more processors810, memory811, a communication device812, and one or more input/output (I/O) devices813, all coupled to each other through an interconnect814. The interconnect814may be or include one or more conductive traces, buses, point-to-point connections, controllers, adapters and/or other conventional connection devices. The processor(s)810may be or include, for example, one or more general-purpose programmable microprocessors, microcontrollers, application specific integrated circuits (ASICs), programmable gate arrays, or the like, or a combination of such devices. The processor(s)810control the overall operation of the processing device800. Memory811may be or include one or more physical storage devices, which may be in the form of random access memory (RAM), read-only memory (ROM) (which may be erasable and programmable), flash memory, miniature hard disk drive, or other suitable type of storage device, or a combination of such devices. Memory811may store data and instructions that configure the processor(s)810to execute operations in accordance with the techniques described above. The communication device812may be or include, for example, an Ethernet adapter, cable modem, Wi-Fi adapter, cellular transceiver, Bluetooth transceiver, or the like, or a combination thereof. Depending on the specific nature and purpose of the processing device800, the I/O devices813can include devices such as a display (which may be a touch screen display), audio speaker, keyboard, mouse or other pointing device, microphone, camera, etc.

Unless contrary to physical possibility, it is envisioned that (i) the methods/steps described above may be performed in any sequence and/or in any combination, and that (ii) the components of respective embodiments may be combined in any manner.

The techniques introduced above can be implemented by programmable circuitry programmed/configured by software and/or firmware, or entirely by special-purpose circuitry, or by a combination of such forms. Such special-purpose circuitry (if any) can be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.

Note that any and all of the embodiments described above can be combined with each other, except to the extent that it may be stated otherwise above or to the extent that any such embodiments might be mutually exclusive in function and/or structure.