System for facilitating payments

Abstract

The combination of virtual payment cards (tokens) and 3D Secure to transparently transport information to an issuing authority between mutually independent transactions. Furthermore, the virtual payment card standard digital information is transformed by embedding the mandated URL/SESSION ID without the need for the card schemes, acquirers, or payment gateways to make any modifications to their system or message formats.

Claims

1. A system for facilitating an online transaction initiated by a client at an online address, the system comprising one or more processors and memory storing instructions executable by the one or more processors to cause the system to: generate a payment token, originating at a client terminal, having a unique identification factor wherein said unique identification factor is a generated 16 digit cryptogram and comprises at least an account number and an expiry date and embedded further authentication information comprising a portal URL and a session ID; transmit, by an authorisation gateway to a data processing unit associated with an authorizing institution system, the 16 digit cryptogram, wherein transmitting the 16 digit cryptogram embedding the portal URL and the session ID complies with standard ISO 8583 messaging formats; receive, by the data processing unit, the online address and the unique identification factor; and determine, by the data processing unit, whether to: allow the transaction; deny the transaction; or require a further confirmation step; wherein the determination by the data processing unit is based on the online address, the unique identification factor and a set of rules.

2. A system according to claim 1, wherein said further confirmation step comprises a notification to the client of predetermined information.

3. A system according to claim 1, wherein a link between a transaction approval and the online address is created.

4. A method for facilitating an online transaction at an online address, comprising the steps of: at check-out, entering 16 digit card number (PAN-primary account number), expiry date and the card verification value (CVV) to generate a 16 digit cryptogram, the 16 digit cryptogram comprising at least an account number and the expiry date and embedded further authentication information of a portal URL or a session ID; transmitting, by an authorization gateway, to a data processing unit associated with an authorizing institution system, the 16 digit cryptogram, wherein transmitting the 16 digit cryptogram embedding the portal URL and the session ID complies with standard ISO 8583 messaging formats; and determine, by the data processing unit, whether to: allow the transaction; deny the transaction; or require a further confirmation step; wherein the determination by the data processing unit is based on the online address, the unique identification factor and a set of rules.

Description

DETAILED DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 discloses an exemplary payment card that shows which bits of information are used to generate the cryptogram.

(2) FIG. 2 is a diagram of the system for facilitating payments.

(3) FIGS. 3A-3B disclose a method of facilitating payments as implemented by the system.

DETAILED DESCRIPTION OF THE INVENTION

(4) In order for customers to pay for the goods and services they purchase, online merchants accept payment instruments such as debit and credit cards as well as well known payment methods such as PayPal. Merchants use their own websites or those of marketplaces to sell their goods and services identifiable by their unique URL/SESSION IDs (Uniform Resource Locators) commonly called web addresses.

(5) When a debit or credit card is used to effect a payment instruction, the transaction information, inclusive of the amount to be paid is sent to the merchant's acquiring bank or payment gateway which then requests an authorisation from the institution that issued the credit or debit card to the transacting client (card issuer). Issuing institutions would not previously vet the URIs (Uniform Resource Identifiers) of the merchants from which transactions originate.

(6) It is clear therefore that merchant stores can be accessed via different URL/SESSION IDs depending on the browser's clients use at various times. The access path selected is in most cases irrelevant to clients but, if required, clients always have the choice to choose the portal/URL/SESSION ID through which the merchant will be accessed. For example, a client may wish to purchase a pair of shoes via a portal that offers discounts. Such discounts are in some cases negotiated by an affiliate of the merchant concerned and can thus only be claimed by a client if the purchase is performed via the affiliate's URL/SESSION ID.

(7) When a client accesses a merchant's URL/SESSION ID directly, only this merchant can offer a discount. When the same client purchases the goods via an affiliate of said merchant, such affiliate may be able to offer the client a discount and/or cashback based on its affiliate/merchant agreement. Clients can thus search the internet for the best discounts and purchase the goods they require via their associated website.

(8) There are currently no known technological methods to control an authorisation based on the specific URL/SESSION ID a client may have used to make purchases. The reason for this lack of control is twofold, a) the issuing institution will generally not deny a transaction unless it does not comply with its standard financial terms (e.g. credit limit) and b) it is the client who decides from which web-site the goods will be purchased based on criteria that are not the business of issuing institutions.

(9) The internet is an open system and thus it would be intuitively wrong to obligate clients to use specific URL/SESSION IDs to effect purchases, unless of course clients were advised beforehand that such restriction is necessary for them to access certain financial products or derive benefits. Clients therefore would decide on the URL/SESSION IDs they wished to use based on the benefits these would attract.

(10) For example, an organisation may wish to provide short term finance to its clients but only if specific affiliate links are utilised. The credit provided may be financially beneficial to clients as the credit provider would derive income streams from the merchants with which they have concluded affiliate agreements. Without these new income streams, the credit provider may not be in a position to offer the credit line requested on preferential terms.

(11) Clients may, inadvertently or knowingly access the merchant's website via an URL/SESSION ID that are not affiliated with the credit provider. If and when this occurs, the credit provider may wish to decline the purchaser and therefore refuse to provide the credit line requested or advise the client that the financial terms of the credit line such as interest, fees, repayment periods, etc. have changed as a result of the client's action (URL/SESSION ID selection). Thus, a notification may be made.

