The present disclosure generally relates to systems and methods for providing central token handling for computing networks, and in particular, to systems and methods for detokenization of network messages from multiple different networks whereby tokens associated therewith may be provided from multiple different token providers.
This section provides background information related to the present disclosure which is not necessarily prior art.
Network transactions often involve users, who initiate the transactions. In connection with such transactions, payloads of the transactions are known to be bases for how the transactions are handled and/or processed. It is common for transactions to rely on account indicators, within the payloads, such as account numbers, for routing, processing and/or replying to messages related to the transactions. It is also known for account numbers to be omitted for purposes of security, where tokens are provided in place of the account numbers. Specifically, for example, a payment network may rely on a token in some instances to mask or otherwise obscure a payment account number (e.g., a primary account number (PAN), etc.) from messages within the payment network and/or outside of the payment network (e.g., from a merchant, etc.). At some point in the payment network, the token is detokenized to reveal the payment account number for the account, thereby permitting routing, processing or approval of the underlying transaction, etc. Further, issuers often rely on token service providers to generate and provide tokens in connection with payment accounts, and also for the issuers to generate and/or provide tokens directly themselves.
The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations, and are not intended to limit the scope of the present disclosure:
Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.
Exemplary embodiments will now be described more fully with reference to the accompanying drawings. The description and specific examples included herein are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.
Transactions initiated at merchants, either in person or via network interactions, may result in authorization requests for the transactions, in which tokens are used rather than primary account numbers (PANs), for example, for payment accounts identified in the transactions. In connection with the transactions, the tokens are typically mapped or converted to the PANs, by token service providers issuing the tokens, to permit the transactions to proceed. When different token service providers, or different payment networks, are involved, issues may arise with the tokens, where the authorization requests may be processed by parties that are unable to map the tokens to the proper PANs.
Uniquely, the systems and methods herein provide for tokens to be converted to account numbers by a primary payment network, where network messages for transactions associated therewith are routed through different routing payment networks. In particular, when a routing payment network receives a network message (from an acquirer) for a transaction including a token unfamiliar to the routing payment network, a service request is directed to the primary payment network, which requests conversion or mapping of the token to an account number, such as, for example, a PAN, etc., associated with the specific account. Upon receipt of the account number from the primary payment network, the routing payment network provides the network message, with the account number, to an issuer of the account. Thereafter, the routing payment network directs a network reply message (as received from the issuer) to the acquirer from which the network message was initially received. In connection with the transaction, the issuer also provides transaction details to the account holder (e.g., a consumer involved in the transaction, etc.) at a communication device associated with the account holder. In this manner, when a network message is routed through the routing payment network, which is unfamiliar with the token identified in the message, the routing payment network is still able to identify the appropriate payment account, via a request to the primary payment network (i.e., to another payment network), and to continue routing of the network message. With that said, the primary payment network includes a token vault data structure that includes tokens from one or multiple token service providers, to thereby provide a central handling of token-inclusive network messages and subsequent detokenization of the same as needed. As such, efficiencies are gained herein over non-central handling of tokens, where network messages may be directed to disparate services and may be dependent on issuers associated with and/or generators of the specific tokens.
In the illustrated embodiment, the system 100 generally includes a merchant 102, an acquirer 104, a routing payment network 106, a payment network 108 (e.g., an issuer payment network, etc.), and an issuer 110, each coupled to (and in communication with) network 112. The system 100 also includes token service providers 114a and 114b, each coupled to and in communication with the network 112. That said, the network 112 may include, without limitation, a local area network (LAN), a wide area network (WAN) (e.g., the Internet, etc.), a mobile network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts illustrated in
The merchant 102 in the system 100 is generally associated with products (e.g., goods and/or services, etc.) available for purchase by one or more consumers (including consumer 118). The merchant 102 may offer the products for sale to the consumer 118, for example, through a physical location and/or through a virtual location, etc.
The consumer 118 in the system 100 is associated with a payment account, which is issued by the issuer 110 and which is suitable for use in funding transactions for products at the merchant 102 (or at other merchants as desired). The issuer 110 generally issues payment accounts (including the payment account issued to the consumer 118) that are specific to particular payment networks. For example, in the illustrated embodiment, the issuer 110 is configured to issue the consumer's payment account (and potentially other payment accounts) in association with (but without limitation to) the routing payment network 106, whereby messaging associated with transactions to the issued payment account is routed through the routing payment network 106. As such, in this example, the routing payment network 106 is a “front of card” payment network for the consumer's payment account (and for other payment accounts issued in association with the payment network 106). Similarly, the issuer 110 may be configured to issue payment accounts in association with the payment network 108, whereby messaging associated with transactions to the issued payment accounts would be routed through the payment network 108. And, here, the payment network 108 is the “front of card” payment network for such payment accounts. Regardless, however, each of the payment networks 106 and 108 is configured to provide at least messaging between acquirers and issuers to facilitate payment account transactions to the various payment accounts.
With that said, it is possible for one or more transactions directed to the payment account of the consumer 118 to potentially be routed through the payment network 108 (even though issued in association with the routing payment network 106). For example, by agreement between the routing payment network 106 and the payment network 108, the payment network 108 may be configured to route all transactions of a certain type (e.g., all debit transactions, all ATM transactions, etc.) or all transactions for a certain location between corresponding acquirers and issuers, for processing as described in more detail below.
With continued reference to
Each of the token service providers 114a-b is illustrated as being a separate part of the system 100, for example, separate from the payment network 108 and the routing payment network 106 (e.g., as third party service providers, etc.). That said, one or both of the token service providers 114a-b may be incorporated (physically or by control/agreement, etc.) into the routing payment network 106 and/or the payment network 108 in other embodiments. For example, in at least one embodiment, the token service provider 114a may be a separate, standalone part of the system 100, while the token service provider 114b may be incorporated into the payment network 108.
Generally, while one merchant 102, one acquirer 104, two payment networks 106 and 108, one issuer 110, and two token service providers 114a-b are included in the system 100 illustrated in
Referring to
The memory 204, as described herein, is one or more devices that permit data, instructions, etc., to be stored therein and retrieved therefrom. The memory 204 may include one or more computer-readable storage media, such as, without limitation, dynamic random access memory (DRAM), static random access memory (SRAM), read only memory (ROM), erasable programmable read only memory (EPROM), solid state devices, flash drives, CD-ROMs, thumb drives, floppy disks, tapes, hard disks, and/or any other type of volatile or nonvolatile physical or tangible computer-readable media. The memory 204 may be configured to store, without limitation, transaction data, tokens, token maps, account numbers (e.g., PANs, etc.), account ranges, and/or other types of data (and/or data structures) suitable for use as described herein. Furthermore, in various embodiments, computer-executable instructions may be stored in the memory 204 for execution by the processor 202 to cause the processor 202 to perform one or more of the functions described herein, such that the memory 204 is a physical, tangible, and non-transitory computer readable storage media. Such instructions often improve the efficiencies and/or performance of the processor 202 that is performing one or more of the various operations herein. It should be appreciated that the memory 204 may include a variety of different memories, each implemented in one or more of the functions or processes described herein.
In addition in the exemplary embodiment, the computing device 200 includes a presentation unit 206 that is coupled to (and is in communication with) the processor 202 (however, it should be appreciated that the computing device 200 could include output devices other than the presentation unit 206, etc.). The presentation unit 206 outputs information (e.g., tokens, etc.), either visually or audibly to a user of the computing device 200, for example, the consumer 118 in the system 100, users associated with other parts of the system 100, etc. Various interfaces (e.g., as defined by network-based applications, webpages, short message service (SMS) messages, emails, etc.) may be displayed at computing device 200, and in particular at presentation unit 206, to display such information. The presentation unit 206 may include, without limitation, a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, an “electronic ink” display, speakers, etc. In some embodiments, presentation unit 206 may include multiple devices.
The computing device 200 also includes an input device 208 that receives inputs from the user (i.e., user inputs) such as, for example, selections to purchase products, etc. The input device 208 is coupled to (and is in communication with) the processor 202 and may include, for example, a keyboard, a pointing device, a mouse, a stylus, a touch sensitive panel (e.g., a touch pad or a touch screen, etc.), another computing device, and/or an audio input device. Further, in various exemplary embodiments, a touch screen, such as that included in a tablet, a smartphone, or similar device, may behave as both the presentation unit 206 and the input device 208.
In addition, the illustrated computing device 200 also includes a network interface 210 coupled to (and in communication with) the processor 202 and the memory 204. The network interface 210 may include, without limitation, a wired network adapter, a wireless network adapter (e.g., a near field communication (NFC) adapter, a Bluetooth™ adapter, etc.), a mobile network adapter, or other device capable of communicating to/with one or more different networks, including the network 112. Further, in some exemplary embodiments, the computing device 200 may include the processor 202 and one or more network interfaces (including the network interface 210) incorporated into or with the processor 202.
Referring again to
As an example, the token service provider 114a may provision a token to the consumer 118 for his/her payment account (where, as described above, the payment account is issued to the consumer 118 by the issuer 110 and is specific to the routing payment network 106). Subsequently, in connection with a transaction between the consumer 118 and the merchant 102 involving the payment account, the consumer 118 may present the token (as associated with the consumer's payment account) to the merchant 102 in connection with funding the transaction (instead of an account number for the consumer's payment account, whereby the transaction includes/involves the token but not the actual account number or actual alpha-numeric digits representative of the account number). The token may be presented, for example, via a payment application included in the computing device 116 associated with the consumer 118, or otherwise. In turn, the merchant 102 is configured to receive the token and compile an authorization request for the transaction (e.g., including the token associated with the account; an amount of the purchase; a cryptogram associated with enhanced authentication operations, if any; etc.). The merchant 102 is configured to then transmit the authorization request to the acquirer 104, along path A in
In particular, upon receipt of the authorization request (and prior to relaying the authorization request to the issuer 110), the routing payment network 106 is configured to determine whether the token included therein is known and/or familiar to the payment network 106. If the token is known and/or familiar (e.g., where the token service provider 114a transmits the generated token to the routing payment network 106, where the routing payment network includes the token vault data structure, etc.), the routing payment network 106 is configured to convert or map that token to an account number (e.g., the PAN, etc.) for the consumer's payment account (e.g., based on a token map available to the routing payment network 106, etc.) and to append the account number to the authorization request (in addition to, or in place of, the token). The routing payment network 106 then routes the authorization request to the issuer 110 (as indicated by the account), along path A.
However, if the routing payment network 106 determines that the token is not known and/or familiar (e.g., where, as described above, the token service provider 114a instead provides the generated token to the payment network 108, etc.), the routing payment network 106 is configured to initiate a service request network message to the payment network 108 (comprising at least the token from the authorization request) (e.g., to another one of MasterCard®, VISA®, Discover®, American Express®, etc.), and specifically, to the token vault data structure 120 associated therewith (along path B in
In either case, upon receipt of the authorization request, the issuer 110 is configured to determine if the consumer's payment account is in good standing (e.g., if the consumer 118 has timely made at least one payment for any outstanding balance associated with the payment account, if there are no overdue balances for the payment account, etc.) and if there is sufficient funds and/or credit to cover the transaction. In addition, and as applicable, the issuer 110 is configured to validate any cryptogram included in the authorization request. Then, if the transaction is approved/validated by the issuer 110, the issuer 110 is configured to transmit an authorization reply (indicating the approval of the transaction) back to the acquirer 104 and the merchant 102, via the routing payment network 106, again along path A, thereby permitting the merchant 102 to complete the transaction. The authorization reply typically includes the token and the PAN, in whole or in part (e.g., the authorization reply may include the token and the last four digits of the PAN, etc.). Clearing and settlement of the transaction may then be performed based on the PAN for the consumer's payment account (as the PAN is available to both payment networks 106 and 108). And, the issuer 110 is configured to transmit transaction history detail to the computing device 116, as desired.
The transaction, when approved, is later cleared and/or settled by and between the merchant 102, the acquirer 104, and the issuer 110. If the transaction is declined by the issuer 110, however, an authorization reply (indicating a decline of the transaction) is provided by the issuer 110 back to the merchant 102, thereby permitting the merchant 102 to halt or terminate the transaction or to request an alternative form of payment.
While the system 100 is described above in connection with tokenization of account numbers for payment accounts, it should be appreciated that the system 100 may also be implemented in connection with Automated Clearing House (ACH) transactions (and tokenization of account numbers in connection therewith). For example, ACH transactions generally permit originating financial institutions to deposit and/or withdraw funds to/from accounts, based on permissions from account holders associated with the accounts. Such ACH transactions are often used, for example, to fund transactions involving utility bills, tax bills, and other bills via bill pay applications, and to deposit funds associated with directly deposited wages and tax refunds (among others). In connection therewith, consumer's associated with the accounts may provide tokens for use in the transactions in lieu of account numbers. As such, in connection with processing the transactions, the tokens may be stored in the common token vault data structure 120 as discussed above, or in another common data structure (e.g., apart from the payment network 108, etc.), whereby an ACH network may then request an account number for a given account based on a token provided by a consumer in connection with an underlying ACH transaction.
At the outset in the method 300, the payment network 108 accumulates tokens from multiple token service providers, including the token service providers 114a-b. Specifically, as shown in
Subsequently in the method 300, the consumer 118 performs a transaction at the merchant 102 using his/her payment account (as generally described above in the system 100). In connection therewith, the consumer 118 presents the token for his/her payment account to the merchant 102 (as provided by the token service provider 114a) in lieu of the account number. The merchant 102 receives the token and compiles an authorization request for the transaction (e.g., including the token associated with the account; an amount of the purchase; a cryptogram associated with enhanced authentication operations, if any; etc.). The merchant 102 then transmits the authorization request to the acquirer 104.
In turn, at 306, the acquirer 104 forwards the authorization request for the transaction, from the merchant 102, to the routing payment network 106. Upon receipt of the authorization request, the routing payment network 106 determines, at 308, whether the token is familiar or known to the routing payment network 106. Specifically, for example, the routing payment network 106 may include or be associated with one or more token service providers (such as the token service providers 114a-b), where the payment network 106 (directly or indirectly) generates and/or provisions tokens for payment accounts (such as to the consumer 118). As such, certain tokens may be familiar or known to the routing payment network 106, whereby it is able to convert the tokens (via a token vault data structure) to the corresponding account numbers directly and without interacting with the payment network 108. When the token, therefore, is familiar to the routing payment network 108, the method 300 is ended, and the routing payment network 106 continues as is conventional in connection with tokenized transactions.
Conversely, if the token is unfamiliar or unknown to the routing payment network 106, the routing payment network 106 transmits, at 310, a service request network message (broadly, a request or a network request message) to the payment network 108. The network message may include, for example, an ISO 8583 message, such as an 0100 request message, an 0120 request message, an 0400 request message, or another ISO request message, etc. Alternatively, the message to the payment network 108 may include a call to an application programming interface (API) exposed by the payment network 108. Regardless of the form, the message includes the consumer's token presented in the transaction. In response, the payment network 108 converts the token to the account number for the consumer's payment account. In particular, the payment network 108 accesses the token vault data structure 120 and searches, at 312, within the token maps in the token vault data structure 120 for the token. When the token is identified, the payment network 108 converts, at 314, the token to the account number identified in the search as being associated with the token. The payment network 108 then transmits the identified account number, at 316, back to the routing payment network 106, via a response message, such as, for example, an 0110 response message (to an 0100 request message), an 0130 response message (to an 0120 request message), an 0410 response message (to an 0400 request message), or an API response, etc.
Upon receiving the account number for the consumer's payment account from the payment network 108, the routing payment network 106 appends the account number to the authorization request (in place of the token or in addition to the token) and transmits, at 318, the authorization request to the issuer 110 of the payment account. For example, the account number permits the routing payment network 106 to identify the specific issuer 110 associated with the consumer's payment account (e.g., based on a bank identification number (BIN) range included in the PAN for the payment account, etc.). What's more, where the routing payment network 106 applies value added services, based on the identified issuer 110, and/or the identified BIN range, etc., the routing payment network 106 is further able to appropriately apply the services when the account number is received from the payment network 108 and identified to the specific one or more of the value added services.
In turn, the issuer 110 determines, at 320, whether to approve the transaction, or not, based in part on the account number included the authorization request. In connection therewith, for example, the issuer 110 may determine if the consumer's account associated with the account number is in good standing. In addition, the issuer 110 may validate a cryptogram included in the authorization message (when such cryptogram is present). Or, the one of the payment networks 106 and 108 may validate the cryptogram in the authorization message on behalf of the issuer 110 (e.g., where the one of the payment networks 106 and 108 include the issuers keys to allow for decrypting the cryptogram, etc.). When the issuer 110 determines to approve (or decline) the transaction, the issuer 110 compiles and transmits, at 322, an authorization reply to the routing payment network 106. The authorization reply includes the account number for the consumer's payment account (e.g., the PAN, etc.) and an indication of whether the transaction is approved or declined. In addition, in some implementations of the system 300, the authorization replay may also include the token. The routing payment network 106 then forwards the authorization reply to the acquirer 104, at 324, whereupon the acquirer 104 is able to provide the authorization reply to the merchant 102 (so that the merchant 102 can continue in the transaction (when approved), or halt the transaction (when declined)).
In addition in the method 300, the issuer 110 (and not the routing payment network 106) may transmit transaction details, or a transaction history, to the consumer 118 at the payment application through which the token was issued, or other network-based application, at the computing device 116.
It should be appreciated that in various transactions the payment network 108 may operate as the routing payment network, for example, when authorization requests for transactions are provided to the payment network 108. As such, the payment network 108 is also generally able to receive authorization requests and to transmit the authorization requests to the issuer 110, for example, consistent with the description herein. What's more, in various transactions (and as generally described above) the routing payment network 106 may include the token vault data structure, whereby transactions routed through the routing payment network 106 and including the token may be mapped to the consumer's payment account by the routing payment network 106, via the token vault data structure.
In view of the above, the systems and methods herein permit a routing payment network to properly route transaction messages even when the messages include tokens that are unfamiliar and/or unknown to the routing payment network. As such, when a non “front of card” payment network is involved in a transaction, based on the type of the transaction and/or a location of the transaction, for example, a token included in the corresponding transaction message is not problematic for the routing payment network. Rather, the routing payment network is able to transmit a service request network message to retrieve the payment account number (e.g., PAN, etc.) associated with the token and continue in the transaction. In connection therewith, another payment network may include a token vault data structure, in which tokens are stored from one or multiple token service providers, to thereby provide a central handling of token-inclusive network messages and detokenization of the same. As such, efficiencies are gained by the central handling of the tokens, at the data structure, in that routing payment networks are able to handle network messages by interaction with the central data structure, regardless of whether the tokens included in the messages are known to the routing payment network, or not.
Again, and as previously described, it should be appreciated that the functions described herein, in some embodiments, may be described in computer executable instructions stored on a computer-readable media, and executable by one or more processors. The computer-readable media is a non-transitory computer-readable storage medium. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Combinations of the above should also be included within the scope of computer-readable media.
It should also be appreciated that one or more aspects of the present disclosure transform a general-purpose computing device into a special-purpose computing device when configured to perform the functions, methods, and/or processes described herein.
As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one of the following operations: (a) receiving, by a payment network computing device, a token provisioned to a payment account and storing the token in a data structure coupled to the computing device; (b) receiving, by the payment network computing device, a request from a routing payment network for an account number associated with the payment account in connection with a purchase transaction involving the payment account, the request including the token provisioned to the payment account but not an actual account number for the payment account; (c) identifying the token in the data structure and converting, by the payment network computing device, the token to the account number for the payment account; (d) transmitting, by the payment network computing device, the account number to the routing payment network, whereby the routing payment network can append the account number to an authorization request for the transaction in connection with directing the authorization request to an issuer of the payment account thereby permitting the issuer to approve or decline the transaction based, at least in part, on the account number appended to the authorization request; (e) receiving, by the payment network computing device, an authorization request associated with a second transaction, the authorization request including a second token associated with a second payment account; (f) converting, by the payment network computing device, the second token to a second account number associated with the second payment account based on a listing of tokens in the data structure; and (g) transmitting, by the payment network computing device, the authorization request associated with the second transaction, including the second account number, to an issuer of the second payment account, thereby permitting the issuer to approve or decline the second transaction.
Exemplary embodiments are provided so that this disclosure will be thorough, and will fully convey the scope to those who are skilled in the art. Numerous specific details are set forth, such as examples of specific components, devices, and methods, to provide a thorough understanding of embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be employed, that example embodiments may be embodied in many different forms, and that neither should be construed to limit the scope of the disclosure. In some example embodiments, well-known processes, well-known device structures, and well-known technologies are not described in detail.
The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” may be intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises,” “comprising,” “including,” and “having,” are inclusive and therefore specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed.
When a feature is referred to as being “on,” “engaged to,” “connected to,” “coupled to,” “associated with,” “included with,” or “in communication with” another feature, it may be directly on, engaged, connected, coupled, associated, included, or in communication to or with the other feature, or intervening features may be present. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
Although the terms first, second, third, etc. may be used herein to describe various features, these features should not be limited by these terms. These terms may be only used to distinguish one feature from another. Terms such as “first,” “second,” and other numerical terms when used herein do not imply a sequence or order unless clearly indicated by the context. Thus, a first feature discussed herein could be termed a second feature without departing from the teachings of the example embodiments.
None of the elements recited in the claims are intended to be a means-plus-function element within the meaning of 35 U.S.C. § 112(f) unless an element is expressly recited using the phrase “means for,” or in the case of a method claim using the phrases “operation for” or “step for.”
The foregoing description of exemplary embodiments has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but, where applicable, are interchangeable and can be used in a selected embodiment, even if not specifically shown or described. The same may also be varied in many ways. Such variations are not to be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.