The disclosure relates to an online transaction infrastructure and processes. In particular, it relates to a transaction infrastructure allowing new capabilities for online transactions between consumers and merchants and methods of staging and performing transactions using such an infrastructure.
At present, online transactions are performed through transaction scheme providers (such as Mastercard, Visa and American Express) and through online payment providers (such as PayPal). Transactions using a transaction scheme provider typically use a four-party model—the customer uses a physical payment card associated with a customer account with an issuing bank, and the merchant receives funds from transactions in to a merchant account with an acquiring bank. The transaction scheme manages the performance of the transaction, including obtaining authorization as required from the issuing bank and arranging for clearing and settlement.
For online transactions, a payment gateway is used by a merchant to enable cardholder payment by use of a transaction scheme. Such payment gateways are typically provided by a payment service provider (PSP) with appropriate contractual, trust and technical relationships with merchants and banks.
If, as shown in
This model is effective, but it may not provide as full a range of payment options as the merchant may desire. In particular, the user is committed to making a full initial payment rather than a staged payment in instalments. Mechanisms for making instalment-based payments are available, but these will typically require significantly more setup than might be expected at an online store checkout.
In a first aspect, the disclosure provides a method of authorizing payment for an online transaction according to a credit plan using a payment scheme infrastructure, the method comprising at the payment scheme infrastructure: receiving from a credit issuer a real account number and a virtual account number for a credit plan for a transaction; receiving the transaction for authorization from a merchant gateway, wherein the transaction is completed for the virtual card number; using the virtual card number to obtain or confirm authorization for the credit plan, and recovering the real account number from the virtual card number to obtain authorization of the transaction from an issuer for the real account number; wherein the transaction is authorized if the credit plan is authorized and the transaction is authorized by the issuer for the real account number.
The transaction may further comprise an identifier in the transaction to indicate that it is associated with a credit plan, and the method further comprises using the identifier to identify the transaction as associated with a credit plan when it is received. The method may also further comprise further comprise checking eligibility for credit for the real account number when processing the transaction. The method may also further comprise further comprise providing an instalment code for the credit plan after successfully checking for eligibility for credit for the real account number.
In a second aspect, the disclosure provides a method of authorizing payment for an online transaction according to a credit plan using a payment scheme infrastructure, the method comprising a credit issuer: receiving from a customer a request for credit for a transaction together with customer information; determining whether to offer credit to the customer, and if so, providing a real account number for the customer and creating a virtual account number for a credit plan for the transaction; providing the virtual account number to the merchant and real account number and the virtual account number to the payment scheme infrastructure; authorizing the transaction, if the transaction is completed using the virtual account number and the credit plan is authorized, through an issuing bank associated with the credit issuer; and requesting payment from a customer for the transaction according to the credit plan.
If the customer has previously requested credit from the credit issuer, the credit issuer may then use the existing real account number for the customer but creates a new virtual card number for the credit plan.
In a third aspect, the disclosure provides a method of establishing and authorizing payment for an online transaction according to a credit plan using a payment scheme infrastructure, the method comprising a merchant: at an online checkout for a transaction, receiving a customer request for a credit plan for the transaction; causing the request for a credit plan and associated customer information to be provided to a credit issuer; if the request for a credit plan is accepted, receiving from the credit issuer a credit plan to present to the customer and a virtual card number for the credit plan; and if the customer accepts the credit plan, completing the transaction with the virtual card number and submitting the transaction for authorization.
Completing the transaction may further comprise including an identifier in the transaction to indicate that it is associated with a credit plan. The transaction may be completed with the virtual card number at a merchant payment gateway.
In a fourth aspect, the disclosure provides a payment scheme infrastructure adapted to authorize payment for an online transaction according to a credit plan, the payment scheme infrastructure being adapted to: receive from a credit issuer a real account number and a virtual account number for a credit plan for a transaction; on receiving a transaction for authorization from a merchant gateway completed for the virtual card number, to use the virtual card number to obtain or confirm authorization for the credit plan, and to recover the real account number from the virtual card number to obtain authorization of the transaction from an issuer for the real account number.
The payment scheme infrastructure may also comprise an eligibility checker for checking eligibility for credit for the real account number when processing the transaction. This eligibility checker may be adapted to obtain an instalment code for the credit plan after successfully checking for eligibility for credit for the real account number.
In a fifth aspect, the disclosure provides a credit issuer computing system adapted for authorizing payment for an online transaction according to a credit plan using a payment scheme infrastructure, the credit issuer computing system being adapted to: receive from a customer a request for credit for a transaction together with customer information; determine whether to offer credit to the customer, and if so, provide a real account number for the customer and create a virtual account number for a credit plan for the transaction; provide the virtual account number to the merchant and real account number and the virtual account number to the payment scheme infrastructure; authorize the transaction, if the transaction is completed using the virtual account number and the credit plan is authorized, through an issuing bank associated with the credit issuer; and request payment from a customer for the transaction according to the credit plan.
If the customer has previously requested credit from the credit issuer, the credit issuer computing system may be adapted to use the existing real account number for the customer but to create a new virtual card number for the credit plan.
In this way, the disclosure provides a transaction method in which a virtual card number is associated with a transaction credit plan, wherein the virtual card number is used to process the transaction through a payment card transaction infrastructure. The virtual card number may be associated with a real card number associated with a customer relationship with a merchant or credit facilitator. The real card number may be associated with multiple virtual card numbers, and these virtual card numbers may be associated with different transaction credit plans (with different payment terms).
In this way, the disclosure also provides a method of processing a transaction in a transaction infrastructure wherein a card number identifies a transaction as being associated with an instalment plan, and wherein the transaction is submitted for instalment plan approval before authorization of the transaction. This may be by obtaining an instalment code, which is then provided to an issuer bank for the transaction when authorization of the transaction is requested.
The scope of the present disclosure is best understood from the following detailed description of the exemplary embodiments when read in conjunction with the accompanying drawings. Included in the drawings are the following figures:
Before discussion of specific embodiments of the disclosure, the four-party transaction scheme model will be introduced with respect to
The four-party model may be used as a basis for the transaction network. For each transaction, the model comprises four entity types: cardholder 110, merchant 120, issuer 130 and acquirer 140. In this model, the cardholder 110 purchases goods or services from the merchant 120. The issuer 130 is the bank or any other financial institution that issued the card to the cardholder 110. The acquirer 140 provides services for card processing to the merchant 120.
The model also comprises a central switch 150—interactions between the issuer 130 and the acquirer 140 are routed via the switch 150. The switch 150 enables a merchant 120 associated with one particular bank acquirer 140 to accept payment transactions from a cardholder 110 associated with a different bank issuer 130.
A typical transaction between the entities in the four-party model can be divided into two main stages: authorization and settlement. The cardholder 110 initiates a purchase of a good or service from the merchant 120 using their card. Details of the card and the transaction are sent to the issuer 130 via the acquirer 140 and the switch 150 to authorize the transaction. Should the transaction be considered abnormal by the issuer 130, the cardholder 110 may be required to undergo an additional verification process to verify their identity and the details of the transaction. Once the additional verification process is complete the transaction is authorized.
On completion of the transaction between the cardholder 110 and the merchant 120, the transaction details are submitted by the merchant 120 to the acquirer 140 for settlement.
The transaction details are then routed to the relevant issuer 130 by the acquirer 140 via the switch 150. Upon receipt of these transaction details, the issuer 130 provides the settlement funds to the switch 150, which in turn forwards these funds to the merchant 120 via the acquirer 140.
Separately, the issuer 130 and the cardholder 110 settle the payment amount between them. In return, a service fee is paid to the acquirer 140 by the merchant 120 for each transaction, and an interchange fee is paid to the issuer 130 by the acquirer 140 in return for the settlement of funds.
In practical implementations of a four-party system model, the roles of a specific party may involve multiple elements acting together. This is typically the case in implementations that have developed beyond a contact-based interaction between a customer card and a merchant terminal to digital implementations using proxy or virtual cards on user computing devices. As will be discussed further below, embodiments of the present disclosure relate to use of virtual cards in online transactions between a user computing device and a merchant server.
The cardholder 1 uses their computing device—which may be any or all of a cellular telephone handset, a tablet, a laptop, a static personal computer or any other suitable computing device (here both a cellular telephone handset 11 and a laptop computer 12 are shown as possible cardholder computing devices)—to provide user means for payment with a physical payment card 6 or as a virtual payment card operating only in a digital domain. The smartphone 11 may achieve this with a mobile payment application and a digital wallet (and can thus transact with a merchant POS terminal 7 using NFC or another contactless technology), but in the cases of relevance to the disclosure the cardholder computing device will typically be acting simply as a client interacting with a merchant server 12 representing the merchant 2 over any appropriate network connection, such as the public internet.
The transaction scheme infrastructure (transaction infrastructure, payment infrastructure, payment scheme infrastructure) 5 provides the computing infrastructure necessary to operate the card scheme and provide routing of transactions and other messaging to parties such as the acquirer 3 and the issuer 4—it may also provide services such as a wallet service to support a digital wallet on a cardholder computing device and a digital enablement service supporting tokenisation of transactions—these are not described in detail here but are discussed further in EMV specifications as identified below. Connecting to the transaction infrastructure 5 for performing online transactions there is an internet gateway 18 for a payment service provider to accept internet based transactions for processing by the transaction infrastructure 5.
Additional services may also be provided by the transaction infrastructure (as will be described below with reference to embodiments of the disclosure) and on behalf of other parties such as the issuer 4 and the acquirer 3. One such service is issuer permissioning service 41 which allows for configuration of card permissions—one example of such a service is the applicant's InControl service. As will be shown below, such a service is used in embodiments of the present disclosure.
Individual computing elements of the architecture of
Specific embodiments of the disclosure will be described below with reference to
When the customer 1 takes the “My Merchant Credit” option, they are connected to a credit facilitator 4—an issuing bank, though not necessarily the issuer of any payment card owned by the customer—rather than to a conventional payment gateway 18. The customer will typically be required to enter or confirm personal information typically necessary in obtaining credit—such as salary, address and e-mail, as indicated in the exemplary screen shown in
If a credit offer is selected, the credit facilitator 4 opens a line of credit associated with the transaction with associated payment terms for the transaction corresponding to the offered instalment plan. This transaction infrastructure 5 also uses the four-party model, and as noted above the credit facilitator 4 essentially corresponds to an issuing bank. The model is directly analogous in that the credit facilitator 4 essentially establishes an account for the customer 1 for transactions with that merchant associated with a real card number (RCN) that performs a similar role to a primary account number (PAN) for a conventional payment card. Associated with the specific transaction requested there will also be a virtual card number (VCN) with use limited to the specific transaction at issue. The RCN and VCN may also be termed a real account number and a virtual account number.
If a customer 1 makes a future transaction with the same retailer and again selects “My Merchant Credit”, this credit approval step may be circumvented and the existing RCN used, with only a new VCN created for this new transaction. Potentially, the RCN may cover interactions between the credit facilitator 4 and the customer 1 involving other merchants, but the VCN will be merchant specific. The credit facilitator 4 must request any new RCN and VCN from a transaction infrastructure provider 5—in this case of the applicant, this is achieved through Mastercard's InControl product, which provides card management capabilities for issuers and can establish supplementary card creation and usage parameters.
At this point a merchant specific VCN for the transaction is created (and an RCN created if needed), and the VCN is provided as shown in
Eligibility determination is shown in
As shown in
If a credit option has been chosen, the merchant completes the plan with the stored VCN associated with that plan and sends an authorization request to the transaction scheme provider using that VCN. This is recognised as a VCN transaction as before, so it is routed for decoding of the VCN to recover the associated RCN, which is returned to the issuer for authorization of the transaction. The authorization is received by the transaction scheme provider, who converts the RCN pack to the VCN and sends authorization to the acquirer 3, who passes this back to the merchant PSP as for a conventional transaction. The merchant determines the purchase to be complete, and releases the goods for provision to the consumer.
After completion of the transaction, the transaction type is noted in transaction scheme records for clearing, and this is provided for issuer records for use in the cardholder statement. The credit transaction then appears in the cardholder monthly statement in the conventional way and will be paid off by the consumer in payment of their monthly statement.
Further variants to these process flows are possible while maintaining the principles indicated here. For example, eligibility checking may be carried out before generation of a VCN for the instalment plan—a suitable plan may be provided (via the merchant) for customer approval at this point. The VCN may then be generated after customer approval of a plan that had been determined as suitable after the eligibility check.
Whilst various exemplary embodiments of the disclosed system and method have been described above it should be understood that they have been presented for purposes of example only, and should not be taken to be limitations. The above description is not exhaustive and does not limit the disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practicing of the disclosure, without departing from the breadth or scope of the disclosure.
Number | Date | Country | Kind |
---|---|---|---|
1715375.0 | Sep 2017 | GB | national |