(12) The previously missing link (in other words, the contribution of the present inventive concept) is that the schemes' payment authorisation function cannot be tracked as needed and the merchant is thus is not aware of the agreement previously entered into by the client and the credit provider (issuing authority) regarding the use of a specific URL/SESSION ID. This lack of historical tracking might allow the client to make use of the credit provided using any URL/SESSION ID and thus bypass the credit provider's rules.

(13) This inventive concept resolves the above dilemma elegantly by creating an trackable link between the credit approval process and the URL/SESSION ID to be utilised. This link is created when the client selects the merchant store and the goods to be purchased.

(14) The first part of the solution is achieved by issuing a virtual card, constructed in such a way as to, on the one hand, adhere to the card schemes' format and on the other, to embed in the issuer's proprietary data fields, the URL/SESSION ID from which the goods should be acquired. This ensures that when this virtual card is utilised in the future to make a purchase, the URL/SESSION ID which was to be used is provided to the authorisation authority, in this case, the credit provider (issuing authority).

(15) The inventive concept thus creates an irrefutable audit trail of the client's agreement embedded in the virtual card itself thus ensuring that the URL/SESSION ID information cannot be lost and can always finds its way back to the authorisation (issuing) authority.

(16) The inventive concept further addresses the problem associated with providing the URL/SESSION ID, on which the transaction is actually being affected, to the authorising authority so that it can perform a comparison. It must be noted that previous card schemes do not and cannot currently provide this information as part and parcel of their standard ISO 8583 message formats. It was thus not previously possible for the authorisation (issuing) authority to be made aware of the URL/SESSION ID being used at the time the transaction is performed.

(17) This inventive concept resolves this problem by utilising the 3D secure functionality as a means of obtaining the URL/SESSION ID on which the transaction is being conducted. At check-out, clients are asked to enter their 16 digit card number (PAN-primary account number), expiry date and the card verification value (CVV). Once these values have been entered, the transaction is sent for authorisation through the acquirer's system or the merchant's payment gateway. If 3D secure is mandated by the issuing institution, a 3D secure portal is activated through which the client can be identified and validated.

(18) The 3D portal is provided by the issuing institution which can therefore derive the URL/SESSION ID being used by the client. In addition to providing additional client security, 3D secure is utilised to feed-back to the issuer, the virtual card details as well as the URL/SESSION ID where these were captured.

(19) The authorising institution (in this case, the credit provider) can now compare the URL/SESSION IDs and either a) authorise the transaction, b) deny the transaction or/and c) advise the client via the 3D portal that the wrong URL/SESSION ID is being used thus allowing the client to take remedial action.

(20) FIG. 1 shows an exemplary payment card in line with EMV standards, and shows how specific data can be embedded into a cryptogram and repurposes the result to look and function as a standard EMV token. Thus, a process where a scheme issued BIN 401 is combined with a system generated cryptogram comprising 16 digits (making use of public/private key pair) generated using identification and authentication data such as, but not limited to an account identifier 404, session ID 405, a signature 406 generated with the customers private key, and a check digit make up what would traditional be known as a PAN, CVV and Expiry date.

(21) FIG. 2 shows the system for facilitating payment of the by using the exemplary payment card of FIG. 1. As discussed above, the client terminal 11 which houses the a data processing unit uses the information on the payment card to generate a virtual card 10 including the cryptogram described above and then initiate a financial transaction session for that particular payment card. This can be done at a client terminal 11. The financial transaction session then contacts the retailer 14, either by standard internet 12 or by a preferred portal provider 13 to initiate the financial transaction with the retailer 14. The retailer 14 contacts the issuing institution 15 to ensure that the card is authorized for the transaction, and if so, proceeds with completing the transaction. If the issuing institution 15 fails to provide sufficient authorization for the card used, the retailer 14 can void the transaction and then notify both the issuing institution and the user that the transaction has been voided. If proper authorization is granted by the issuing institution 15, the retailer then approves and completes the transaction. In either situation, tracking information is generated.

(22) FIGS. 3A-3B show the method for facilitating payment as executed by the system of FIG. 2. In FIG. 3A, the method begins with an initiation step 18 of a transaction by the client. First, a check 20 is made to see there is any pre-existing virtual card information that can be used for this session. If yes, then cryptogram is generated 21. If no, then the virtual card information is generated 20 and then the cryptogram is generated 21. In the next step, the client contacts the retailer to initiate a POS transaction 23. Then then client either checks for or is informed of a preferred portal that can used for this transaction as discussed above 24. If yes, then a further check is executed to see if this client is authorized to use this preferred portal 25 and the client can take advantage of the special benefits associated with using that preferred portal with the retailer. If no, then the client is not allowed to use the portal. The next step is to secure client authorization for the POS transaction with this retailer by verifying the cryptogram 26. If the client is approved for this transaction 27, then the transaction is completed 29. If the client is not approved for this transaction, the transaction is voided 28. In both instances, this is the end of this method 30.

(23) It is to be understood that the system and method for facilitating payments is not limited to the specific embodiments described above but encompasses any and all embodiments within the scope of the generic language of the following claims enabled by the embodiments described herein, or as otherwise shown in the drawings or as described above in terms sufficient to enable one of ordinary skill in the art to make and use the claimed subject matter.