US20200302442A1 - Systems and methods for tokenizing tokens in transactions - Google Patents
Systems and methods for tokenizing tokens in transactions Download PDFInfo
- Publication number
- US20200302442A1 US20200302442A1 US16/723,359 US201916723359A US2020302442A1 US 20200302442 A1 US20200302442 A1 US 20200302442A1 US 201916723359 A US201916723359 A US 201916723359A US 2020302442 A1 US2020302442 A1 US 2020302442A1
- Authority
- US
- United States
- Prior art keywords
- token
- sub
- pan
- payment
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
- G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q2220/00—Business processing using cryptography
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
Definitions
- Tokenization Standard In November 2013, MasterCard International Incorporated (the assignee hereof), Visa and American Express jointly published guidelines entitled “Payment Token Interoperability Standard” (hereinafter referred to as the “Tokenization Standard”).
- the Tokenization Standard referred to a concept called “tokenization,” in which surrogate values (“tokens”) replace primary account numbers (PANs) of payment cards (such as credit or debit cards) during part of the operation of payment systems.
- PANs primary account numbers
- the PAN associated with a consumer's payment card is converted into a token by a token service provider (e.g., the PAN is “tokenized”). Then, the consumer can cause the token to conduct transactions rather than using the PAN.
- a token service provider e.g., the PAN is “tokenized”.
- FIG. 1 is a block diagram that illustrates a system pursuant to some embodiments.
- FIG. 2 illustrates a mapping of tokens and sub-tokens to PANs that may occur in the system of FIG. 1 pursuant to some embodiments.
- FIG. 3 is a portion of a platform that may be used in the system of FIG. 1 pursuant to some embodiments.
- FIG. 4 is a tabular portion of a user database according to some embodiments.
- FIG. 5 is a flow diagram that illustrates a process that may be performed pursuant to some embodiments.
- FIG. 6 is a user interface that illustrates a user interaction pursuant to some embodiments.
- PAN or “payment credential” will be generally used to refer to a payment account number or identifier issued by a financial institution to a user (such as a “consumer”).
- the term “consumer” is used herein to refer to a holder of a PAN or payment credential, and may refer to an individual or an entity such as a business.
- the term “primary token” refers to a payment token that is associated with a PAN or payment credential and that can directly be used by a token service provider or other entity or service provider to identify the PAN or payment credential.
- sub-token or “secondary token” refers to a token associated with a primary token (where the sub-token is generated from the primary token).
- tertiary token refers to a token associated with a sub-token or secondary token (or another tertiary token).
- Each of the primary token, and any sub-tokens or tertiary tokens may be referred to simply as a “token” or “payment token”.
- Each token may be generated using a tokenization service such as the MasterCard Digital Enablement Service (“MDES”) or the like.
- MDES MasterCard Digital Enablement Service
- Each token associated with a PAN may be used to conduct financial transactions associated with the payment account associated with the PAN.
- the consumer may be associated with an account associated with the platform.
- a consumer may have an account on a social network platform. The account may uniquely identify the consumer to the social network platform.
- the consumer may establish a primary token associated with a PAN or payment credential for use in transactions facilitated by or through the platform.
- the consumer may interact with the platform to establish one or more sub-tokens (and/or tertiary tokens) of the payment credential for use with specific transactions or groups of transactions.
- a consumer may establish a sub-token of a payment credential for use in a specific transaction that the consumer wishes to track or control separately.
- FIG. 1 also includes a block 104 that represents a token service provider.
- the token service provider 104 may in some embodiments also be the operator of a payment network (block 106 ), such as that operated by MasterCard International Incorporated, the assignee hereof
- the token service provider 104 may be authorized in the system 100 to issue tokens to token requestors (one such token requestor may be, for example, the platform 108 ).
- the token service provider 104 may perform such functions as operating and maintaining a token vault 110 , generating and issuing tokens (in accordance, e.g., with aspects of the present disclosure), assuring security and proper controls, token provisioning (e.g., personalizing payment cards, etc. with token values), and registering token requestors.
- the token service provider 104 is further operable to generate sub-tokens and tertiary tokens from primary tokens.
- block 104 should also be understood to represent one or more computer systems operated by the token service provider.
- the token service provider 104 may further be configured to implement functionality of the MasterCard Digital Enablement Service (“MDES”), a service of MasterCard International Incorporated, the assignee hereof.
- MDES MasterCard Digital Enablement Service
- the token service provider 104 may be configured to operate to tokenize payment card information according to other standards or using other infrastructure, so long as the tokens are usable in payment transactions as described herein.
- Block 112 in FIG. 1 represents an issuer of payment card accounts held by the consumer 102 .
- the issuer 112 may include a number of systems and components operated by or on behalf of a financial institution that issues payment card accounts to individual consumers 102 .
- the issuer 112 may perform such functions as (a) receiving and responding to requests for authorization of payment card account transactions to be charged to payment accounts issued by the financial institution and (b) tracking and storing transactions and maintaining account records.
- Block 114 in FIG. 1 represents a merchant that a consumer 102 may transact with. As shown, consumer 102 transacts with the merchant 114 via the platform 108 .
- the merchant 114 may be a merchant that provides video on demand (such as Netflix® or Amazon®, etc.), and a consumer 102 may wish to rent or purchase a video from the merchant 114 .
- the consumer 102 may obtain a payment token by interacting with the platform 108 and cause the platform 108 to present the payment token to the merchant 114 for the goods or services.
- the payment token may be generated by or on behalf of the platform 108 from another token previously created for the consumer 102 .
- the merchant 114 upon receipt of the payment token, uses the payment token to initiate processing of a payment transaction using the payment token.
- the merchant 114 may cause a payment authorization request to be processed through an acquirer 116 .
- the acquirer 116 may be a financial institution that provides banking services to the merchant 114 , and that receives and routes authorization requests originated from the merchant 114 .
- the payment authorization request is routed from the acquirer 116 through a payment network 106 to an issuer 112 of the payment account associated with the payment token.
- a payment network 106 is referred to as the “Banknet” system, and is operated by MasterCard International Incorporated, which is the assignee hereof.
- system 100 may include numerous consumers 102 , platforms 108 , merchants 114 , acquirers 116 , and issuers 112 . Further, multiple token service providers 104 , payment networks 106 and token vaults 110 may also be provided.
- FIG. 2 where a variety of PAN and token mapping relationships are shown. These relationships may be maintained and managed, for example, by a token service provider 104 based on requests received from entities such as the platform 108 . Each of the tokens and their relationships to a PAN may be stored in a secure database such as, for example, a token vault 110 associated with the token service provider 104 .
- Each PAN 202 a - n may, for example, be associated with one or more primary tokens 202 a - 1 , etc.
- Each PAN 202 a - n may also, for example, be associated with one or more sub-tokens 202 a - 1 a , etc.
- additional layers of tokens may also be provided (e.g., such as tertiary or other tokens). As shown, a number of primary tokens 202 a - 1 to 202 a - n are mapped to PAN 202 a.
- a number of sub-tokens 202 a - 1 a to 202 a - nx are also mapped to PAN 202 a.
- Each of the tokens shown as having a relationship with a PAN are usable to conduct transactions involving that PAN through operation of the system 100 .
- FIG. 3 is a block diagram representation of a computer system that may be operated by the token service provider in accordance with aspects of the present disclosure.
- This computer system indicated by reference numeral 104 , may be referred to as the “token service provider computer 104 ” and may perform at least some functions in accordance with aspects of the present disclosure.
- the token service provider computer 104 may be configured to receive requests from a token requestor, such as platform 108 , to generate primary tokens, sub-tokens and tertiary tokens that correspond to PANs of consumers that interact with the platform 108 .
- the token service provider computer 104 may be conventional in its hardware aspects but may be controlled by software to cause it to function as described herein.
- the token service provider computer 104 may be constituted by conventional server computer hardware.
- functionality disclosed herein may be distributed among two or more computers having hardware architecture similar to that described below.
- the computer processor 300 may be constituted by one or more conventional processors. Processor 300 operates to execute processor-executable steps, contained in program instructions described below, so as to control the token service provider computer 104 to provide desired functionality.
- Communication device 301 may be used to facilitate communication with, for example, other devices (such as other components of the system 100 shown in FIG. 1 ).
- communication device 301 may comprise numerous communication ports (not separately shown), to allow the token service provider computer 104 to communicate simultaneously with a number of other computers and other devices, including communication with the platform 108 .
- Input device 306 may comprise one or more of any type of peripheral device typically used to input data into a computer.
- the input device 306 may include a keyboard and a mouse.
- Output device 308 may comprise, for example, a display and/or a printer.
- the programs may include one or more conventional operating systems (not shown) that control the processor 300 so as to manage and coordinate activities and sharing of resources in the token service provider computer 104 , and to serve as a host for application programs (described below) that run on the token service provider computer 104 .
- the programs stored in the storage device 304 may also include a token generation program 310 that controls the processor 300 to enable the token service provider computer 104 to generate tokens based on token creation requests received from devices such as the platform 108 . Details of some of the functionality provided by the token generation program 310 will be discussed below in conjunction with FIG. 5 .
- Another program that may be stored in the storage device 304 is an application program or program module 312 that controls the processor 300 to enable the token service provider computer 104 to generate a mapping of tokens relative to the PANs that they represent.
- This program 312 will hereafter be referred to as the token map generation application program; functionality thereof will be described below in conjunction with FIG. 5 .
- the storage device 304 may further store a program/program module 318 that enables the token service provider computer 104 to perform de-tokenization with respect to tokens that it receives for that purpose.
- the de-tokenization enabled by program/program module 318 may in general be consistent with the proposals contained in the above-referenced Tokenization Standard.
- “de-tokenization” refers to substituting a PAN for a token that represented the PAN.
- Embodiments described herein further allow the substitution of a PAN for a sub-token, a tertiary token or a primary token that represented the PAN.
- At least some of the functionality ascribed below to the token service provider computer 104 may alternatively be performed by another computer or computers in the system 100 of FIG. 1 (e.g., by a computer or computers operated by the issuer 112 or by the acquirer 116 ).
- Such computer or computers may have essentially the same hardware architecture as the token service provider computer 104 , and like the token service provider computer 104 , may be programmed by suitable software program instructions to provide functionality as described herein.
- FIG. 4 is a tabular representation of a portion of a token data table 400 in accordance with some embodiments of the present invention.
- the table 400 includes entries associated with different users of a platform 108 and different tokens and token authorization parameters.
- the table 400 also defines fields for each of the entries. The fields might specify a user identifier 402 (associated with a user identifier provided by a system such as platform 108 to uniquely identify users of the platform 108 ), a token 404 (associated with a primary token, a sub-token or a tertiary token), and a token type 406 (specifying whether the token is a primary token, a sub-token or a tertiary token), an expiry date 408 of the token.
- a user identifier 402 associated with a user identifier provided by a system such as platform 108 to uniquely identify users of the platform 108
- a token 404 associated with a primary token, a sub-token or a tertiary token
- additional information may also be provided in the form of one or more authorization parameter(s) 410 that have been provided by a system such as platform 108 .
- the authorization parameter(s) may be used to control how and where the token 404 may be used, and may include authorization controls such as a limitation to a specific merchant category code (“MCC”) or group of categories, authorization limits (such as a spend limit), or the like.
- MCC merchant category code
- each token 404 may also be associated with information identifying the parent token 412 which the token 404 is related to.
- the information in the database 400 may be periodically created and updated based on information received from, for example, platform 108 or other components of system 100 .
- FIG. 5 is a flow chart that illustrates a process 500 that may be performed in accordance with aspects of the present disclosure.
- the process steps illustrated in FIG. 5 may be performed by the token service provider computer 104 and/or by a computer or computers operated by the issuer 112 ( FIG. 1 ).
- the process 500 is performed by the token service provider computer 104 in response to messages, requests or instructions received from platform 108 .
- a user may interact with platform 108 , and that interaction may cause the platform 108 to submit requests to the token service provider computer 104 to perform the process 500 (e.g., to create a sub-token from a primary token associated with the consumer's account with the provider 108 in order to use the sub-token for one or more transactions).
- the process 500 e.g., to create a sub-token from a primary token associated with the consumer's account with the provider 108 in order to use the sub-token for one or more transactions.
- a sub-token associated with the token and the PAN is generated.
- the sub-token may be generated using, for example, a tokenization process such as the MDES process or the like.
- a tokenization process such as the MDES process or the like.
- the token service provider computer 104 may store sub-tokens generated at 506 in a manner such as to indicate a mapping of sub-tokens to the PANs that they represent.
- the mapping of tokens to PANS may be stored in a suitable database, such as the above-mentioned token vault 110 .
- processing at 508 may include the token service provider computer 104 transmitting the sub-token to the platform 108 .
- the sub-token may be returned in a response message to the API request described above.
- the platform 108 may then operate to store the sub-token in the consumer's user account with the platform 108 .
- the user may connect their Netflix® account with the platform such that a token issued or obtained by the platform 108 (e.g., using the process 500 discussed above) is automatically provided to or associated with the user's Netflix® account.
- the user may be provided with instructions for entering the token in the external account.
- the user may click on a name of a merchant to be taken to the user's account with the merchant so the user can administer or manage that account.
- a user may also be provided with an option to request a “new token” (e.g., using the process 500 discussed above).
- sub-tokens may be generated and managed by payment system wallets, issuer wallets, or the like.
- the term “computer” should be understood to encompass a single computer or two or more computers in communication with each other.
- processor should be understood to encompass a single processor or two or more processors in communication with each other.
- payment card network or “payment network” is used to refer to a payment network or payment system such as the systems operated by MasterCard International Incorporated (which is the assignee hereof), or other networks that process payment transactions on behalf of a number of merchants, issuers and cardholders.
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
- This application is a continuation-in-part and claims benefit of and priority to U.S. patent application Ser. No. 15/826,137 filed on Nov. 29, 2017.
- In November 2013, MasterCard International Incorporated (the assignee hereof), Visa and American Express jointly published guidelines entitled “Payment Token Interoperability Standard” (hereinafter referred to as the “Tokenization Standard”). The Tokenization Standard referred to a concept called “tokenization,” in which surrogate values (“tokens”) replace primary account numbers (PANs) of payment cards (such as credit or debit cards) during part of the operation of payment systems. One reason for using tokens in place of PANs is to combat potentially fraudulent activities.
- In a typical tokenization transaction, the PAN associated with a consumer's payment card is converted into a token by a token service provider (e.g., the PAN is “tokenized”). Then, the consumer can cause the token to conduct transactions rather than using the PAN.
- 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 system pursuant to some embodiments. -
FIG. 2 illustrates a mapping of tokens and sub-tokens to PANs that may occur in the system ofFIG. 1 pursuant to some embodiments. -
FIG. 3 is a portion of a platform that may be used in the system ofFIG. 1 pursuant to some embodiments. -
FIG. 4 is a tabular portion of a user database according to some embodiments. -
FIG. 5 is a flow diagram that illustrates a process that may be performed pursuant to some embodiments. -
FIG. 6 is a user interface that illustrates a user interaction pursuant to some embodiments. - In general, and for the purpose of introducing concepts of the present disclosure, merchants, social networks, and other platforms may operate to generate tokens associated with tokenized payment credentials. For example, pursuant to some embodiments, a consumer may interact with a platform to provide a payment credential to the platform. The platform is operated to obtain a first tokenized representation of the payment credential. Then, for each transaction (or for groups of transactions), the platform is operated to obtain one or more further tokenized representations of the first tokenized representation of the payment credential. As will be described further herein, the use of such further tokenized representations provide a number of benefits to the consumer and to the platform.
- For convenience and ease of exposition, the following terms will be used. The term “PAN” or “payment credential” will be generally used to refer to a payment account number or identifier issued by a financial institution to a user (such as a “consumer”). The term “consumer” is used herein to refer to a holder of a PAN or payment credential, and may refer to an individual or an entity such as a business. The term “primary token” refers to a payment token that is associated with a PAN or payment credential and that can directly be used by a token service provider or other entity or service provider to identify the PAN or payment credential. The term “sub-token” or “secondary token” refers to a token associated with a primary token (where the sub-token is generated from the primary token). The term “tertiary token” refers to a token associated with a sub-token or secondary token (or another tertiary token). Each of the primary token, and any sub-tokens or tertiary tokens may be referred to simply as a “token” or “payment token”. Each token may be generated using a tokenization service such as the MasterCard Digital Enablement Service (“MDES”) or the like. Each token associated with a PAN may be used to conduct financial transactions associated with the payment account associated with the PAN.
- Pursuant to some embodiments, a sub-token (or tertiary token) may be created with one or more authorization parameter(s). For example, a sub-token may be generated with an authorization parameter allowing the sub-token to be used in a specific transaction or type of transaction. As a specific illustrative, but not limiting example, the sub-token may be generated for use in a transaction at a specific merchant and/or with a specific dollar amount (e.g., the transaction may only be authorized if the sub-token is used at a Target® store for a transaction under $100).
- Pursuant to some embodiments, the consumer may be associated with an account associated with the platform. As an illustrative, but not limiting example, a consumer may have an account on a social network platform. The account may uniquely identify the consumer to the social network platform. In some embodiments, the consumer may establish a primary token associated with a PAN or payment credential for use in transactions facilitated by or through the platform. Further, pursuant to some embodiments, the consumer may interact with the platform to establish one or more sub-tokens (and/or tertiary tokens) of the payment credential for use with specific transactions or groups of transactions. As an illustrative, but not limiting example, a consumer may establish a sub-token of a payment credential for use in a specific transaction that the consumer wishes to track or control separately. These and further embodiments will be described further herein.
-
FIG. 1 is a block diagram that illustrates apayment system 100 in which teachings of the present disclosure may be applied. Individual users or payment card holders (generally, referred to herein as “consumers”) are indicated byreference numeral 102 inFIG. 1 . As shown,consumers 102 interact with aplatform 108.Platform 108 may be, for example, a platform operated by or on behalf of a social network (such as Facebook® or the like) or a platform operated by or on behalf of a network of merchants or other entities which allowconsumers 102 to create accounts and purchase goods or services as will be described further herein. -
FIG. 1 also includes ablock 104 that represents a token service provider. Thetoken service provider 104 may in some embodiments also be the operator of a payment network (block 106), such as that operated by MasterCard International Incorporated, the assignee hereof Thetoken service provider 104 may be authorized in thesystem 100 to issue tokens to token requestors (one such token requestor may be, for example, the platform 108). In issuing tokens, thetoken service provider 104 may perform such functions as operating and maintaining atoken vault 110, generating and issuing tokens (in accordance, e.g., with aspects of the present disclosure), assuring security and proper controls, token provisioning (e.g., personalizing payment cards, etc. with token values), and registering token requestors. Pursuant to some embodiments, thetoken service provider 104 is further operable to generate sub-tokens and tertiary tokens from primary tokens. - In addition to representing the token service provider,
block 104 should also be understood to represent one or more computer systems operated by the token service provider. In some embodiments, thetoken service provider 104 may further be configured to implement functionality of the MasterCard Digital Enablement Service (“MDES”), a service of MasterCard International Incorporated, the assignee hereof. Those skilled in the art will appreciate that thetoken service provider 104 may be configured to operate to tokenize payment card information according to other standards or using other infrastructure, so long as the tokens are usable in payment transactions as described herein. -
Block 112 inFIG. 1 represents an issuer of payment card accounts held by theconsumer 102. In some embodiments, some or all of the functions of thetoken service provider 104 may be taken on by theissuer 112. Theissuer 112 may include a number of systems and components operated by or on behalf of a financial institution that issues payment card accounts toindividual consumers 102. Theissuer 112 may perform such functions as (a) receiving and responding to requests for authorization of payment card account transactions to be charged to payment accounts issued by the financial institution and (b) tracking and storing transactions and maintaining account records. -
Block 114 inFIG. 1 represents a merchant that aconsumer 102 may transact with. As shown,consumer 102 transacts with themerchant 114 via theplatform 108. As an illustrative, but not limiting example, themerchant 114 may be a merchant that provides video on demand (such as Netflix® or Amazon®, etc.), and aconsumer 102 may wish to rent or purchase a video from themerchant 114. In some embodiments, theconsumer 102 may obtain a payment token by interacting with theplatform 108 and cause theplatform 108 to present the payment token to themerchant 114 for the goods or services. Pursuant to some embodiments, the payment token may be generated by or on behalf of theplatform 108 from another token previously created for theconsumer 102. Themerchant 114, upon receipt of the payment token, uses the payment token to initiate processing of a payment transaction using the payment token. For example, themerchant 114 may cause a payment authorization request to be processed through anacquirer 116. As is well known, theacquirer 116 may be a financial institution that provides banking services to themerchant 114, and that receives and routes authorization requests originated from themerchant 114. The payment authorization request is routed from theacquirer 116 through apayment network 106 to anissuer 112 of the payment account associated with the payment token. - One well known example of a
payment network 106 is referred to as the “Banknet” system, and is operated by MasterCard International Incorporated, which is the assignee hereof. - While only individual blocks are shown in
FIG. 1 for simplicity, those skilled in the art will appreciate that a practical embodiment of thesystem 100 may includenumerous consumers 102,platforms 108,merchants 114,acquirers 116, andissuers 112. Further, multipletoken service providers 104,payment networks 106 andtoken vaults 110 may also be provided. - As discussed above, multiple levels or layers of tokens may be used pursuant to some embodiments of the present invention. To further illustrate features of some embodiments, reference is now made to
FIG. 2 , where a variety of PAN and token mapping relationships are shown. These relationships may be maintained and managed, for example, by atoken service provider 104 based on requests received from entities such as theplatform 108. Each of the tokens and their relationships to a PAN may be stored in a secure database such as, for example, atoken vault 110 associated with thetoken service provider 104. - Each PAN 202 a-n may, for example, be associated with one or more primary tokens 202 a-1, etc. Each PAN 202 a-n may also, for example, be associated with one or more sub-tokens 202 a-1 a, etc. Those skilled in the art, upon reading this disclosure, will appreciate that additional layers of tokens may also be provided (e.g., such as tertiary or other tokens). As shown, a number of primary tokens 202 a-1 to 202 a-n are mapped to
PAN 202 a. A number of sub-tokens 202 a-1 a to 202 a-nx are also mapped toPAN 202 a. Each of the tokens shown as having a relationship with a PAN are usable to conduct transactions involving that PAN through operation of thesystem 100. - In some situations, a PAN (such as
PAN 202 b) is associated with a single primary token (such astoken 202 b-1) and a single sub-token (such astoken 202 b-1 a). In some situations, a PAN (such asPAN 202 n) is associated with a single primary token (such astoken 202 n-1) and multiple sub-tokens (such astoken 202 n-1 a-202 n-1 x). A wide variety of different combinations and permutations may be provided. Although only three PANs are explicitly shown intoken vault 110 inFIG. 2 , in practice, the number of PANs stored therein, with tokens mapped thereto, may be quite a large number. -
FIG. 3 is a block diagram representation of a computer system that may be operated by the token service provider in accordance with aspects of the present disclosure. This computer system, indicated byreference numeral 104, may be referred to as the “tokenservice provider computer 104” and may perform at least some functions in accordance with aspects of the present disclosure. For example, the tokenservice provider computer 104 may be configured to receive requests from a token requestor, such asplatform 108, to generate primary tokens, sub-tokens and tertiary tokens that correspond to PANs of consumers that interact with theplatform 108. - The token
service provider computer 104 may be conventional in its hardware aspects but may be controlled by software to cause it to function as described herein. For example, the tokenservice provider computer 104 may be constituted by conventional server computer hardware. In some embodiments, functionality disclosed herein may be distributed among two or more computers having hardware architecture similar to that described below. - The token
service provider computer 104 may include acomputer processor 300 operatively coupled to acommunication device 301, astorage device 304, aninput device 306 and anoutput device 308. - The
computer processor 300 may be constituted by one or more conventional processors.Processor 300 operates to execute processor-executable steps, contained in program instructions described below, so as to control the tokenservice provider computer 104 to provide desired functionality. -
Communication device 301 may be used to facilitate communication with, for example, other devices (such as other components of thesystem 100 shown inFIG. 1 ). For example (and continuing to refer toFIG. 3 ),communication device 301 may comprise numerous communication ports (not separately shown), to allow the tokenservice provider computer 104 to communicate simultaneously with a number of other computers and other devices, including communication with theplatform 108. -
Input device 306 may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, theinput device 306 may include a keyboard and a mouse.Output device 308 may comprise, for example, a display and/or a printer. -
Storage device 304 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and 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 device 304 stores one or more programs for controllingprocessor 300. The programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of the tokenservice provider computer 104, executed by theprocessor 300 to cause the tokenservice provider computer 104 to function as described herein. - The programs may include one or more conventional operating systems (not shown) that control the
processor 300 so as to manage and coordinate activities and sharing of resources in the tokenservice provider computer 104, and to serve as a host for application programs (described below) that run on the tokenservice provider computer 104. - The programs stored in the
storage device 304 may also include atoken generation program 310 that controls theprocessor 300 to enable the tokenservice provider computer 104 to generate tokens based on token creation requests received from devices such as theplatform 108. Details of some of the functionality provided by thetoken generation program 310 will be discussed below in conjunction withFIG. 5 . - Another program that may be stored in the
storage device 304 is an application program orprogram module 312 that controls theprocessor 300 to enable the tokenservice provider computer 104 to generate a mapping of tokens relative to the PANs that they represent. Thisprogram 312 will hereafter be referred to as the token map generation application program; functionality thereof will be described below in conjunction withFIG. 5 . - Moreover, the
storage device 304 may further store a program/program module 318 that enables the tokenservice provider computer 104 to perform de-tokenization with respect to tokens that it receives for that purpose. The de-tokenization enabled by program/program module 318 may in general be consistent with the proposals contained in the above-referenced Tokenization Standard. As is known to those who are skilled in the art, “de-tokenization” refers to substituting a PAN for a token that represented the PAN. Embodiments described herein further allow the substitution of a PAN for a sub-token, a tertiary token or a primary token that represented the PAN. - The
storage device 304 may also store, and the tokenservice provider computer 104 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 the tokenservice provider computer 104. The other programs may also include, e.g., communication software, database management software, device drivers, etc. - The
storage device 304 may also store one ormore databases 320 required for operation of the tokenservice provider computer 104. Thosedatabases 320 may, for example, include thetoken vault 110 shown inFIG. 1 . - In some embodiments, at least some of the functionality ascribed below to the token
service provider computer 104 may alternatively be performed by another computer or computers in thesystem 100 ofFIG. 1 (e.g., by a computer or computers operated by theissuer 112 or by the acquirer 116). Such computer or computers may have essentially the same hardware architecture as the tokenservice provider computer 104, and like the tokenservice provider computer 104, may be programmed by suitable software program instructions to provide functionality as described herein. -
FIG. 4 is a tabular representation of a portion of a token data table 400 in accordance with some embodiments of the present invention. The table 400 includes entries associated with different users of aplatform 108 and different tokens and token authorization parameters. The table 400 also defines fields for each of the entries. The fields might specify a user identifier 402 (associated with a user identifier provided by a system such asplatform 108 to uniquely identify users of the platform 108), a token 404 (associated with a primary token, a sub-token or a tertiary token), and a token type 406 (specifying whether the token is a primary token, a sub-token or a tertiary token), anexpiry date 408 of the token. Pursuant to some embodiments, additional information may also be provided in the form of one or more authorization parameter(s) 410 that have been provided by a system such asplatform 108. The authorization parameter(s) may be used to control how and where the token 404 may be used, and may include authorization controls such as a limitation to a specific merchant category code (“MCC”) or group of categories, authorization limits (such as a spend limit), or the like. In some embodiments, each token 404 may also be associated with information identifying theparent token 412 which the token 404 is related to. The information in thedatabase 400 may be periodically created and updated based on information received from, for example,platform 108 or other components ofsystem 100. -
FIG. 5 is a flow chart that illustrates aprocess 500 that may be performed in accordance with aspects of the present disclosure. The process steps illustrated inFIG. 5 may be performed by the tokenservice provider computer 104 and/or by a computer or computers operated by the issuer 112 (FIG. 1 ). In some embodiments, theprocess 500 is performed by the tokenservice provider computer 104 in response to messages, requests or instructions received fromplatform 108. For example, a user (such as a consumer 102) may interact withplatform 108, and that interaction may cause theplatform 108 to submit requests to the tokenservice provider computer 104 to perform the process 500 (e.g., to create a sub-token from a primary token associated with the consumer's account with theprovider 108 in order to use the sub-token for one or more transactions). -
Process 500 may begin at 502 where a token is received (which may be, for example, a “primary token” associated with a user's account at platform 108) as well as a request to generate a sub-token based on the token. For example, the request may be received pursuant to an application programming interface (API) of the token service provider computer 104 (e.g., such as an API method to generate a sub-token). Processing continues at 504 where an association between the token and a primary account number (PAN) of a user is identified. For example, processing at 504 may include operating the tokenservice provider computer 104 to confirm the validity of the token and to look up or otherwise confirm its association with a PAN. - Processing continues at 506 where a sub-token associated with the token and the PAN is generated. The sub-token may be generated using, for example, a tokenization process such as the MDES process or the like. Once the sub-token is generated, the association between the generated sub-token, the primary token, and the PAN is recorded for further reference. The token
service provider computer 104 may store sub-tokens generated at 506 in a manner such as to indicate a mapping of sub-tokens to the PANs that they represent. The mapping of tokens to PANS may be stored in a suitable database, such as the above-mentionedtoken vault 110. - The generated sub-token is then provided for use in a payment transaction at 508. For example, processing at 508 may include the token
service provider computer 104 transmitting the sub-token to theplatform 108. For example, the sub-token may be returned in a response message to the API request described above. Theplatform 108 may then operate to store the sub-token in the consumer's user account with theplatform 108. - Pursuant to some embodiments,
platform 108 may include features and user interfaces that allow users of the platform (such as customers 102) to manage their tokens. For example, referring toFIG. 6 (where anillustrative user interface 602 is shown that may be displayed on a display device of a device operated by customer 102),platform 108 may allow a user to view tokens and transactions associated therewith. In theillustrative user interface 602, a user has had separate tokens (or sub-tokens) issued for use with specific merchants or retailers. The user may be permitted to cancel or update the details of each or all of the tokens to manage their use. For example, in some embodiments, the user may connect merchant accounts with the user's account on theplatform 108. As a specific illustrative example, the user may connect their Netflix® account with the platform such that a token issued or obtained by the platform 108 (e.g., using theprocess 500 discussed above) is automatically provided to or associated with the user's Netflix® account. In some embodiments, rather than automatically providing the token to the user's external account, the user may be provided with instructions for entering the token in the external account. In theillustrative user interface 600, the user may click on a name of a merchant to be taken to the user's account with the merchant so the user can administer or manage that account. As shown in theillustrative user interface 600, a user may also be provided with an option to request a “new token” (e.g., using theprocess 500 discussed above). Other user interfaces may also be provided to allow users to manage the issuance and use of tokens and sub-tokens. While some embodiments have been described for use with aplatform 108, those skilled in the art, upon reading this disclosure, will appreciate that the generation and use of sub-tokens as described herein may be used without aplatform 108. For example, sub-tokens may be generated and managed by payment system wallets, issuer wallets, or the like. - 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.
- The term “payment card network” or “payment network” is used to refer to a payment network or payment system such as the systems operated by MasterCard International Incorporated (which is the assignee hereof), or other networks that process payment transactions on behalf of a number of merchants, issuers and cardholders.
- As used herein and in the appended claims, the term “payment card system account” includes a credit card account, a deposit account that the account holder may access using a debit card, a prepaid card account, or any other type of account from which payment transactions may be consummated. The terms “payment card system account” and “payment card 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, debit card, prepaid card, or other type of payment instrument, whether an actual physical card or virtual.
- Although the present disclosure has been described 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 (14)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/723,359 US20200302442A1 (en) | 2017-05-10 | 2019-12-20 | Systems and methods for tokenizing tokens in transactions |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201762504219P | 2017-05-10 | 2017-05-10 | |
US15/826,137 US20190164155A1 (en) | 2017-11-29 | 2017-11-29 | Systems and methods for tokenizing tokens in transactions |
US16/723,359 US20200302442A1 (en) | 2017-05-10 | 2019-12-20 | Systems and methods for tokenizing tokens in transactions |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/826,137 Continuation-In-Part US20190164155A1 (en) | 2017-05-10 | 2017-11-29 | Systems and methods for tokenizing tokens in transactions |
Publications (1)
Publication Number | Publication Date |
---|---|
US20200302442A1 true US20200302442A1 (en) | 2020-09-24 |
Family
ID=72515554
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/723,359 Abandoned US20200302442A1 (en) | 2017-05-10 | 2019-12-20 | Systems and methods for tokenizing tokens in transactions |
Country Status (1)
Country | Link |
---|---|
US (1) | US20200302442A1 (en) |
Citations (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070038525A1 (en) * | 2005-08-15 | 2007-02-15 | Waldvogel Richard T | Systems and Methods of Managing Retailer Affiliate Programs |
US20110213807A1 (en) * | 2010-03-01 | 2011-09-01 | Ulf Mattsson | System and method for distributed tokenization using several substitution steps |
US20120255994A1 (en) * | 2006-12-07 | 2012-10-11 | Smart Systems Innovations, Llc | Mass transit fare processing system |
US20120330846A1 (en) * | 2011-06-27 | 2012-12-27 | Accenture Global Services Limited | Dynamic electronic money |
US20140032419A1 (en) * | 2012-07-26 | 2014-01-30 | Lisa Anderson | Configurable payment tokens |
US20140143144A1 (en) * | 2012-11-20 | 2014-05-22 | Mastercard International Incorporated | Systems and methods for processing electronic payments using a global payment directory |
US20150095240A1 (en) * | 2013-09-30 | 2015-04-02 | Fiserv, Inc. | Card account identifiers associated with conditions for temporary use |
US20150106239A1 (en) * | 2013-10-11 | 2015-04-16 | Ajit Gaddam | Tokenization revocation list |
US20150112870A1 (en) * | 2013-10-18 | 2015-04-23 | Sekhar Nagasundaram | Contextual transaction token methods and systems |
US20150199679A1 (en) * | 2014-01-13 | 2015-07-16 | Karthikeyan Palanisamy | Multiple token provisioning |
US20150199873A1 (en) * | 2014-01-10 | 2015-07-16 | PayNearMe | Systems and methods for cash payments for online gaming |
US20150242853A1 (en) * | 2014-02-26 | 2015-08-27 | Mastercard International Incorporated | Payment account tokenization method |
US20150254699A1 (en) * | 2014-03-04 | 2015-09-10 | Bank Of America Corporation | Providing offers associated with payment credentials in digital wallets |
US20160224977A1 (en) * | 2015-01-30 | 2016-08-04 | Yaasha Sabba | Token check offline |
US20160239833A1 (en) * | 2015-02-17 | 2016-08-18 | Mastercard Asia/Pacific Pte. Ltd. | Methods and systems for processing an electronic payment |
US20160321652A1 (en) * | 2015-04-30 | 2016-11-03 | James Dimmick | Tokenization Capable Authentication Framework |
US9626674B1 (en) * | 2007-09-26 | 2017-04-18 | Gregory J. Wolff | System and method for exchanging, sharing and redeeming credits |
US9734652B1 (en) * | 2016-05-16 | 2017-08-15 | Paypal, Inc. | Simulating I/O using multicomputer data processing |
US20170249622A1 (en) * | 2012-10-17 | 2017-08-31 | Royal Bank Of Canada | Systems, methods, and devices for secure generation and processing of data sets representing pre-funded payments |
US20170270521A1 (en) * | 2016-03-21 | 2017-09-21 | Mastercard International Incorporated | Systems and Methods for Use in Providing Payment Transaction Notifications |
US20170300895A1 (en) * | 2016-04-13 | 2017-10-19 | Mastercard International Incorporated | System and method for peer-to-peer assistance in provisioning payment tokens to mobile devices |
US20170316405A1 (en) * | 2016-05-02 | 2017-11-02 | American Express Travel Related Services Company, Inc. | Systems and Methods for Control and Reconciliation of Virtual Token Accounts |
US20170353436A1 (en) * | 2016-06-03 | 2017-12-07 | Penny Jurss | Compromise alert and reissuance |
US20180018660A1 (en) * | 2016-07-15 | 2018-01-18 | Paypal, Inc. | Processing a transaction using electronic tokens |
US20180121917A1 (en) * | 2016-10-28 | 2018-05-03 | Thomas Purves | Token creation and provisioning |
US20180247306A1 (en) * | 2017-02-24 | 2018-08-30 | Passport Technology Inc. | Systems and methods for rule-based payment card management using tokens |
US20180268405A1 (en) * | 2017-03-17 | 2018-09-20 | Eduardo Lopez | Replacing token on a multi-token user device |
US20190066096A1 (en) * | 2017-08-25 | 2019-02-28 | Mastercard International Incorporated | Systems and methods for minimizing user interactions for cardholder authentication |
US20190087816A1 (en) * | 2017-09-20 | 2019-03-21 | Paypal, Inc. | Using a consumer digital wallet as a payment method in a merchant digital wallet |
US10762483B2 (en) * | 2014-03-04 | 2020-09-01 | Bank Of America Corporation | ATM token cash withdrawal |
US11308483B2 (en) * | 2015-08-25 | 2022-04-19 | Paypal, Inc. | Token service provider for electronic/mobile commerce transactions |
-
2019
- 2019-12-20 US US16/723,359 patent/US20200302442A1/en not_active Abandoned
Patent Citations (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070038525A1 (en) * | 2005-08-15 | 2007-02-15 | Waldvogel Richard T | Systems and Methods of Managing Retailer Affiliate Programs |
US20120255994A1 (en) * | 2006-12-07 | 2012-10-11 | Smart Systems Innovations, Llc | Mass transit fare processing system |
US9626674B1 (en) * | 2007-09-26 | 2017-04-18 | Gregory J. Wolff | System and method for exchanging, sharing and redeeming credits |
US20110213807A1 (en) * | 2010-03-01 | 2011-09-01 | Ulf Mattsson | System and method for distributed tokenization using several substitution steps |
US20120330846A1 (en) * | 2011-06-27 | 2012-12-27 | Accenture Global Services Limited | Dynamic electronic money |
US20140032419A1 (en) * | 2012-07-26 | 2014-01-30 | Lisa Anderson | Configurable payment tokens |
US20170249622A1 (en) * | 2012-10-17 | 2017-08-31 | Royal Bank Of Canada | Systems, methods, and devices for secure generation and processing of data sets representing pre-funded payments |
US20140143144A1 (en) * | 2012-11-20 | 2014-05-22 | Mastercard International Incorporated | Systems and methods for processing electronic payments using a global payment directory |
US20150095240A1 (en) * | 2013-09-30 | 2015-04-02 | Fiserv, Inc. | Card account identifiers associated with conditions for temporary use |
US20150106239A1 (en) * | 2013-10-11 | 2015-04-16 | Ajit Gaddam | Tokenization revocation list |
US20150112870A1 (en) * | 2013-10-18 | 2015-04-23 | Sekhar Nagasundaram | Contextual transaction token methods and systems |
US20150199873A1 (en) * | 2014-01-10 | 2015-07-16 | PayNearMe | Systems and methods for cash payments for online gaming |
US20150199679A1 (en) * | 2014-01-13 | 2015-07-16 | Karthikeyan Palanisamy | Multiple token provisioning |
US20150242853A1 (en) * | 2014-02-26 | 2015-08-27 | Mastercard International Incorporated | Payment account tokenization method |
US20150254699A1 (en) * | 2014-03-04 | 2015-09-10 | Bank Of America Corporation | Providing offers associated with payment credentials in digital wallets |
US10762483B2 (en) * | 2014-03-04 | 2020-09-01 | Bank Of America Corporation | ATM token cash withdrawal |
US20160224977A1 (en) * | 2015-01-30 | 2016-08-04 | Yaasha Sabba | Token check offline |
US20160239833A1 (en) * | 2015-02-17 | 2016-08-18 | Mastercard Asia/Pacific Pte. Ltd. | Methods and systems for processing an electronic payment |
US20160321652A1 (en) * | 2015-04-30 | 2016-11-03 | James Dimmick | Tokenization Capable Authentication Framework |
US11308483B2 (en) * | 2015-08-25 | 2022-04-19 | Paypal, Inc. | Token service provider for electronic/mobile commerce transactions |
US20170270521A1 (en) * | 2016-03-21 | 2017-09-21 | Mastercard International Incorporated | Systems and Methods for Use in Providing Payment Transaction Notifications |
US20170300895A1 (en) * | 2016-04-13 | 2017-10-19 | Mastercard International Incorporated | System and method for peer-to-peer assistance in provisioning payment tokens to mobile devices |
US20170316405A1 (en) * | 2016-05-02 | 2017-11-02 | American Express Travel Related Services Company, Inc. | Systems and Methods for Control and Reconciliation of Virtual Token Accounts |
US9734652B1 (en) * | 2016-05-16 | 2017-08-15 | Paypal, Inc. | Simulating I/O using multicomputer data processing |
US20170353436A1 (en) * | 2016-06-03 | 2017-12-07 | Penny Jurss | Compromise alert and reissuance |
US20180018660A1 (en) * | 2016-07-15 | 2018-01-18 | Paypal, Inc. | Processing a transaction using electronic tokens |
US20180121917A1 (en) * | 2016-10-28 | 2018-05-03 | Thomas Purves | Token creation and provisioning |
US20180247306A1 (en) * | 2017-02-24 | 2018-08-30 | Passport Technology Inc. | Systems and methods for rule-based payment card management using tokens |
US20180268405A1 (en) * | 2017-03-17 | 2018-09-20 | Eduardo Lopez | Replacing token on a multi-token user device |
US20190066096A1 (en) * | 2017-08-25 | 2019-02-28 | Mastercard International Incorporated | Systems and methods for minimizing user interactions for cardholder authentication |
US20190087816A1 (en) * | 2017-09-20 | 2019-03-21 | Paypal, Inc. | Using a consumer digital wallet as a payment method in a merchant digital wallet |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10915898B2 (en) | Demand deposit account payment system | |
US10412060B2 (en) | Token enrollment system and method | |
JP6420371B2 (en) | Payment token lifetime management method in mobile devices | |
US20170364910A1 (en) | System and method to push payment to beneficiary account using an alias | |
US20170372417A1 (en) | Digital asset account management | |
US11803823B2 (en) | Systems and methods for blockchain-based payment transactions, alerts, and dispute settlement, using a blockchain interface server | |
US20170091757A1 (en) | Tokenization provisioning and allocating system | |
US11847628B2 (en) | User interfaces for using shared databases for managing supplemental payment sources | |
US20220036347A1 (en) | Payment transaction process employing dynamic account expiry and dynamic token verification code | |
US20240029053A1 (en) | Provisioning of payment acceptance to payment account holders | |
US20160140557A1 (en) | E-commerce based payment system with authentication of electronic invoices | |
US20230013949A1 (en) | Interactive user interface systems and methods for analyzing transaction attributes and dispute information using blockchain | |
US20200302442A1 (en) | Systems and methods for tokenizing tokens in transactions | |
US20160210608A1 (en) | Merchant interface for transaction-related services | |
US20190164155A1 (en) | Systems and methods for tokenizing tokens in transactions | |
EP4421710A1 (en) | Payment instrument adaptable for multiple central bank digital currencies | |
US20190188747A1 (en) | Reward optimization through real time authorization processing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MASTERCARD INTERNATIONAL INCORPORATED, NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HOSP, ADAM KENNETH;REEL/FRAME:051347/0896 Effective date: 20171127 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |