US20200097959A1 - Payment transaction process employing dynamic account expiry and dynamic token verification code - Google Patents

Abstract

A method includes receiving a request for payment credentials. The request indicates an account from which payment for a transaction is to be made. A payment token is looked-up that corresponds to the indicated account. Dynamic expiry data and a dynamic token verification code are generated. As a response to the request, the looked-up payment token, the generated dynamic expiry data and the generated dynamic token verification code are transmitted.

Description

BACKGROUND
• FIG. 1 is a block diagram that illustrates aconventional payment system100.
• Thesystem100 includes acustomer device102 by which auser103 accesses ane-commerce server104 via theinternet105. Thecustomer device102 may be any type of computing device usable to allow access to the internet, and runs a browser program (not separately shown) to enable interaction between thecustomer device102 and the various resources available via the internet. Thecustomer device102 may be, for example, a personal computer, a laptop computer, a tablet computer or a mobile-browser-equipped smartphone or other mobile device. Thee-commerce server104 is typically a server computer operated by or on behalf of a merchant to host an online store/shopping website and to allow virtual visits to the website from customer devices. The e-commerceserver104 also operates to handle online-shopping transactions, typically funded by a payment system account owned by theuser103. In an online shopping transaction, theuser103 operates thecustomer device102 to select one or more items for purchase, then elects to enter a checkout phase of the transaction, in which information that identifies the user's payment system account is provided to or accessed by thee-commerce server104.
• Acomputer108 operated by an acquirer (acquiring financial institution) is also shown as part of thesystem100 inFIG. 1. The acquirer may be a financial institution that provides payment account acceptance services to the merchant that operates thee-commerce server104. Theacquirer computer108 may operate to receive a transaction authorization request message (“authorization request”) for the online shopping transaction from thee-commerce server104. Theacquirer computer108 may route the authorization request via a payment network110 (sometimes also referred to as a “card network”) to theserver computer112 operated by the issuer of the payment account that was specified during the checkout phase of the online shopping transaction. A transaction authorization response message (“authorization response”) generated by the payment accountissuer server computer112 may be routed back to thee-commerce server104 via thepayment network110 and theacquirer computer108.
• One well known example of a payment network is referred to as the “Banknet” system, and is operated by Mastercard International Incorporated, which is the assignee hereof.
• The payment accountissuer server computer112 may be operated by or on behalf of a financial institution (“FI”) that issues payment accounts to individual users and/or other entities. For example, the payment accountissuer server computer112 may perform such functions as (a) receiving and responding to requests for authorization of payment account transactions to be charged to payment accounts issued by the FI; (b) engaging in payment transaction clearing operations; and (c) tracking and storing transactions and maintaining account records.
• The components of thesystem100 as depicted inFIG. 1 are only those that are needed for processing a single transaction. A typical payment system may process many purchase transactions (including simultaneous transactions) and may include a considerable number of payment account issuers and their computers, a considerable number of acquirers and their computers, and numerous merchants and their e-commerce servers. The system may also include a very large number of payment account holders, who engage in online shopping transactions.
• As is well known to those who are skilled in the art, a typical payment system like that shown inFIG. 1 may also handle numerous face to face purchase transactions at the point of sale in retail stores and other establishments. In a typical such transaction (not illustrated), the customer may present a payment card or other payment-enabled device (e.g., a payment-enabled mobile device) to a point of sale (POS) terminal. The POS terminal is operated by the merchant (or merchant's employee) to read payment account information from the card or device presented by the customer. An authorization request may originate from the POS terminal for routing to the account issuer, and the authorization response may be routed back to the POS terminal from the account issuer.
• In some e-commerce transactions, the user enters the PAN (primary account number) for his/her payment card account during the checkout phase of interaction between the customer device and the e-commerce server. In other arrangements, there may be a “card-on-file” with the e-commerce server, so that the user does not have to enter his/her PAN. To enhance security, and help to protect the PAN from being intercepted by a wrongdoer, in a card-on-file arrangement the user's payment account may be represented by a payment token, which is a character string that serves as a replacement for the PAN during part of the transaction process. For example, the payment token may be dedicated for use only in e-commerce transactions with the merchant in question.
• The present inventors have now recognized an opportunity to further enhance the security and convenience of e-commerce transactions.
BRIEF DESCRIPTION OF THE DRAWINGS
• Features and advantages of some embodiments of the present disclosure, and the manner in which the same are accomplished, will become more readily apparent upon consideration of the following detailed description of the disclosure taken in conjunction with the accompanying drawings, which illustrate preferred and exemplary embodiments and which are not necessarily drawn to scale, wherein:
• FIG. 1 is a block diagram that illustrates a conventional payment system.
• FIG. 2 is a block diagram that illustrates a payment system provided according to aspects of the present disclosure.
• FIG. 3 is a block diagram that illustrates a computer system that may perform a role in the system ofFIG. 2.
• FIG. 4 is a block diagram that illustrates another computer system that may perform a role in the system ofFIG. 2.
• FIG. 5 is a simplified block diagram of a customer device that may perform a role in the system ofFIG. 2.
• FIG. 6 is a flow chart that illustrates a process that may be performed in the system ofFIG. 2 according to aspects of the present disclosure.
DETAILED DESCRIPTION
• In general, and for the purpose of introducing concepts of embodiments of the present disclosure, as part of an e-commerce transaction, the user may request a transaction-specific set of payment credentials from a remote payment services computer. In response to the request, the payment services computer may look up a payment token that points to an account that the user has selected to use for the current transaction. The payment services computer may also engage in a cryptographic process or processes to generate dynamic expiry data and a dynamic token verification code. The payment service computer may send the payment token, the dynamic expiry data and the dynamic token verification code to the user as a set of transaction-specific payment credentials. The user may in turn provide the set of payment credentials to the merchant for inclusion in an authorization request and downstream verification of the dynamic expiry data and the dynamic token verification code.
• With an arrangement of this kind, the desirable security goal is met of effectively submitting a transaction-specific token that can be verified during payment system processing and that cannot be reused if intercepted by a wrongdoer.
• FIG. 2 is a block diagram that illustrates apayment system200 provided according to aspects of the present disclosure.
• As in the system ofFIG. 1, auser103 is shown operating acustomer device202, so as to interact with ane-commerce server204 via theinternet105. Anacquirer108 provides the e-commerce server (merchant)204 with access to apayment network110a. The system also includes anaccount issuer112, to which the merchant's authorization request is ultimately routed via thepayment network110a. In accordance with aspects of the present disclosure, thesystem200 further includes apayment services computer206. Via in-app orinternet communication208, thecustomer device202 interacts with thepayment services provider206 to obtain a set of payment credentials, as described herein.
• The two dot-dash lines210 linking thepayment services computer206 to thepayment network110aare intended to imply the possibility or possibilities that (a) thepayment services computer206 is under common operation with thepayment network110a; and/or (b) the payment services computer is closely associated with, in frequent communication with, and/or at least partially overlaps with computing resources employed in operating thepayment network110a.
• As was the case with the system as depicted inFIG. 1,FIG. 2 only shows components required for handling a single transaction. In a practical embodiment of thesystem200, there may be numerous e-commerce servers, and customer devices, a large number of merchants' banks/acquirers and issuers, and potentially also a number of payment service computers. Thesystem200 may also handle transactions at the point of sale, and so may include many items of POS equipment like those referred to above. Still further, thesystem200 may include a very large number of customer payment devices, such as cards, fobs, payment-enabled mobile devices, etc., for use in initiating transactions at the point of sale.
• FIG. 3 is a block diagram that illustrates an embodiment of thepayment services computer206 shown inFIG. 2.
• Referring now toFIG. 3, thepayment services computer206 may, in its hardware aspects, resemble a typical server computer and/or mainframe computer, but may be controlled by software to cause it to function as described herein. For example, thepayment services computer206 may be constituted by commercially available server computer hardware and/or by cloud-based computing resources.
• Thepayment services computer206 may include acomputer processor300 operatively coupled to acommunication device301, astorage device304, aninput device306 and anoutput device308. Thecommunications device301, thestorage device304, theinput device306 and theoutput device308 may all be in communication with theprocessor300.
• Thecomputer processor300 may be constituted by one or more conventional processors.Processor300 operates to execute processor-executable steps, contained in program instructions described below, so as to control thepayment services computer206 to provide desired functionality.
• Communication device301 may be used to facilitate communication with, for example, other devices (such as customer devices). For example,communication device301 may comprise numerous communication ports (not separately shown), to allow thepayment services computer206 to communicate simultaneously with a large number of other devices, including communications as required to simultaneously handle numerous requests for payment credentials.
• Input device306 may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, theinput device306 may include a keyboard and a mouse.Output device308 may comprise, for example, a display and/or a printer.
• Storage device304 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory. Any one or more of such information storage devices may be considered to be a computer-readable storage medium or a computer usable medium or a memory.
• Storage device304 stores one or more programs for controllingprocessor300. The programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of thepayment services computer206, executed by theprocessor300 to cause thepayment services computer206 to function as described herein.
• The programs may include one or more conventional operating systems (not shown) that control theprocessor300 so as to manage and coordinate activities and sharing of resources in thepayment services computer206, and to serve as a host for application programs (described below) that run on thepayment services computer206.
• The programs stored in thestorage device304 may also include asoftware communications interface310 that programs theprocessor300 to facilitate communications between thepayment services computer206 and customer/user devices.
• Thestorage device304 may also store a payment credentials request handlingapplication program312. The payment credentials request handlingapplication program312 may program theprocessor300 to enable thepayment services computer206 to handle numerous requests for payment credentials as described herein.
• Thestorage device304 may also store, and thepayment services computer206 may also execute, other programs, which are not shown. For example, such programs may include a reporting application, which may respond to requests from system administrators for reports on the activities performed by thepayment services computer206. The other programs may also include, e.g., database management software, device drivers, etc.
• Thestorage device304 may also store one ormore databases314 required for operation of thepayment services computer206.
• FIG. 4 is a block diagram that illustrates an embodiment of acomputer401 that performs at least some functionality required for operation of thepayment network110a. Thecomputer401 will accordingly be referred to as the “payment network computer.” Thepayment network computer401 may resemble the above-describedpayment services computer206 in terms of hardware architecture and/or constituent components. Accordingly, thepayment network computer401 may include acomputer processor400 operatively coupled to acommunication device402, astorage device404, aninput device406 and anoutput device408. Thecommunications device402, thestorage device404, theinput device406 and theoutput device408 may all be in communication with theprocessor400.
• Processor400 operates to execute processor-executable steps, contained in program instructions described below, so as to control thepayment network computer401 to provide desired functionality.
• Storage device404 stores one or more programs for controllingprocessor400. The programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of thepayment network computer401 executed by theprocessor400 to cause thepayment network computer401 to function as described herein.
• The programs may include one or more conventional operating systems (not shown) that control theprocessor400 so as to manage and coordinate activities and sharing of resources in thepayment network computer401, and to serve as a host for application programs (described below) that run on thepayment network computer401.
• The programs stored in thestorage device404 may also include a software communications interface410 to facilitate data communications between thepayment network computer401 and computers operated by transaction acquirer banks. In addition, thestorage device404 may store a software communications interface412 to facilitate data communications between thepayment network computer401 and computers operated by account issuer banks.
• Thestorage device404 may also store a transaction handling application program414. The transaction handling application program414 may program theprocessor400 to enable thepayment network computer401 to handle numerous payment account system transactions including verification of payment credentials as described below.
• Still further, thestorage device404 may store a transactionclearing application program416. The transactionclearing application program416 may program theprocessor400 to enable thepayment network computer401 to handle clearing of payment account system transactions between issuer and acquirer banks.
• Thestorage device404 may also store, and thepayment network computer401 may also execute, other programs, which are not shown. For example, such programs may include a reporting application, which may respond to requests from system administrators for reports on the activities performed by thepayment network computer401. The other programs may also include, e.g., database management software, device drivers, etc.
• Thestorage device404 may also store one ormore databases418 required for operation of thepayment network computer401.
• FIG. 5 is a simplified block diagram of an example of thecustomer device202 shown inFIG. 2. In this example embodiment, thecustomer device202 is illustrated as a mobile device such as a smartphone.
• Thecustomer device202 may include ahousing503. (In cases where thecustomer device202 is a desktop computer, thecustomer device202 may include several housings including the “tower” housing, the keyboard housing, etc.)
• Thecustomer device202 further includes a processor/control circuit506, which is contained within thehousing503. Also included in thecustomer device202 is a storage/memory device or devices (reference numeral508). The storage/memory devices508 are in communication with the processor/control circuit506 and may contain program instructions to control the processor/control circuit506 to manage and perform various functions of thecustomer device202. Programs/applications (or “apps”) that are stored in the storage/memory devices508 are represented atblock510 inFIG. 5, and may be accessed to program the processor/control circuit506. In view of its pertinence to the teachings of this disclosure, a browser program is shown separately from the programs/apps510 and is represented byblock511. In the same vein, apayment app512 is depicted separately from the other programs/apps510 Physical and/or software aspects of the device user interface, including input/output (I/O) devices, are represented atblock513 inFIG. 5.
• As is typical for computing devices, thecustomer device202 may include communications components as represented byblock514. Thecommunications components514 allow thecustomer device202 to engage in data communication with other devices. For example, thecommunications components514 may support mobile communications functions that include voice and data communications via a mobile communications network (not shown). The data communication capabilities of thecustomer device202 may allow for online browsing sessions and interactions with webpages via thebrowser512 and/or may support “in-app” communication sessions.
• From the foregoing discussion, it will be appreciated that the blocks depicted inFIG. 5 as components of thecustomer device202 may in effect overlap with each other, and/or there may be functional connections among the blocks which are not explicitly shown in the drawing.
• FIG. 6 is a flow chart that illustrates a process that may be performed in thepayment system200 according to aspects of the present disclosure.
• At602 inFIG. 6, theuser103 operates his/hercustomer device202/browser512 to engage in an online shopping transaction via interaction between thebrowser512 and the e-commerce server computer204 (FIG. 2). It is assumed that theuser103 selects one or more items for purchase in the transaction, and proceeds to the checkout phase (block604) of the online shopping transaction.
• At606 inFIG. 6, it is determined that the merchant/e-commerce server204 supports a payment method, as described below in more detail, in which dynamic expiry data and a dynamic token verification code are coupled with a payment token to form a set of payment credentials. Step606 may occur via an interaction between the mobile browser511 (FIG. 5) and thee-commerce server204.
• At608 inFIG. 6, it is determined that the payment app512 (FIG. 5) supports the payment method referred to above in connection withstep606. This determination may occur via an interaction between themobile browser511 and the payment app.
• At610, the payment app is assumed to be selected by the user from among a number of different payment mechanisms that may be supported by the merchant.
• At612, the user is presented with an opportunity to select from among a number of different accounts belonging to the user, with the selection to indicate which account is to be used for the current transaction. In some embodiments, the accounts available for selection may include a deposit account maintained at a bank and belonging to the user. Other account options available for selection may include credit card accounts, debit card accounts, prepaid card accounts, etc. It is further assumed at612 that the user selects one of the available account options.
• At614, thecustomer device202, via operation of thepayment app512, may interact with thepayment services computer206 so as to transmit to the payment services computer206 a request for payment credentials. It may be assumed that thepayment services computer206 receives the request for payment credentials. The request for payment credentials may include an indication of the account that the user selected at612.
• At616, thepayment services computer206 may look up a previously created payment token that has been associated ahead of time with the selected account. As used herein and in the appended claims to “look up” includes thepayment services computer206 accessing a token database that it stores and/or communicating with a token service provider (not shown) to retrieve the result of a mapping between the selected account and a payment token previously assigned to represent the selected account.
• At618, thepayment services computer206 generates dynamic expiry data to be associated for the current transaction with the payment token looked up at616. The expiry data is “dynamic” in the sense that it is changed from transaction to transaction, rather than being fixed (for a period of a few years) as is the conventional expiration date generally associated with a PAN or payment token.
• At620, thepayment services computer206 generates a dynamic token verification code to be associated for the current transaction with the payment token looked up at616. The dynamic token verification code is to take the place of a “fixed” code such as a CVC that is customarily associated with a PAN or payment token. The dynamic token verification code is “dynamic” in the sense that it is changed from transaction to transaction, rather than being fixed (for a period of a few years) as is a conventional CVC associated with a PAN.
• In some embodiments, thesteps618 and620 may be accomplished via one or more cryptographic processes performed by thepayment services computer206. The payment token looked up at616 may be one of the inputs of the cryptographic process or processes. One or more items of transaction data (i.e., data that indicates one or more attributes of the current transaction) may also be an input or inputs of the cryptographic process. Examples of transaction data may include transaction number, transaction amount and/or transaction date and/or time.
• According to one example cryptographic process for accomplishingsteps618 and620, thepayment services computer206 may concatenate the payment token with one, two or more numeric items of transaction data and then may digitally sign the resulting numeric string with a secret cryptographic key. The resulting digital signature is a second numeric string from which the dynamic expiry data and the dynamic token verification code may be derived. For example, the first three digits of the second numeric string may be used as the dynamic token verification code. The next four or more digits of the second numeric string may be subjected to a transformation that produces a four-digit number that satisfies the constraints required to mimic a valid card expiration date. The resulting four-digit number may be employed as the dynamic expiry data. Based on the above description, those who are skilled in the art will recognize that other cryptographic processes may alternatively be used to generate the dynamic expiry data and the dynamic token verification code, using the payment token and one or more items of transaction data as inputs.
• Referring again toFIG. 6, at622, thepayment services computer206 may transmit the payment token looked up at616, the dynamic expiry data generated at618 and the dynamic token verification code generated at620 to thecustomer device202 as the requested set of payment credentials. It may be assumed that the result ofstep622 is that thepayment app512 in thecustomer device202 receives that set of payment credentials.
• At624, thepayment app512 may pass the payment credentials to themobile browser511 in thecustomer device202. At626, the mobile browser may control thecustomer device202 to transmit the payment credentials to thee-commerce server204. It may be assumed that thee-commerce server204 receives the payment credentials transmitted to it at624.
• At628, the e-commerce server202 (i.e., the merchant) may assemble a transaction authorization request message (authorization request) in a standard format. The payment token may be inserted in the payment account number field of the authorization request format. The dynamic expiry data may be inserted in the card expiration date field of the authorization request format. The dynamic token verification code may be inserted in the (for example) CVC field in the authorization request format. The authorization request may also include transaction data such as transaction amount and merchant i.d., including the one or more items of transaction data used by thepayment services computer206 to generate the dynamic expiry data and the dynamic token verification code.
• Block630 inFIG. 6 represents routing and processing of the authorization request. This may include routing the authorization request via theacquirer108 to thepayment network110a. As part of the processing of the authorization request, thepayment network computer401 may detokenize (or obtain detokenization of) the payment token, and also may verify the dynamic expiry data and the dynamic token verification code. The verification processing may include duplicating the process by which thepayment services computer206 generated the dynamic expiry data and the dynamic token verification code using the payment token and transaction data as inputs.
• With the PAN or other account number data produced by detokenization, thepayment network computer401 may route the authorization request to theaccount issuer112. As forwarded from thepayment network computer401 to theaccount issuer112, the authorization request may contain one or more indications that thepayment network computer401 had verified the payment credentials.
• At632, the transaction authorization response message may be generated by theaccount issuer112 and routed to the merchant. It may be assumed for purposes of this discussion that the authorization request and the condition of the user's account satisfied the issuer's requirements for approving the transaction, and that the authorization response accordingly indicates approval of the requested transaction.
• At634, the merchant (e-commerce server204) may send a message to thecustomer device202 to indicate that payment processing for the transaction has been completed. Fulfillment of the transaction by the merchant may then proceed in due course.
• With a payment process as described herein, a highly secure mode of account identification may be incorporated in an e-commerce transaction. The desirable goal of what is in effect a transaction-specific set of payment credentials is achieved in a manner that is convenient for the user. Although the payment token itself may be reused, the token itself would be of little value to a wrongdoer, if one should intercept it, because the payment token is used only in combination with transaction-specific dynamic expiry data and a dynamic token verification code. The latter two elements of the payment credentials are transaction-specific and are changed for every transaction. Because of the security provided by cryptographic processes, the notional wrongdoer would likely find it impossible to generate valid expiry data and a valid token verification code in order to re-use the token, assuming the same were to be intercepted. Consequently, there is reduced concern over any possible data security breach that might occur with respect to the merchant's systems.
• There will now be a further discussion of aspects of the process illustrated inFIG. 6, particularly in regard to transaction authorization and clearing. According to one clearing mode of operation, payment settlement occurs in real time. According to another clearing mode of operation, traditional payment system clearing processes take place.
• The traditional clearing mode will be discussed first. In this mode, transaction authorization occurs after the user has engaged in selection of an online purchase and has selected a bank account as the payment instrument. Authorization request processing proceeds from the merchant via the acquirer and the payment network to the account issuer. It will be understood that payment credentials were obtained by the user and provided to the merchant as described above in connection withFIG. 6. As the authorization response is processed at the payment network, the dynamic elements of the payment credentials are verified. Fraud services may also be performed by the payment network, along with detokenization.
• Assuming approval of the authorization request, an ACH (automated clearing house) processor (not separately shown) associated with the payment network may enrich the authorization request with payment instruction details (e.g., “from” the user's bank account and “to” the user's bank holding account) and converts the authorization request in ISO 8583 format to ISO 20022 format before sending the authorization request to the user's bank.
• The ACH processor converts the authorization response from the user's bank from ISO 20022 to ISO 8583 before sending the authorization response back to the acquirer. The ACH processor also matches the authorized and cleared transactions before sending them to the user's bank.
• The ACH processor sends payment instructions to the user's bank to debit the user's bank account and to credit the user's bank holding account. The ACH processor provides clearing and reconciliation files to the user's bank to support clearing and reconciliation. A settlement account management system (not separately shown) sends the settlement advice to a payment network settlement bank (not shown) after reconciling authorization and clearing files. The user's bank settles with the payment network settlement bank, which then settles with the acquirer bank.
• The real time clearing mode will next be discussed. In this mode, transaction authorization occurs after the user has engaged in selection of an online purchase and has selected a bank account as the payment instrument. Authorization request processing proceeds from the merchant via the acquirer and the payment network to the account issuer. It will be understood that payment credentials were obtained by the user and provided to the merchant as described above in connection withFIG. 6. As the authorization response is processed at the payment network, the dynamic elements of the payment credentials are verified. Fraud services may also be performed by the payment network, along with detokenization.
• Assuming approval of the authorization request, an ACH (automated clearing house) processor (not separately shown) associated with the payment network may enrich the authorization request with payment instruction details (e.g., “from” the user's bank account and “to” the user's bank holding account) and converts the authorization request in ISO 8583 format to ISO 20022 format before sending the authorization request to the user's bank.
• The ACH processor converts the authorization response from the user's bank from ISO 20022 to ISO 8583 before sending the authorization response back to the acquirer. The ACH processor also appends the merchant's bank account information to the payment request.
• The ACH processor sends the payment request to the user's bank to debit the user's bank account and credit the merchant bank account. The user's bank clears the transaction with a real-time payment bank (not shown), which in turn clears the transaction with the acquirer bank. The user's bank settles with the real-time payments bank, which settles with the acquirer bank.
• As used herein and in the appended claims, the term “computer” should be understood to encompass a single computer or two or more computers in communication with each other.
• As used herein and in the appended claims, the term “processor” should be understood to encompass a single processor or two or more processors in communication with each other.
• As used herein and in the appended claims, the term “memory” should be understood to encompass a single memory or storage device or two or more memories or storage devices.
• The flow charts and descriptions thereof herein should not be understood to prescribe a fixed order of performing the method steps described therein. Rather the method steps may be performed in any order that is practicable, including simultaneous performance of at least some steps and/or omitting one or more steps.
• As used herein and in the appended claims, the term “payment card system account” includes a credit card account or a deposit account that the account holder may access using a debit card. The terms “payment card system account” and “payment card account” and “payment system account” and “payment account” are used interchangeably herein. The term “payment card account number” includes a number that identifies a payment card system account or a number carried by a payment card, or a number that is used to route a transaction in a payment system that handles debit card and/or credit card transactions. The term “payment card” includes a credit card or a debit card.
• As used herein and in the appended claims, the term “payment card system” refers to a system for handling purchase transactions and related transactions. An example of such a system is the one operated by Mastercard International Incorporated, the assignee of the present disclosure. In some embodiments, the term “payment card system” may be limited to systems in which member financial institutions issue payment card accounts to individuals, businesses and/or other organizations.
• Although the present disclosure has been set forth in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the disclosure as set forth in the appended claims.

Claims (20)

What is claimed is:

1. A method comprising:

receiving a request for payment credentials, the request indicating an account from which payment for a transaction is to be made;

looking up a payment token that corresponds to said account;

generating dynamic expiry data and a dynamic token verification code; and

responding to the request by transmitting the looked-up payment token, the generated dynamic expiry data and the generated dynamic token verification code.

2. The method ofclaim 1, wherein said transmitted payment token, dynamic expiry data and dynamic token verification code collectively uniquely correspond to said transaction.

3. The method ofclaim 2, wherein said generating step includes a cryptographic process that has the looked-up payment token as an input.

4. The method ofclaim 3, wherein said cryptographic process has transaction data as another input, said transaction data corresponding to at least one attribute of said transaction.

5. The method ofclaim 1, further comprising, after said responding step:

receiving a transaction authorization request message, the transaction authorization request message containing said payment token, said dynamic expiry data and said dynamic token verification code.

6. The method ofclaim 5, further comprising, after receiving said transaction authorization request message:

verifying said dynamic expiry data and said dynamic token verification code.

7. The method ofclaim 1, wherein the receiving, looking-up, generating and responding steps are performed by a payment services computer.

8. The method ofclaim 7, wherein the payment services computer is operated by an operator of a payment account system.

9. The method ofclaim 1, wherein the indicated account is a deposit account maintained at a bank.

10. A method comprising:

sending a request for payment credentials for a transaction; and

receiving the requested payment credentials, the received payment credentials including a payment token, dynamic expiry data and a dynamic token verification code;

wherein the payment token, the dynamic expiry data and the dynamic token verification code collectively uniquely correspond to said transaction.

11. The method ofclaim 10, further comprising:

submitting the received payment credentials to a merchant associated with the transaction.

12. The method ofclaim 11, wherein the sending, receiving and submitting steps are performed by a mobile device.

13. An apparatus comprising:

a processor; and

a memory in communication with the processor, the memory storing program instructions, the processor operative with the program instructions to perform functions as follows:

receiving a request for payment credentials, the request indicating an account from which payment for a transaction is to be made;

looking up a payment token that corresponds to said account;

generating dynamic expiry data and a dynamic token verification code; and

responding to the request by transmitting the looked-up payment token, the generated dynamic expiry data and the generated dynamic token verification code.

14. The apparatus ofclaim 13, wherein said transmitted payment token, dynamic expiry data and dynamic token verification code collectively uniquely correspond to said transaction.

15. The apparatus ofclaim 14, wherein said generating function includes a cryptographic process that has the looked-up payment token as an input.

16. The apparatus ofclaim 15, wherein said cryptographic process has transaction data as another input, said transaction data corresponding to at least one attribute of said transaction.

17. The apparatus ofclaim 13, wherein the processor is further operative, after performing said responding function, to receive a transaction authorization request message, the transaction authorization request message containing said payment token, said dynamic expiry data and said dynamic token verification code.

18. The apparatus ofclaim 17, wherein the processor is further operative, after receiving said transaction authorization request message, to verify said dynamic expiry data and said dynamic token verification code.

19. The apparatus ofclaim 13, wherein the processor and the memory are components of a payment services computer.

20. The apparatus ofclaim 13, wherein the indicated account is a deposit account maintained at a bank.

Images