US20190197552A1 - Payment account identifier system - Google Patents
Payment account identifier system Download PDFInfo
- Publication number
- US20190197552A1 US20190197552A1 US16/293,488 US201916293488A US2019197552A1 US 20190197552 A1 US20190197552 A1 US 20190197552A1 US 201916293488 A US201916293488 A US 201916293488A US 2019197552 A1 US2019197552 A1 US 2019197552A1
- Authority
- US
- United States
- Prior art keywords
- token
- payment
- transactable
- account identifier
- payment account
- 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
-
- 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
- G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
-
- 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/3674—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 involving authentication
Definitions
- PANs primary account numbers
- PANs While the use of PANs for such purposes has been useful, the use of PANs as accountholder identification mechanisms is problematic. If PANs are retained by merchants, for example, the merchants will need to be PCI (payment card industry) compliant. To be PCI compliant, merchants need to take a number of steps to improve the security of their data systems. Such steps can be resource and time intensive to implement and maintain.
- PCI payment card industry
- Tokens can be substitutes for real PANs.
- a token can be used in place of a real PAN in a payment transaction. If the token is stolen by an unauthorized user (e.g., a hacker), then a new token can be issued in place of the token that was stolen. In this situation, the underlying real PAN is protected and the consumer's basic account information need not be re-issued.
- each accountholder PAN can be mapped to multiple tokens ( 1 -N mapping). For example, if a PAN is used in multiple digital wallets, each wallet instance can have a different static token for the same cardholder PAN. In another example, a different token relating to a PAN can be issued for each transaction.
- Embodiments of the invention address these and other problems, individually and collectively.
- Embodiments of the invention can relate to systems and methods that can utilize payment tokens and non-transactable payment account identifiers.
- a non-transactable payment account identifier may have the same format as a PAN. Because of this, an entity's existing processing system (i.e., systems that process PANs) can utilize the non-transactable payment account identifier much like it would for a real PAN. However, unlike a PAN or a transactable payment token, the non-transactable payment account identifier cannot be used to conduct a payment transaction.
- non-transactable payment account identifiers can be stored and used by entities such as merchants, acquirers, and program operators to perform operations including loyalty processing, fraud processing, and reporting, even though tokens are used to conduct payment transactions. As such, such entities do not need to be PCI compliant.
- One embodiment of the invention is directed to a method.
- the method comprises receiving, by a token service computer, a token request comprising a primary account identifier from a token requestor computer, and then determining, by the token service computer, a transactable payment token and a non-transactable payment account identifier associated with the primary account identifier.
- the method also includes transmitting, by the token service computer, the transactable payment token and the non-transactable payment account identifier to the token requestor computer. If the token requestor computer is not a consumer's payment device, the token requestor computer may provide the transactable payment token and the non-transactable payment account identifier to the payment device.
- the transactable payment token and the non-transactable payment account identifier can then be passed from the consumer's payment device to an access device to conduct a transaction.
- the transactable payment token can be used by the access device to process a payment for the transaction instead of the primary account identifier, while the non-transactable payment account identifier can be used as a reference for the primary account identifier to perform an operation that is not a payment transaction.
- Another embodiment of the invention is directed to a token service computer configured to perform the above-described method.
- Another embodiment of the invention is directed to a method comprising receiving, by a token service system, a token request associated with account information and then determining a non-transactable payment account identifier and a payment token.
- the method also includes providing the non-transactable payment account identifier and a token associated with the account information, and then receiving an authorization request message including the token and the non-transactable payment account identifier from a merchant.
- the method also includes adding the account information to the authorization request message and sending the authorization request message to an issuer.
- the method further includes receiving an authorization response message including the account information from the issuer and replacing the account information with the transactable payment token and the non-transactable payment account identifier in the authorization response message.
- the method further includes sending the authorization response message to the merchant.
- Another embodiment of the invention is directed to a token service system configured to perform the above-described method.
- FIG. 1 shows a block diagram of a system according to an embodiment of the invention.
- FIG. 2 shows a flowchart illustrating a method according to an embodiment of the invention.
- FIG. 3 shows a block diagram of another system according to an embodiment of the invention.
- FIG. 4 shows a flow diagram illustrating methods that can be used with the system illustrated in FIG. 3 .
- FIG. 5 shows a block diagram of a computer apparatus according to an embodiment of the invention.
- Embodiments of the invention use a non-transactable payment account identifier to allow entities (e.g., merchant, acquirer, etc.) within a transaction eco-system to identify an accountholder when using tokens in lieu of traditional PANs.
- entity e.g., merchant, acquirer, etc.
- the non-transactable payment account identifier enables entities such as merchants and acquirers to identify accountholders when using transactable payment tokens for various applications.
- Such applications include, but are not limited to: fraud and risk checks on transaction authorization requests, fraud and risk reviews after transactions are completed, performance of value added services (e.g., loyalty, backend applications, reporting), and transaction feeds for third party value added applications.
- a “non-transactable payment account identifier” may be any string of characters that identify an accountholder and that is not used to conduct a payment transaction on an underlying account.
- a non-transactable payment account identifier may be 16-19 digits (or any other suitable length) and may be based on the format and rules of a PAN (primary account number).
- the non-transactable payment account identifier may be static over time and any number of transactions.
- a non-transactable account identifier may have a BIN (bank identification number) that is the same as the BIN for the corresponding real account identifier. Alternatively, it may have a BIN that is derived from or completely random with respect to the real BIN.
- the BIN in the non-transactable account identifier could also be a static tokenized BIN.
- the non-transactable payment account identifier may include one or more characters that may indicate that it cannot be used to conduct a payment transaction. For example, it could be that all non-transactable payment account identifiers may start with the characters “99.” Any data strings that are similar in length to a real PAN in any transaction request messages would be treated by any suitable payment processing computers as being non-transactable. In other embodiments, non-transactable payment account identifiers may not be readily identified as being non-transactable by an outside observer.
- a token service computer e.g., a token vault
- Payment account information may be any information that identifies or is associated with a payment account. Payment account information may be provided in order to make a payment from a payment account. Some examples of payment account information include one or more of a PAN (primary account number), a CVV (card verification value), a dCVV (dynamic card verification value), a user name, an expiration date, a gift card number or code, etc.
- PAN primary account number
- CVV card verification value
- dCVV dynamic card verification value
- user name an expiration date
- a gift card number or code etc.
- a “real account identifier” may include a transactable identifier associated with a payment account that directly represents the payment account.
- a real account identifier may be a primary account number (PAN) issued by an issuer for a card account (e.g., credit card, debit card, etc.).
- PAN primary account number
- a real account identifier may include a sixteen digit numerical value such as “4147 0900 0000 1234.” The first six digits of the real account identifier (e.g., “414709”), may represent a real issuer identifier (e.g., a “BIN” or bank identification number) that may identify an issuer associated with the real account identifier.
- Tokenization is a process by which data is replaced with substitute data.
- a payment account identifier e.g., a primary account number (PAN)
- PAN primary account number
- tokenization may be applied to any other-information which may be replaced with a substitute value (i.e., token). Tokenization may be used to enhance transaction efficiency, improve transaction security, increase service transparency, or to provide a method for third-party enablement.
- Token exchange or “de-tokenization” can include a process of restoring the data that was substituted during tokenization.
- a token exchange may include replacing a payment token with a corresponding primary account number (PAN) that was associated with the payment token during tokenization of the PAN.
- PAN primary account number
- the de-tokenization may refer to the process of redeeming a token for the associated PAN value based on a token-to-PAN mapping stored, for example, in a token vault.
- the ability to retrieve a PAN in exchange for the associated token may be restricted to specifically authorized entities, individuals, applications, or systems.
- de-tokenization or token exchange may be applied to any other information.
- token exchange may be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request).
- API application programming interface
- a “transactable payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN).
- PAN primary account number
- a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier.
- a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.”
- a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing payment processing networks (e.g., ISO 8583 financial transaction message format).
- a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided.
- a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived.
- the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.
- a “Bank Identification Number (BIN)” may be a number that identifies a bank.
- a BIN may be assigned by a payment network to an issuer of a payment account.
- BINs may be consistent with industry account and issuer identification specifications (e.g. ISO 7812) such that the payment network assigning the BIN may be identified based on the BIN and associated account ranges.
- a “token BIN” may refer to a specific BIN that has been designated only for the purpose of issuing tokens and may be flagged accordingly in BIN tables. Token BINs may not have a dual purpose and may not be used to issue both primary account numbers (PANs) and tokens.
- PANs primary account numbers
- a “token issuer identifier range (issuer BIN range)” may refer to a unique identifier (e.g., of 6 to 12 digits length) originating from a set of pre-allocated token issuer identifiers (e.g., 6 digit token BINs).
- one or more token BIN ranges can be allocated to each issuer BIN range that is associated with an issuer.
- the token BIN ranges may be used to generate a payment token and may not be used to generate a non-payment token.
- a token may pass the basic validation rules of an account number including, for example, a LUHN check or checksum validation that may be set up by different entities within the payment system.
- a payment token issuer identifier may be mapped to a real issuer identifier (e.g., a BIN) for an issuer.
- a payment token issuer identifier may include a six digit numerical value that may be associated with an issuer.
- any token including the payment token issuer identifier may be associated with a particular issuer.
- the issuer may be identified using the corresponding issuer identifier range associated with the token issuer identifier.
- a payment token issuer identifier “490000” corresponding to a payment token “4900 0000 0000 0001” can be mapped to an issuer identifier “414709” corresponding to a payment account identifier “4147 0900 0000 1234”.
- a payment token issuer identifier is static for an issuer.
- a payment token issuer identifier e.g., “490000”
- another payment token issuer identifier e.g., “520000”
- the first and second payment token issuer identifiers may not be changed or altered without informing all entities within the network token processing system.
- a payment token issuer identifier range may correspond to an issuer identifier.
- Token BIN Ranges and assignment of tokens from these BIN ranges may be made available to the parties (e.g., via routing tables) accepting the transaction to make routing decisions.
- a “token service system” can include a system that that services payment tokens.
- a token service system can facilitate requesting, determining (e.g., generating) and/or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g. token vault).
- PANs primary account numbers
- the token service system may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding.
- the token service system may support token processing of payment transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN.
- a token service system may include a token service computer alone, or in combination with other computers such as a payment processing network computer.
- a “token service provider” may include an entity that services payment tokens.
- the token service provider may operate one or more server computers in a token service system that generate, process and maintain tokens.
- the token service provider may include or be in communication with a token vault where the generated tokens are stored.
- the token vault may maintain one-to-one mapping between a token and a primary account number (PAN) represented by the token.
- PAN primary account number
- the token service provider may have the ability to set aside licensed BINs as token BINs to issue tokens for the PANs that may be submitted to the token service provider.
- Various entities of a tokenization ecosystem may assume the roles of the token service provider.
- a token service provider may provide reports or data output to reporting tools regarding approved, pending, or declined token requests, including any assigned token requestor IDs.
- the token service provider may provide data output related to token-based transactions to reporting tools and applications and present the token and/or PAN as appropriate in the reporting output.
- a “token vault” may be an example of a token service computer and can include a repository that maintains established token-to-PAN mappings. According to various embodiments, the token vault may also maintain other attributes of the token requestor that may be determined at the time of registration. The attributes may be used by the token service provider to apply domain restrictions or other controls during transaction processing. In some embodiments, the token vault may be a part of the token service system or the token service provider. Alternatively, the token vault may be a remote repository accessible to the token service provider. Token vaults, due to the sensitive nature of the data mappings that are stored and managed in them, may be protected by strong underlying physical and logical security.
- ID&V identification and verification
- Examples of ID&V methods may include, but are not limited to, an account verification message, a risk score based on assessment of the primary account number (PAN) and use of one time password by the issuer or its agent to verify the account holder.
- Exemplary ID&V methods may be performed using information such as a user signature, a password, an offline or online personal identification number (PIN), an offline or online enciphered PIN, a combination of offline PIN and signature, a combination of offline enciphered PIN and signature, user biometrics (e.g.
- a confidence level may be established with respect to the token to PAN binding.
- a “token assurance level” may include an indicator or a value that allows the token service provider to indicate the confidence level of the token to PAN binding.
- the token assurance level may be determined by the token service provider based on the type of identification and verification (ID&V) performed and the entity that performed the ID&V.
- the token assurance level may be set when issuing the token.
- the token assurance level may be updated if additional ID&V is performed.
- a “requested token assurance level” may include a token assurance level requested by the token requestor.
- the requested token assurance level may be included in a field of a token request message sent by the requestor to the token service provider for the generation/issuance of the token.
- An “assigned token assurance level” may include an actual (i.e. generated) value assigned by the token service provider to the token as the result of the identification and verification (ID&V) process performed by an entity within the tokenization ecosystem.
- the assigned token assurance level may be provided back to the token requestor in response to the token request message.
- the assigned token assurance level may be different than the requested token assurance level included in the token request message.
- token attributes may include any feature or information about a token.
- token attributes may include information that can determine how a token can be used, delivered, issued, or otherwise how data may be manipulated within a transaction system.
- the token attributes may include a type of token, frequency of use, token expiry date and/or expiry time, a number of associated tokens, a transaction lifecycle expiry date, and any additional information that may be relevant to any entity within a tokenization ecosystem.
- token attributes may include a wallet identifier associated with the token, an additional account alias or other user account identifier (e.g., an email address, username, etc.), a device identifier, an invoice number, etc.
- a token requestor may provide token attributes at the time of requesting the generation of tokens.
- a network token system, payment network associated with the network token system, an issuer, or any other entity associated with the token may determine and/or provide the token attributes associated with a particular token.
- a “token presentment mode” may indicate a method through which a token is submitted for a transaction.
- Some non-limiting examples of the token presentment mode may include machine readable codes (e.g., quick response code (QRC), barcode, etc.), mobile contactless modes (e.g., near-field communication (NFC) communication), e-commerce remote modes, e-commerce proximity modes, and any other suitable modes in which to submit a token.
- Tokens may be provided through any number of different methods.
- a token may be embedded in machine-readable code which may be generated by a wallet provider, mobile application, or other application on mobile device and displayed on a display of the mobile device. The machine readable code can be scanned at the POS through which the token is passed to the merchant.
- a mobile contactless mode may include passing the token through NFC in a contactless message.
- An e-commerce remote mode may include submitting a token by a consumer or a wallet provider through an online transaction or as an e-commerce transaction using a merchant application or other mobile application.
- An e-commerce proximity mode may include submitting a token by a consumer from a wallet application on a mobile device at a merchant location.
- a “token requestor” include an entity that requests a token.
- the token requestor may initiate a request that a primary account number (PAN) be tokenized by submitting a token request message to the token service provider.
- PAN primary account number
- a token requestor may no longer need to store a PAN associated with a token once the requestor has received a requested token.
- the requestor may be an application, a device, a process, or a system that is configured to perform actions associated with tokens.
- a token requestor can request registration with a network token system, request token generation, token activation, token de-activation, token exchange, token lifecycle management related processes, and/or any other token related processes.
- a requestor may interface with a network token system through any suitable communication networks and/or protocols (e.g., using HTTPS, SOAP and/or an XML interface among others).
- token requestors may include, for example, communication devices (e.g., mobile phones and computers) operated by consumers, card-on-file merchants, acquirers, acquirer processors, and payment gateways acting on behalf of merchants, payment enablers (e.g., original equipment manufacturers, mobile network operators, etc.), digital wallet providers, issuers, third party wallet providers, and/or payment processing networks.
- a token requestor can request tokens for multiple domains and/or channels.
- a token requestor may be registered and identified uniquely by the token service provider within the tokenization ecosystem.
- the token service provider may formally process the token requestor's application to participate in the token service system.
- the token service provider may collect information pertaining to the nature of the requestor and the relevant use of tokens to validate and formally approve the token requestor and establish appropriate domain restriction controls.
- Successfully registered token requestors may be assigned a token requestor identifier that may also be entered and maintained within the token vault.
- Token requestors be revoked or assigned new token requestor identifiers. This information may be subject to reporting and audit by the token service provider.
- a “token requestor identifier (ID)” may include an identifier for a token requestor. It may include any characters, numerals, or other identifiers associated with an entity associated with a network token system. In some embodiments, a unique token requestor ID may be assigned for each domain for a token request associated with the same token requestor. For example, a token requestor ID can identify a pairing of a token requestor (e.g., a mobile device, a mobile wallet provider, etc.) with a token domain (e.g., e-commerce, contactless, etc.). A token requestor ID may include any format or type of information.
- a token requestor e.g., a mobile device, a mobile wallet provider, etc.
- a token requestor ID may include any format or type of information.
- the token requestor ID may include an alphanumerical value such as a ten digit or an eleven digit letter and/or number (e.g., 4678012345).
- a token requestor ID may include a code for a token service provider (e.g., first 3 digits) such as the network token system and the remaining digits may be assigned by the token service provider for each requesting entity (e.g., mobile wallet provider) and the token domain (e.g., contactless, e-commerce, etc.).
- a “token request indicator” may refer to an indicator used to indicate that a message is related to a token request.
- the token request indicator may optionally be passed to the issuer as part of the Identification and Verification (ID&V) method to inform the issuer of the reason the account status check is being performed.
- ID&V Identification and Verification
- a “token domain” may indicate the factors that can be established at the time of token issuance to enable appropriate usage of the token for payment transactions.
- Examples of the token domain may include, but are not limited to, a POS entry mode, and merchant identifiers to uniquely identify where the token can be used.
- a set of parameters i.e. token domain restriction controls
- the token domain restriction controls may restrict the use of the token with particular presentment modes, such as contactless or e-commerce presentment modes.
- the token domain restriction controls may restrict the use of the token at a particular merchant that can be uniquely identified.
- Some exemplary token domain restriction controls may require the verification of the presence of a token cryptogram that is unique to a given transaction.
- Token expiry date may refer to the expiration date/time of the token.
- the token expiry date may be passed among the entities of the tokenization ecosystem during transaction processing to ensure interoperability.
- the token expiration date may be a numeric value (e.g. a 4-digit numeric value).
- a “consumer” may include an individual or a user that may be associated with one or more personal accounts and/or consumer devices.
- the consumer may also be referred to as a cardholder, account holder, or user.
- An “access device” may be any suitable device for communicating with a merchant computer or payment processing network, and for interacting with a payment device, a user computer apparatus, and/or a user mobile device.
- An access device may generally be located in any suitable location, such as at the location of a merchant.
- An access device may be in any suitable form.
- Some examples of access devices include POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, Websites on remote server computers, and the like.
- An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a payment device and/or a user mobile device.
- the access device may be a POS terminal.
- a POS terminal may include a payment device reader, a processor, and a computer-readable medium.
- the reader may utilize any suitable contact or contactless mode of operation.
- exemplary card readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers.
- RF radio frequency
- An “authorization request message” may be an electronic message that is sent to a payment processing network and/or an issuer of a payment card to request authorization for a transaction.
- An authorization request message may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or payment account.
- the authorization request message may include an issuer account identifier that may be associated with a payment device or payment account.
- An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or “account number”), a user name, an expiration date, etc.
- An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction.
- An “authorization response message” may be an electronic message reply to an authorization request message generated by an issuing financial institution or a payment processing network.
- the authorization response message may include, by way of example only, one or more of the following status indicators: Approval—transaction was approved; Decline—transaction was not approved; or Call Center—response pending more information, merchant must call the toll-free authorization phone number.
- the authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the payment processing network) to the merchant's access device (e.g. POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization.
- a payment processing network may generate or forward the authorization response message to the merchant.
- a “server computer” may include a powerful computer or cluster of computers.
- the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit.
- the server computer may be a database server coupled to a Web server.
- the server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers.
- the server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.
- An “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user that is associated with a portable communication device such as an account enrolled in a mobile application installed on a portable communication device.
- a business entity e.g., a bank
- a portable communication device such as an account enrolled in a mobile application installed on a portable communication device.
- a “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.
- An “acquirer” may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers.
- FIG. 1 shows a system 100 comprising a number of components.
- the system 100 comprises a token vault 110 , which may be an example of at least part of a token service provider computer.
- the token vault 110 may be in communication with one or more of a token requestor 115 , a merchant 130 , an acquirer 135 , a payment processing network 140 , and an issuer 150 .
- Each of the token requestor 115 , the merchant 130 , the acquirer 135 , the payment processing network 140 , and the issuer 150 may be embodied by one or more computers.
- the consumer 120 i.e., a device operated by the consumer 120
- the consumer 120 may be in communication with the token requestor 115 , the issuer 150 , and the merchant 130 .
- the merchant 130 , the acquirer 135 , the payment processing network 140 , the issuer 150 , and a token network 145 may all be in operative communication with each other through any suitable communication channel or communications network.
- a suitable communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like.
- WAP Wireless Application Protocol
- I-mode I-mode
- the token vault 110 may be associated with the payment processing network 140 , the issuer 150 , the acquirer 135 , or the merchant 130 .
- the token vault 110 can receive a token request from the token requestor 115 , the request including information (e.g., a PAN) that identifies a payment account.
- the token vault 110 can issue a token that can be used as surrogate payment account information.
- a record of the token may be stored at the token vault 110 , and the record may include the token, token expiration date, associated payment account information, token assurance information, token requestor information, and/or any other suitable information.
- the token vault 110 may also generate a unique non-transactable payment account identifier that may be a static non-payment identifier.
- the token vault 110 may associate the non-transactable payment account identifier with a PAN, so that the non-transactable payment account identifier is associated with a payment account.
- the token vault 110 may provide a non-transactable payment account identifier to the token requestor 115 in response to a token request.
- the token vault 110 can provide both payment information (via a token) and identification (via a non-transactable payment account identifier) without providing the actual PAN associated with the payment account.
- the non-transactable payment account identifier may first be generated and associated with the payment account the first time a token is requested for the payment account. The non-transactable payment account identifier may be identified and provided along with tokens in response to any future token requests.
- the token vault 110 may also be capable of de-tokenizing a token and providing payment account information in response to receiving the token.
- the token vault 110 may receive requests for payment account information from the payment processing network 140 , issuer 150 , acquirer 135 , and/or merchant 130 .
- the token vault 110 may receive a de-tokenization request including a token, identify payment account information that is associated with the token, and provide the payment account information to the de-tokenization requestor.
- the token vault 110 may be an example of a token service computer.
- the token service computer may comprise a processor and a computer readable medium.
- the computer readable medium comprising code, executable by the processor, for implementing a method.
- the method comprises receiving a token request comprising a primary account identifier from a token requestor computer, determining a transactable payment token and a non-transactable payment account identifier associated with the primary account identifier, and transmitting the transactable payment token and the non-transactable payment account identifier to the token requestor computer. If the token requestor computer is not a payment device, the token requestor computer passes the transactable payment token and the non-transactable payment account identifier to the payment device.
- the transactable payment token and the non-transactable payment account identifier are both passed from the consumer's payment device to an access device to conduct a transaction.
- the transactable payment token is used by the access device to process a payment for the transaction instead of the primary account identifier.
- the non-transactable payment account identifier is used as a reference for the primary account identifier to perform an operation that is not a payment transaction.
- the de-tokenization requestor may be the payment processing network 140 , which may request the payment account information for authorization purposes. In some embodiments, the de-tokenization requestor may be the merchant 130 which may wish to have the payment account information for consumer 120 identification purposes.
- the token requestor 115 may request a token on behalf of the consumer 120 .
- the token requestor 115 may be a digital wallet provider, a merchant 130 , payment processing network 140 , a payment device (e.g., the consumer's mobile phone), or any other suitable entity.
- the consumer 120 may wish to purchase a good and/or service from the merchant 130 and the token requestor 115 may retrieve a token from the token vault 110 for the consumer 120 to use for the purchase.
- the merchant 130 is capable providing goods and/or services to the consumer 120 .
- the merchant 130 may receive payment information comprising a token and a non-transactable payment account identifier from the consumer 120 (i.e., a payment device operated by the consumer 120 ) in a payment transaction.
- the merchant 130 may send the token and the non-transactable payment account identifier to the acquirer 135 for payment authorization.
- the merchant 130 may use the non-transactable payment account identifier for tracking consumer activity.
- the non-transactable payment account identifier may be static, so that the same non-transactable payment account identifier is provided each time a consumer 120 uses a certain payment account at a merchant 130 , even if the token is variable.
- one payment account may be associated with several digital wallets, and each digital wallet may have a different token associated with the same payment account.
- the merchant 130 may receive the same non-transactable payment account identifier whenever any of these different tokens are received.
- the merchant 130 may be able to recognize a payment account by a received non-transactable payment account identifier.
- the merchant 130 (or other party) to request that the consumer that is associated with the non-transactable account identifier provide additional information about the consumer (e.g., name, home address, telephone number, zip code, etc.) so that the merchant 130 has additional information to link the consumer to the non-transactable account identifier.
- additional information about the consumer e.g., name, home address, telephone number, zip code, etc.
- the merchant 130 may use the non-transactable payment account identifier as a consumer identifier instead of a PAN.
- the merchant 130 may keep a record of consumer 120 trends by recording transactions that involve the non-transactable payment account identifier.
- the non-transactable payment account identifier may comprise 16, 18, or 19 digits and can be formatted as a PAN so that merchants 130 can easily integrate a non-transactable payment account identifier into an existing consumer-tracking system that typically uses a PAN for consumer tracking.
- the non-transactable payment account identifier may replace a PAN for any suitable identification purpose.
- a consumer 120 may have more than one payment account, and thus the consumer 120 may be associated with multiple non-transactable payment account identifiers.
- a non-transactable payment account identifier may also be formatted to indicate an issuer 150 and/or a token vault 110 .
- the merchant 130 may use the non-transactable payment account identifier and associated consumer purchase record for other applications including value added services such as loyalty programs, backend applications, and reporting.
- the non-transactable payment account identifier may function as a consumer 120 loyalty identifier for tracking loyalty points and providing rewards or special offers.
- the merchant 130 may also use the non-transactable payment account identifier for fraud/risk checks during authorization. For example, the merchant 130 may be able to detect high-velocity transactions. If too many transactions (associated with the same payment token or multiple payment tokens corresponding to an underlying real account identifier) associated with the non-transactable payment account identifier occur within a certain amount of time, the merchant 130 may suspect fraudulent activity. The merchant may then reject further transactions involving the non-transactable payment account identifier.
- the merchant 130 may mark the non-transactable payment account identifier as high-risk or put the non-transactable payment account identifier on a “blacklist.” The merchant 130 may also use the non-transactable payment account identifier to review fraud/risk levels after a transaction is authorized.
- the merchant 130 may use the non-transactable payment account identifier to access past transactions. For example, the merchant 130 may use the non-transactable payment account identifier to identify a past transaction for a refund or an inquiry.
- the non-transactable payment account identifier may also be used for providing a transaction feed to third party value added applications.
- the merchant 130 may inform third party applications about consumer 120 purchases and trends that are tracked via the non-transactable payment account identifier.
- a third-party may use a transaction feed for providing rewards or offers to the consumer in real time or offline (e.g. in a statement of credit).
- the acquirer 135 may be associated with the merchant 130 , and may manage authorization requests on behalf of the merchant 130 .
- the acquirer 135 may receive an authorization request message including the token and non-transactable payment account identifier from the merchant 130 and send the authorization request message to a payment processing network 140 .
- the payment processing network 140 may be associated with the token and may be identified by one or more fields within the token.
- the acquirer 135 may use the non-transactable payment account identifier for online fraud analysis, offline fraud analysis, loyalty services, third party loyalty programs, reporting to merchants, or any other suitable purpose. For example, in some embodiments, the acquirer 135 may flag a payment account (identified by a non-transactable payment account identifier) and an associated merchant 130 for fraud/risk level scoring. In another example, a non-transactable payment account identifier may be used for providing card-linked offers. In another example, the acquirer 135 may provide a consumer transaction report to merchants, the report including transactions that involved a certain non-transactable payment account identifier.
- the merchant 130 and/or the acquirer 135 may be able to provide a non-transactable payment account identifier to the token vault 110 and then receive associated payment account information. Additionally, in some embodiments, the merchant 130 and/or the acquirer 135 may provide payment account information to the token vault 110 , and then receive an associated non-transactable payment account identifier. For example, a merchant 130 may send a “Get PAN” request that includes the non-transactable payment account identifier to the token vault 110 , and the token vault 110 may respond with the PAN information.
- the merchant 130 may send a “Get non-transactable payment account identifier” request including the PAN and/or the transactable payment token to the token vault 110 , and receive a non-transactable payment account identifier associated with the PAN.
- the acquirer 135 , the payment processing network 140 , and the issuer 150 may operate suitable routing tables to route authorization request messages using real account identifiers such as PANs or tokens. Token routing data may be provided or maintained by the token vault 110 , and may be communicated to any of the entities in FIG. 1 .
- the payment processing network 140 may be disposed between the acquirer 135 and the issuer 150 .
- the payment processing network 140 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services.
- the payment processing network 140 may comprise a server computer, coupled to a network interface (e.g. by an external communication interface), and a database(s) of information.
- An exemplary payment processing network may include VisaNetTM.
- Payment processing networks such as VisaNetTM are able to process credit card transactions, debit card transactions, and other types of commercial transactions.
- VisaNetTM in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services.
- the payment processing network 140 may use any suitable wired or wireless network, including the Internet.
- the payment processing network 140 may be able to de-tokenize any tokens in any authorization request message that is received.
- the payment processing network 140 may receive an authorization request message including a token and non-transactable payment account identifier, send the token and non-transactable payment account identifier to the token vault 110 , receive associated payment account information from the token vault 110 , and forward the authorization request message to the issuer 150 with the payment account information.
- the payment processing network 140 may also receive an authorization response message with the payment account information, and replace some or all of the payment account information with the token and/or non-transactable payment account identifier before forwarding the message to the acquirer 135 .
- the token vault 110 and the payment processing network 140 may form a token service system.
- the token service system comprises a token service computer comprising a first processor and a first computer readable medium, the first computer readable medium comprising code, executable by the first processor to implement a method.
- the method includes receiving a token request associated with account information, determining a non-transactable payment account identifier and a transactable payment token associated with the account information, and providing the non-transactable payment account identifier and the transactable payment token associated with the account information.
- the method also includes a payment processing network computer in communication with the token service computer.
- the payment processing network computer comprises a second processor and a second computer readable medium, the second computer readable medium comprising code, executable by the second processor for implementing a method.
- the method comprises receiving an authorization request message including the transactable payment token and the non-transactable payment account identifier from a merchant, adding the account information to the authorization request message, sending the authorization request message to an issuer, receiving an authorization response message including the account information from the issuer, replacing the account information with the transactable payment token and the non-transactable payment account identifier in the authorization response message, and sending the authorization response message to the merchant.
- the token network 145 may also be able to provide de-tokenization services.
- the token network 145 may include another payment processing network, another token vault, and/or another token requestor.
- the consumer 120 may receive a token that is associated with a payment processing network of the token network 145 .
- the payment processing network 140 may send the token and non-transactable payment account identifier to the token network 145 , which may then return the payment account information.
- the token network 145 may wish to de-tokenize a token that is associated with the payment processing network 140 , and may obtain associated payment account information by similarly communicating with the payment processing network 140 and token vault 110 .
- a method 200 according to embodiments of the invention can be described with respect to FIG. 2 .
- the steps shown in the method 200 may be performed sequentially or in any suitable order in embodiments of the invention.
- the consumer 120 may purchase a good or service at a merchant 130 .
- the merchant 130 may then request that the consumer 120 provide payment information to conduct the purchase.
- the consumer 120 can use a token to conduct the payment transaction.
- the consumer 120 may cause the token requestor 115 to request a token to conduct the transaction.
- the token requestor 115 may be the consumer's mobile phone or may be a digital wallet that is associated with the consumer's mobile phone.
- the token requestor 115 may then send a token request to the token vault 110 on behalf of the consumer 120 .
- a token request may be in an electronic message format, such as an e-mail, a short messaging service (SMS) message, a multimedia messaging service (MMS) message, a hypertext transfer protocol (HTTP) request message, a transmission control protocol (TCP) packet, a web form submission.
- the token request may be directed to any suitable location, such as an e-mail address, a telephone number, an internet protocol (IP) address, or a uniform resource locator (URL).
- a token request may comprise a mix of different message types, such as both email and SMS messages.
- the token request may include any suitable type of information.
- the token request may include an account identifier (e.g., a PAN) associated with an account that is to be used to pay for the good or service, a token requestor ID, or any other suitable information.
- the token vault 110 may receive the token request from the token requestor 115 .
- the token request may include information about the payment account for which a token is desired.
- the token vault 110 may determine (e.g., generate or identify) a non-transactable payment account identifier and associate the non-transactable payment account identifier with the payment account information of the consumer 120 .
- the token vault 110 may store a record of the non-transactable payment account identifier and associated payment account information in a database if desired.
- the non-transactable payment account identifier may be determined in any suitable manner.
- the non-transactable payment account identifier may be generated using an algorithm that converts a real PAN into the non-transactable payment account identifier.
- the algorithm may be an encryption algorithm such as DES, triple DES, etc.
- a listing of non-transactable payment account identifiers may be generated in advance and a non-transactable payment account identifier could be assigned to each received token request.
- the token vault 110 may then determine (e.g., identify or generate) a token that represents or is associated with the indicated payment account information.
- the token vault 110 may maintain a record including the account information, the token associated with the account information, the non-transactable payment account identifier associated with the account information, a token expiration date, a token assurance level, and/or any other suitable information in a database.
- the token may be determined in any suitable manner.
- the non-transactable payment account identifier may be generated using an algorithm that converts a real PAN into the token.
- a listing of tokens may be generated in advance and a token could be assigned to each received token request.
- the token vault 110 may then transmit the token and the non-transactable payment account identifier to the token requestor 115 in a token response message.
- the token and the non-transactable token may be transmitted to the token requestor 115 in multiple messages.
- the token response message may have the same or different form or format as the previously described token request message. It may also have additional information that was not present in the token request message. For example, the token response message may include other information such as the time period in which the token would be valid.
- the token requestor 115 may provide the information to the consumer 120 (i.e., a payment device operated by the consumer 120 ), which may then provide the token and non-transactable payment account identifier to the merchant 130 . Or, the token requestor 115 may provide the information to the merchant 130 . Any suitable mode of communication may be used to provide the information to the merchant 130 .
- the token is provided as payment information and the non-transactable payment account identifier is provided as extended token data or additional VAS data.
- the token requestor 115 or consumer 120 may generate a QR code that may include the token and the non-transactable payment account identifier in a transaction payload.
- the consumer 120 may provide the QR code to the merchant 130 via an access device.
- Any other suitable communication mechanism e.g., a contactless mechanism
- the merchant 130 may then use the non-transactable payment account identifier to identify a purchase record of the consumer 120 and may update the record with the current transaction.
- the merchant 130 may use the non-transactable payment account identifier-identified consumer 120 record for various applications including online fraud analysis, offline fraud analysis, value added services (e.g. loyalty, backend applications, reporting), third-party transaction feeds, or any other suitable purposes.
- the merchant 130 may forward the token, the non-transactable payment account identifier, and other information to the acquirer 135 in an authorization request message.
- the token may be in the data field in the authorization request message normally reserved for the PAN, while the non-transactable payment account identifier may be placed in a supplemental or discretionary data field such as Field 55 . If desired, the data in the supplemental discretionary data field may follow a tag-length-value data format.
- the acquirer 135 may send the authorization request message to the payment processing network 140 .
- the acquirer 135 may also use the non-transactable payment account identifier for identifying the consumer 120 , online fraud analysis, offline fraud analysis, loyalty services, third party loyalty programs, value added services (e.g. loyalty, backend applications), third-party transaction feeds, reporting to merchants, or any other suitable purposes.
- the payment processing network 140 may receive the authorization request message. After the payment processing network 140 receives the authorization request message, it extracts the token from the authorization request message and then de-tokenizes it. In some embodiments, it can do this by requesting the payment account information from the token vault 110 . In some embodiments, if the token is associated with another payment processing network that is a part of a different token network 145 , the payment processing network 140 may request the payment account information from the token network 145 .
- the token vault 110 may receive the token and/or non-transactable payment account identifier from the payment processing network 140 .
- the token vault 110 may identify the associated payment account information in the token record, and send the payment account information to the payment processing network 140 .
- the payment processing network 140 may replace the token in the authorization request message with the payment account information. For example, if the account information includes a PAN, then the token is removed from the PAN data field in the authorization request message. The PAN is then added back into the authorization request message. The non-transactable payment account identifier may remain in a supplemental data field. Once this is done, the payment processing network 140 may forward the authorization request message to the issuer 150 .
- the issuer 150 may analyze it and may determine whether or not to authorize the transaction. The issuer 150 may determine if the account associated with the authorization request message has sufficient funds or credit. It may also determine that the transaction is not inherently risky. If the transaction is authorized by the issuer 150 , the issuer 150 may send an authorization response including the payment account information and an approval code to the payment processing network 140 .
- step S 280 the payment processing network 140 receives the authorization response message including the payment account information from the issuer 150 .
- the payment processing network 140 may then query the token vault 110 for information associated with the payment account information, such as the token and non-transactable payment account identifier.
- the token vault 110 may identify the requested information in the token record and provide it to the payment processing network 140 .
- the payment processing network 140 may add the token, non-transactable payment account identifier, or any other suitable transaction information into the authorization response message, and may remove some or all of the payment account information from the message. For example, in some embodiments, the last four digits of a PAN may remain in the message, even though the real PAN is removed and is replaced with the token.
- the non-transactable payment account identifier may remain in a supplemental data field.
- step S 295 the payment processing network 140 may then forward the message to the acquirer 135 .
- the acquirer 135 may forward the message to the merchant 130 , which may inform the consumer 120 of the authorization results.
- the merchant 130 may update the non-transactable payment account identifier-identified consumer 120 transaction record with the authorization results.
- a clearing and settlement process between the issuer 150 , the payment processing network 140 , and the acquirer 135 may occur.
- account information and token exchanges that are similar to those in the above-described authorization processing steps can occur.
- Subsequent transactions using different transactable payment tokens using the same payment device may use the same non-transactable payment account identifier.
- each of those entities may retrieve, store, analyze, and process the transaction data associated with the non-transactable payment account identifier. This is the case, even though different payment tokens are used for different transactions conducted with the same underlying account or payment device.
- FIG. 3 shows a block diagram of another embodiment of the invention.
- FIG. 3 shows a diagram of a more detailed system that can incorporate a non-transactable payment account identifier.
- FIG. 3 shows a payment device 302 and a POS terminal 306 (which is an example of an access device) which may be located at a merchant.
- the POS terminal 306 may communicate with an acquirer computer 310 , a payment processing network 312 , and an issuer computer 314 .
- the payment device 302 may be in communication with a wallet server computer 316 , which may comprise a value added services module (which may include VAS data) 316 A and a payment module 316 B.
- the wallet server computer 316 may communicate with an external value added services computer 318 as well as a cloud based payments platform 320 and a tokenization service computer 322 .
- the tokenization service computer 322 may communicate with the payment processing network 312 .
- the payment device 302 may comprise a data transmit application 302 A and a mobile wallet application 302 B. For clarity of illustration, some of the hardware and software elements in the payment device 302 are not shown in FIG. 3 .
- the payment device 302 may additionally include a data processor, and a communication interface (e.g., a contactless interface), a memory, a computer readable medium, input devices (e.g., input keys, a microphone, etc.), output devices (e.g., a touchscreen, speaker, etc.), and an antenna (e.g., for long range communication).
- the payment device 302 may be in the form of a payment card, a key fob, a mobile phone, a tablet computer, a wearable device, etc.
- the POS terminal 306 may comprise a data receive application 306 A, a payment API (application program interface) 306 B, a POS shopping application 306 C, and a local value added services (VAS) application 306 D.
- the POS terminal 306 may additionally include a data processor, and a communication interface (e.g., a contactless interface, a data reader such as a card reader), a memory, a computer readable medium, input devices (e.g., input keys, a microphone, etc.), output devices (e.g., a touchscreen, speaker, etc.), and an antenna (e.g., for long range communication).
- a communication interface e.g., a contactless interface, a data reader such as a card reader
- input devices e.g., input keys, a microphone, etc.
- output devices e.g., a touchscreen, speaker, etc.
- an antenna e.g., for long range communication
- the wallet server 316 may comprise a data processor, a memory and a computer readable medium.
- the VAS module 316 A and the payment module 316 B may reside in the memory and/or the computer readable medium.
- the wallet server 316 may store payment account data (e.g., transactable payment tokens) that may be used by the payment device 302 to conduct purchase transactions.
- the external value added services computer 318 may be operated by an entity that is different than the other entities shown in FIG. 3 . It may provide value added data (described above and below) to the wallet server 316 and the payment device 302 .
- the cloud based payments platform 320 may include a gateway that supplies transactable payment tokens, non-transactable payment account identifiers and other information directly or indirectly to the payment device 302 .
- the tokenization service computer 322 can perform tokenization services and can include the above described token vault.
- FIG. 4 shows a flow diagram illustrating methods that can be used with the system illustrated in FIG. 3 .
- methods illustrating the use of the non-transactable account identifier with value added services data can be described with reference to FIGS. 3 and 4 .
- non-payment data can be provided by merchant or third party applications, which may be used primarily by a merchant POS terminal (and optionally by an acquirer) to provide value added services to consumers.
- Merchants prefer to have non-payment information (e.g., loyalty IDs, coupon IDs, order numbers, etc.) with payment credentials to provide value added services.
- Merchants currently get this information in different forms (e.g., manually, cards, multiple apps, etc.) through multiple consumer interactions. This mode of providing such non-payment information is inconvenient for consumers.
- embodiments of the invention can combine non-payment data from one or more data sources with payment data in a single data element, which may be transmitted from a payment device to a POS terminal.
- a wallet application 302 B in a payment device 302 may send a token request to a tokenization service computer 322 .
- the token request may include an account identifier such as a PAN or some other identifier related to the account. Further details on token requests are provided above.
- step S 402 after the token request is received by the tokenization service computer 322 , the tokenization service computer 322 performs any desired fraud or status checks on the token request. If the checks indicate that a token can be issued, the tokenization service computer 322 can transmit a token to the wallet application 302 B in the payment device 302 . In addition to the token, the tokenization service computer 322 may transmit other information including one or more of a token expiration date, a token requestor ID, a digital wallet ID, and a non-transactable payment account identifier to the wallet application 302 B on the payment device 302 . The token and the other information may be transmitted to the wallet application 302 B in the payment device 302 in a single communication or in multiple communications.
- one or more value added service data sources 316 A, 318 may directly or indirectly transmit value added service data to the wallet application 302 B on the payment device 302 .
- the data sources may include value added services data 316 A from the wallet server 316 or value added data from the external value added services computer 318 .
- value added services data may include one or more of a loyalty identifier (e.g., a frequent flier account number) held by the consumer, a coupon identifier, and an order number for a past or current purchase.
- the wallet application 302 B passes the data from the token service computer 322 and the value added service data source(s) 316 , 318 to the data transmit application 302 A in the payment device 302 A.
- the data transmit application 302 A operating in conjunction with a data processor on the payment device 302 A generates a transaction payload and it may be in the form of a data element such as a QR code. Other data elements such as a cryptogram may be generated by the payment device 302 A and may be included in the transaction payload.
- the value added services data may be in any suitable form, and may include any suitable type of data. It may include strings of characters, image files, videos, etc. Each piece of value added data may have a tag value associated with it. The tag may be defined by the entity (e.g., a payment processing network) that originates or processes the value added services data. Table 1 below provides examples of value added services data.
- Exemplary value added services data list Value added services data Description Data Type Merchant loyalty ID Loyalty ID issued by a Alphanumeric merchant and processed at a POS terminal Alternate loyalty Loyalty ID in the form of a E-mail address credential - e-mail consumer e-mail address Alternate loyalty Loyalty ID in the form of a Numeric credential - phone phone number Order confirmation Order number placed by Alphanumeric consumer at merchant - for remote order and pickup Offer code Coupon/Offer code locally Numeric redeemable by the merchant POS terminal Employee ID Employee ID at retailer Alphanumeric which makes them eligible for special discounts Zip code Zip code which may be Numeric used for data analysis Ticket number Ticket number which may Alpha Numeric be processed by a POS terminal Token Requestor URL of Token Requestor URL (Wallet) URL (Wallet) Service for merchant POS to close the loop
- the data transmit application 302 A may obtain and consolidate this information into a single data element.
- the single data element can be transmitted to the POS terminal 306 at the merchant.
- the data transmit application 302 A may be a QR code generation module, which may generate a single QR code which encodes the token, the non-transactable account identifier, and any value added services data.
- Other information that may be included in the single data element may include cryptograms or other information that may be generated by the payment device 302 .
- multiple data elements can be generated to encode the token and its associated data, as well as the value added services data.
- the single data element is generated by the payment device 302 , in step S 406 , it is then passed to data receive application 306 A in the POS terminal 306 .
- the data receive application 306 A working in conjunction with a data processor in the POS terminal 306 , may then convert the single data element into the original data that was used to form the single data element.
- the POS shopping application 306 C in the POS terminal 306 can then optionally retrieve any additional value added service data (e.g., coupons) from a local value added service data store 306 D or from the external value added services computer 318 , and can perform any desired processing.
- the value added services data could be a coupon that is redeemable at the merchant that operates the POS terminal 306 .
- the POS shopping application 306 C may reduce the amount of the transaction by the value of the coupon when generating an authorization request message for the amount that will be owed by the consumer when conducting the transaction.
- the POS terminal 306 After the POS shopping application determines the amount of the payment transaction, the POS terminal 306 then generates an authorization request message comprising at least some of the elements in the transaction payload received from the payment device 302 .
- the token may be in the data field in the authorization request message normally reserved for the PAN, while the non-transactable payment account identifier may be placed in a supplemental or discretionary data field such as Field 55 . If desired, the data in the supplemental discretionary data field may follow a tag-length-value data format.
- the authorization request message is transmitted by the POS terminal 306 via the payment API 306 B to the acquirer computer 310 .
- the authorization request message may comprise any suitable data including the token and the non-transactable payment account identifier. It may also include the token expiration date, the cryptogram from the payment device 302 , the token requestor identifier, the digital wallet identifier, and a POS terminal entry mode.
- the POS terminal entry mode may identify the mode in which the POS terminal 306 received the transaction payload from the payment device 302 .
- the POS terminal entry mode may indicate that a QR code was the mechanism that was used to transmit the transaction payload from the payment device 302 to the POS terminal 306 .
- This information can be useful to a downstream payment processor. For example, some modes of data transmission are inherently more secure or reliable than other modes of data transmission. This information can be used, for example, to improve transaction fraud scoring.
- step S 410 after receiving the authorization request message from the POS terminal 306 , the authorization request message is then transmitted from the acquirer computer 310 to the payment processing network 312 .
- the payment processing network 312 may then alter the authorization request message. For example, a computer in the payment processing network 312 may provide the token, the token expiration date, and any other appropriate information to the tokenization service computer 322 . If the token is valid, the tokenization service computer 322 may then provide the real account identifier to the payment processing network 312 . The payment processing network can then replace the token and the token expiration date in the authorization request message with the real account identifier (e.g., a PAN) and the expiration date for the real account identifier.
- the real account identifier e.g., a PAN
- step S 412 the modified authorization request message is then transmitted by the payment processing network 312 to the issuer computer 314 .
- the issuer computer 314 determines whether or not the transaction should be authorized. It may conduct any appropriate fraud or credit checks to determine whether or not to approve of the transaction. After this analysis occurs, in step S 414 , the issuer computer 314 then generates and sends an authorization response message comprising the real account identifier back to the payment processing network computer 312 .
- the payment processing network 312 may then substitute the token for the real account identifier in the authorization response message.
- the payment processing network 312 may also provide other information in the authorization response message including, but not limited to a PAN product ID (e.g., an ID that indicates that the PAN is associated with a credit card with a higher customer status), the last four digits of the real account identifier, the token assurance level, the non-transactable payment account identifier, and the token requestor identifier.
- step S 416 after the payment processing network 312 modifies the authorization response message, the payment processing network 312 may transmit the modified authorization response message to the acquirer computer 310 .
- step S 418 after the acquirer computer 310 receives the authorization response message, the acquirer computer 310 may transmit the authorization response message to the POS terminal 306 .
- a clearing and settlement process between the issuer computer 314 , the payment processing network 312 , and the acquirer computer 310 may occur.
- account information and token exchanges that are similar to those in the above-described authorization processing steps can occur.
- Subsequent transactions using different transactable payment tokens using the same payment device may use the same non-transactable payment account identifier.
- each of those entities may retrieve, store, analyze, and process the transaction data associated with the non-transactable payment account identifier. This is the case, even though different payment tokens are used for different transactions conducted with the same underlying account or payment device.
- Embodiments of the invention have a number of advantages.
- the non-transactable payment account identifier allows merchants to track consumer spending habits, analyze fraud/risk, provide transaction feeds to third party applications, etc. without requiring sensitive payment account information, such as a PAN.
- tokens may be used to make a consumer's payment account information more secure without interfering with a merchant's programs.
- the merchant or other entity may be able to aggregate all token spending records for one payment account via the non-transactable payment account identifier.
- FIG. 5 is a high level block diagram of a computer system that may be used to implement any of the entities or components described above.
- the subsystems shown in FIG. 5 are interconnected via a system bus 500 .
- Additional subsystems include a printer 508 , keyboard 516 , fixed disk 518 , and monitor 512 , which is coupled to display adapter 510 .
- Peripherals and input/output (I/O) devices which couple to I/O controller 502 , can be connected to the computer system by any number of means known in the art, such as a serial port.
- serial port 514 or external interface 520 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner.
- system bus 300 allows the central processor 506 to communicate with each subsystem and to control the execution of instructions from system memory 504 or the fixed disk 518 , as well as the exchange of information between subsystems.
- the system memory 504 and/or the fixed disk may embody a computer-readable medium.
- the inventive service may involve implementing one or more functions, processes, operations or method steps.
- the functions, processes, operations or method steps may be implemented as a result of the execution of a set of instructions or software code by a suitably-programmed computing device, microprocessor, data processor, or the like.
- the set of instructions or software code may be stored in a memory or other form of data storage element which is accessed by the computing device, microprocessor, etc.
- the functions, processes, operations or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.
- any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques.
- the software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM.
- RAM random access memory
- ROM read-only memory
- magnetic medium such as a hard-drive or a floppy disk
- an optical medium such as a CD-ROM.
- Any such computer-readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
A method for utilizing a non-transactable account identifier with a payment token is disclosed. The non-transactable account identifier can have the same format as a primary account number (PAN) and the payment token, but is not used to conduct a payment transaction.
Description
- This application is a non-provisional application of and claims the benefit of the filing date of U.S. Provisional Application No. 61/927,381, filed on Jan. 14, 2014, which is herein incorporated by reference in its entirety for all purposes.
- In the current payments ecosystem, merchants, processors and acquirers currently use PANs (primary account numbers) to process payment transactions and to identify cardholders for loyalty programs, fraud checks and reporting.
- While the use of PANs for such purposes has been useful, the use of PANs as accountholder identification mechanisms is problematic. If PANs are retained by merchants, for example, the merchants will need to be PCI (payment card industry) compliant. To be PCI compliant, merchants need to take a number of steps to improve the security of their data systems. Such steps can be resource and time intensive to implement and maintain.
- One way to avoid the need to be PCI compliant is to use payment tokens or “tokens” instead of PANs. Tokens can be substitutes for real PANs. A token can be used in place of a real PAN in a payment transaction. If the token is stolen by an unauthorized user (e.g., a hacker), then a new token can be issued in place of the token that was stolen. In this situation, the underlying real PAN is protected and the consumer's basic account information need not be re-issued.
- Although the use of tokens is desirable, the number of tokens used in a particular payments ecosystem can be very large. In some cases, each accountholder PAN can be mapped to multiple tokens (1-N mapping). For example, if a PAN is used in multiple digital wallets, each wallet instance can have a different static token for the same cardholder PAN. In another example, a different token relating to a PAN can be issued for each transaction.
- Because the number of tokens corresponding to a single PAN is unknown to an entity such as merchant, and because a token is intended to obscure a real PAN, it is difficult if not impossible for an entity such as a merchant to determine who the accountholder is if the merchant is in possession of the token. As such, in a conventional token based payments system, entities such as merchants are unable to perform fraud processing, operate loyalty programs, and other processes that would necessarily require them to know who the accountholder is or might be.
- Embodiments of the invention address these and other problems, individually and collectively.
- Embodiments of the invention can relate to systems and methods that can utilize payment tokens and non-transactable payment account identifiers. In some embodiments of the invention, a non-transactable payment account identifier may have the same format as a PAN. Because of this, an entity's existing processing system (i.e., systems that process PANs) can utilize the non-transactable payment account identifier much like it would for a real PAN. However, unlike a PAN or a transactable payment token, the non-transactable payment account identifier cannot be used to conduct a payment transaction. Consequently, the non-transactable payment account identifiers according to embodiments of the invention can be stored and used by entities such as merchants, acquirers, and program operators to perform operations including loyalty processing, fraud processing, and reporting, even though tokens are used to conduct payment transactions. As such, such entities do not need to be PCI compliant.
- One embodiment of the invention is directed to a method. The method comprises receiving, by a token service computer, a token request comprising a primary account identifier from a token requestor computer, and then determining, by the token service computer, a transactable payment token and a non-transactable payment account identifier associated with the primary account identifier. The method also includes transmitting, by the token service computer, the transactable payment token and the non-transactable payment account identifier to the token requestor computer. If the token requestor computer is not a consumer's payment device, the token requestor computer may provide the transactable payment token and the non-transactable payment account identifier to the payment device. The transactable payment token and the non-transactable payment account identifier can then be passed from the consumer's payment device to an access device to conduct a transaction. The transactable payment token can be used by the access device to process a payment for the transaction instead of the primary account identifier, while the non-transactable payment account identifier can be used as a reference for the primary account identifier to perform an operation that is not a payment transaction.
- Another embodiment of the invention is directed to a token service computer configured to perform the above-described method.
- Another embodiment of the invention is directed to a method comprising receiving, by a token service system, a token request associated with account information and then determining a non-transactable payment account identifier and a payment token. The method also includes providing the non-transactable payment account identifier and a token associated with the account information, and then receiving an authorization request message including the token and the non-transactable payment account identifier from a merchant. The method also includes adding the account information to the authorization request message and sending the authorization request message to an issuer. The method further includes receiving an authorization response message including the account information from the issuer and replacing the account information with the transactable payment token and the non-transactable payment account identifier in the authorization response message. The method further includes sending the authorization response message to the merchant.
- Another embodiment of the invention is directed to a token service system configured to perform the above-described method.
- Further details regarding embodiments of the invention can be found in the Detailed Description and the Figures.
-
FIG. 1 shows a block diagram of a system according to an embodiment of the invention. -
FIG. 2 shows a flowchart illustrating a method according to an embodiment of the invention. -
FIG. 3 shows a block diagram of another system according to an embodiment of the invention. -
FIG. 4 shows a flow diagram illustrating methods that can be used with the system illustrated inFIG. 3 . -
FIG. 5 shows a block diagram of a computer apparatus according to an embodiment of the invention. - Embodiments of the invention use a non-transactable payment account identifier to allow entities (e.g., merchant, acquirer, etc.) within a transaction eco-system to identify an accountholder when using tokens in lieu of traditional PANs. The non-transactable payment account identifier enables entities such as merchants and acquirers to identify accountholders when using transactable payment tokens for various applications. Such applications include, but are not limited to: fraud and risk checks on transaction authorization requests, fraud and risk reviews after transactions are completed, performance of value added services (e.g., loyalty, backend applications, reporting), and transaction feeds for third party value added applications.
- Prior to discussing specific embodiments of the invention, some terms may be described in detail.
- A “non-transactable payment account identifier” (alternatively referred to as a “PAID”) may be any string of characters that identify an accountholder and that is not used to conduct a payment transaction on an underlying account. For example, in some embodiments, a non-transactable payment account identifier may be 16-19 digits (or any other suitable length) and may be based on the format and rules of a PAN (primary account number). The non-transactable payment account identifier may be static over time and any number of transactions. A non-transactable account identifier may have a BIN (bank identification number) that is the same as the BIN for the corresponding real account identifier. Alternatively, it may have a BIN that is derived from or completely random with respect to the real BIN. The BIN in the non-transactable account identifier could also be a static tokenized BIN.
- In some embodiments, the non-transactable payment account identifier may include one or more characters that may indicate that it cannot be used to conduct a payment transaction. For example, it could be that all non-transactable payment account identifiers may start with the characters “99.” Any data strings that are similar in length to a real PAN in any transaction request messages would be treated by any suitable payment processing computers as being non-transactable. In other embodiments, non-transactable payment account identifiers may not be readily identified as being non-transactable by an outside observer. For example, a token service computer (e.g., a token vault) may generate a list of non-transactable payment account identifiers, and that list may be distributed by the token service computer to any entity (e.g., a merchant) that may wish to store or use the non-transactable payment account identifiers. If one tries to use the non-transactable payment account identifier to conduct a transaction, it will not be processed and/or routed by one or more computers in the payments system.
- “Payment account information” may be any information that identifies or is associated with a payment account. Payment account information may be provided in order to make a payment from a payment account. Some examples of payment account information include one or more of a PAN (primary account number), a CVV (card verification value), a dCVV (dynamic card verification value), a user name, an expiration date, a gift card number or code, etc.
- A “real account identifier” may include a transactable identifier associated with a payment account that directly represents the payment account. For example, a real account identifier may be a primary account number (PAN) issued by an issuer for a card account (e.g., credit card, debit card, etc.). For instance, in some embodiments, a real account identifier may include a sixteen digit numerical value such as “4147 0900 0000 1234.” The first six digits of the real account identifier (e.g., “414709”), may represent a real issuer identifier (e.g., a “BIN” or bank identification number) that may identify an issuer associated with the real account identifier.
- “Tokenization” is a process by which data is replaced with substitute data. For example, a payment account identifier (e.g., a primary account number (PAN)) may be tokenized by replacing the primary account identifier with a substitute number (e.g. a token) that may be associated with the payment account identifier. Further, tokenization may be applied to any other-information which may be replaced with a substitute value (i.e., token). Tokenization may be used to enhance transaction efficiency, improve transaction security, increase service transparency, or to provide a method for third-party enablement.
- “Token exchange” or “de-tokenization” can include a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with a corresponding primary account number (PAN) that was associated with the payment token during tokenization of the PAN. Thus, the de-tokenization may refer to the process of redeeming a token for the associated PAN value based on a token-to-PAN mapping stored, for example, in a token vault. The ability to retrieve a PAN in exchange for the associated token may be restricted to specifically authorized entities, individuals, applications, or systems. Further, de-tokenization or token exchange may be applied to any other information. In some embodiments, token exchange may be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request).
- A “transactable payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN). For example, a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” In some embodiments, a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing payment processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.
- A “Bank Identification Number (BIN)” may be a number that identifies a bank. A BIN may be assigned by a payment network to an issuer of a payment account. BINs may be consistent with industry account and issuer identification specifications (e.g. ISO 7812) such that the payment network assigning the BIN may be identified based on the BIN and associated account ranges.
- A “token BIN” may refer to a specific BIN that has been designated only for the purpose of issuing tokens and may be flagged accordingly in BIN tables. Token BINs may not have a dual purpose and may not be used to issue both primary account numbers (PANs) and tokens.
- A “token issuer identifier range (issuer BIN range)” may refer to a unique identifier (e.g., of 6 to 12 digits length) originating from a set of pre-allocated token issuer identifiers (e.g., 6 digit token BINs). For example, in some embodiments, one or more token BIN ranges can be allocated to each issuer BIN range that is associated with an issuer. In some embodiments, the token BIN ranges may be used to generate a payment token and may not be used to generate a non-payment token. In some embodiments, a token may pass the basic validation rules of an account number including, for example, a LUHN check or checksum validation that may be set up by different entities within the payment system. In some embodiments, a payment token issuer identifier may be mapped to a real issuer identifier (e.g., a BIN) for an issuer. For example, a payment token issuer identifier may include a six digit numerical value that may be associated with an issuer. For instance, any token including the payment token issuer identifier may be associated with a particular issuer. As such, the issuer may be identified using the corresponding issuer identifier range associated with the token issuer identifier. For example, a payment token issuer identifier “490000” corresponding to a payment token “4900 0000 0000 0001” can be mapped to an issuer identifier “414709” corresponding to a payment account identifier “4147 0900 0000 1234”. In some embodiments, a payment token issuer identifier is static for an issuer. For example, a payment token issuer identifier (e.g., “490000”) may correspond to a first issuer and another payment token issuer identifier (e.g., “520000”) may correspond to a second issuer, and the first and second payment token issuer identifiers may not be changed or altered without informing all entities within the network token processing system. In some embodiments, a payment token issuer identifier range may correspond to an issuer identifier. For example, payment tokens including payment token issuer identifiers from “490000”-“490002” may correspond to a first issuer (e.g., mapped to issuer identifier “414709”) and payment tokens including payment token issuer identifiers from “520000”-“520002” may correspond to a second issuer (e.g., mapped to real issuer identifier “417548”). Token BIN Ranges and assignment of tokens from these BIN ranges may be made available to the parties (e.g., via routing tables) accepting the transaction to make routing decisions.
- A “token service system” can include a system that that services payment tokens. In some embodiments, a token service system can facilitate requesting, determining (e.g., generating) and/or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g. token vault). In some embodiments, the token service system may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service system may support token processing of payment transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN. In some embodiments, a token service system may include a token service computer alone, or in combination with other computers such as a payment processing network computer.
- A “token service provider” may include an entity that services payment tokens. In some embodiments, the token service provider may operate one or more server computers in a token service system that generate, process and maintain tokens. The token service provider may include or be in communication with a token vault where the generated tokens are stored. Specifically, the token vault may maintain one-to-one mapping between a token and a primary account number (PAN) represented by the token. The token service provider may have the ability to set aside licensed BINs as token BINs to issue tokens for the PANs that may be submitted to the token service provider. Various entities of a tokenization ecosystem may assume the roles of the token service provider. For example, payment networks and issuers or their agents may become the token service provider by implementing the token services according to embodiments of the present invention. A token service provider may provide reports or data output to reporting tools regarding approved, pending, or declined token requests, including any assigned token requestor IDs. The token service provider may provide data output related to token-based transactions to reporting tools and applications and present the token and/or PAN as appropriate in the reporting output.
- A “token vault” may be an example of a token service computer and can include a repository that maintains established token-to-PAN mappings. According to various embodiments, the token vault may also maintain other attributes of the token requestor that may be determined at the time of registration. The attributes may be used by the token service provider to apply domain restrictions or other controls during transaction processing. In some embodiments, the token vault may be a part of the token service system or the token service provider. Alternatively, the token vault may be a remote repository accessible to the token service provider. Token vaults, due to the sensitive nature of the data mappings that are stored and managed in them, may be protected by strong underlying physical and logical security.
- An “identification and verification (ID&V) method” may be used to evaluate whether the person conducting the transaction is the legitimate account holder. Examples of ID&V methods may include, but are not limited to, an account verification message, a risk score based on assessment of the primary account number (PAN) and use of one time password by the issuer or its agent to verify the account holder. Exemplary ID&V methods may be performed using information such as a user signature, a password, an offline or online personal identification number (PIN), an offline or online enciphered PIN, a combination of offline PIN and signature, a combination of offline enciphered PIN and signature, user biometrics (e.g. voice recognition, fingerprint matching, etc.), a pattern, a glyph, knowledge-based challenge-responses, hardware tokens (multiple solution options), one time passwords (OTPs) with limited use, software tokens, two-channel authentication processes (e.g., via phone), etc. Using the ID&V, a confidence level may be established with respect to the token to PAN binding.
- A “token assurance level” may include an indicator or a value that allows the token service provider to indicate the confidence level of the token to PAN binding. The token assurance level may be determined by the token service provider based on the type of identification and verification (ID&V) performed and the entity that performed the ID&V. The token assurance level may be set when issuing the token. The token assurance level may be updated if additional ID&V is performed.
- A “requested token assurance level” may include a token assurance level requested by the token requestor. The requested token assurance level may be included in a field of a token request message sent by the requestor to the token service provider for the generation/issuance of the token.
- An “assigned token assurance level” may include an actual (i.e. generated) value assigned by the token service provider to the token as the result of the identification and verification (ID&V) process performed by an entity within the tokenization ecosystem. The assigned token assurance level may be provided back to the token requestor in response to the token request message. The assigned token assurance level may be different than the requested token assurance level included in the token request message.
- “Token attributes” may include any feature or information about a token. For example, token attributes may include information that can determine how a token can be used, delivered, issued, or otherwise how data may be manipulated within a transaction system. For example, the token attributes may include a type of token, frequency of use, token expiry date and/or expiry time, a number of associated tokens, a transaction lifecycle expiry date, and any additional information that may be relevant to any entity within a tokenization ecosystem. For example, token attributes may include a wallet identifier associated with the token, an additional account alias or other user account identifier (e.g., an email address, username, etc.), a device identifier, an invoice number, etc. In some embodiments, a token requestor may provide token attributes at the time of requesting the generation of tokens. In some embodiments, a network token system, payment network associated with the network token system, an issuer, or any other entity associated with the token may determine and/or provide the token attributes associated with a particular token.
- A “token presentment mode” may indicate a method through which a token is submitted for a transaction. Some non-limiting examples of the token presentment mode may include machine readable codes (e.g., quick response code (QRC), barcode, etc.), mobile contactless modes (e.g., near-field communication (NFC) communication), e-commerce remote modes, e-commerce proximity modes, and any other suitable modes in which to submit a token. Tokens may be provided through any number of different methods. For example, in one implementation, a token may be embedded in machine-readable code which may be generated by a wallet provider, mobile application, or other application on mobile device and displayed on a display of the mobile device. The machine readable code can be scanned at the POS through which the token is passed to the merchant. A mobile contactless mode may include passing the token through NFC in a contactless message. An e-commerce remote mode may include submitting a token by a consumer or a wallet provider through an online transaction or as an e-commerce transaction using a merchant application or other mobile application. An e-commerce proximity mode may include submitting a token by a consumer from a wallet application on a mobile device at a merchant location.
- A “token requestor” include an entity that requests a token. The token requestor may initiate a request that a primary account number (PAN) be tokenized by submitting a token request message to the token service provider. According to various embodiments, a token requestor may no longer need to store a PAN associated with a token once the requestor has received a requested token. The requestor may be an application, a device, a process, or a system that is configured to perform actions associated with tokens. A token requestor can request registration with a network token system, request token generation, token activation, token de-activation, token exchange, token lifecycle management related processes, and/or any other token related processes. A requestor may interface with a network token system through any suitable communication networks and/or protocols (e.g., using HTTPS, SOAP and/or an XML interface among others). Some non-limiting examples of token requestors may include, for example, communication devices (e.g., mobile phones and computers) operated by consumers, card-on-file merchants, acquirers, acquirer processors, and payment gateways acting on behalf of merchants, payment enablers (e.g., original equipment manufacturers, mobile network operators, etc.), digital wallet providers, issuers, third party wallet providers, and/or payment processing networks. In some embodiments, a token requestor can request tokens for multiple domains and/or channels. A token requestor may be registered and identified uniquely by the token service provider within the tokenization ecosystem. During token requestor registration, the token service provider may formally process the token requestor's application to participate in the token service system. The token service provider may collect information pertaining to the nature of the requestor and the relevant use of tokens to validate and formally approve the token requestor and establish appropriate domain restriction controls. Successfully registered token requestors may be assigned a token requestor identifier that may also be entered and maintained within the token vault. Token requestors be revoked or assigned new token requestor identifiers. This information may be subject to reporting and audit by the token service provider.
- A “token requestor identifier (ID)” may include an identifier for a token requestor. It may include any characters, numerals, or other identifiers associated with an entity associated with a network token system. In some embodiments, a unique token requestor ID may be assigned for each domain for a token request associated with the same token requestor. For example, a token requestor ID can identify a pairing of a token requestor (e.g., a mobile device, a mobile wallet provider, etc.) with a token domain (e.g., e-commerce, contactless, etc.). A token requestor ID may include any format or type of information. For example, in one embodiment, the token requestor ID may include an alphanumerical value such as a ten digit or an eleven digit letter and/or number (e.g., 4678012345). In some embodiments, a token requestor ID may include a code for a token service provider (e.g., first 3 digits) such as the network token system and the remaining digits may be assigned by the token service provider for each requesting entity (e.g., mobile wallet provider) and the token domain (e.g., contactless, e-commerce, etc.).
- A “token request indicator” may refer to an indicator used to indicate that a message is related to a token request. The token request indicator may optionally be passed to the issuer as part of the Identification and Verification (ID&V) method to inform the issuer of the reason the account status check is being performed.
- A “token domain” may indicate the factors that can be established at the time of token issuance to enable appropriate usage of the token for payment transactions. Examples of the token domain may include, but are not limited to, a POS entry mode, and merchant identifiers to uniquely identify where the token can be used. A set of parameters (i.e. token domain restriction controls) may be established as part of token issuance by the token service provider that may allow for enforcing appropriate usage of the token in payment transactions. For example, the token domain restriction controls may restrict the use of the token with particular presentment modes, such as contactless or e-commerce presentment modes. In some embodiments, the token domain restriction controls may restrict the use of the token at a particular merchant that can be uniquely identified. Some exemplary token domain restriction controls may require the verification of the presence of a token cryptogram that is unique to a given transaction.
- “Token expiry date” may refer to the expiration date/time of the token. The token expiry date may be passed among the entities of the tokenization ecosystem during transaction processing to ensure interoperability. The token expiration date may be a numeric value (e.g. a 4-digit numeric value).
- A “consumer” may include an individual or a user that may be associated with one or more personal accounts and/or consumer devices. The consumer may also be referred to as a cardholder, account holder, or user.
- An “access device” may be any suitable device for communicating with a merchant computer or payment processing network, and for interacting with a payment device, a user computer apparatus, and/or a user mobile device. An access device may generally be located in any suitable location, such as at the location of a merchant. An access device may be in any suitable form. Some examples of access devices include POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, Websites on remote server computers, and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a payment device and/or a user mobile device.
- In some embodiments, the access device may be a POS terminal. A POS terminal may include a payment device reader, a processor, and a computer-readable medium. The reader may utilize any suitable contact or contactless mode of operation. For example, exemplary card readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers.
- An “authorization request message” may be an electronic message that is sent to a payment processing network and/or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or “account number”), a user name, an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction.
- An “authorization response message” may be an electronic message reply to an authorization request message generated by an issuing financial institution or a payment processing network. The authorization response message may include, by way of example only, one or more of the following status indicators: Approval—transaction was approved; Decline—transaction was not approved; or Call Center—response pending more information, merchant must call the toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the payment processing network) to the merchant's access device (e.g. POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization. As noted above, in some embodiments, a payment processing network may generate or forward the authorization response message to the merchant.
- A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.
- An “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user that is associated with a portable communication device such as an account enrolled in a mobile application installed on a portable communication device.
- A “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.
- An “acquirer” may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers.
-
FIG. 1 shows a system 100 comprising a number of components. The system 100 comprises atoken vault 110, which may be an example of at least part of a token service provider computer. Thetoken vault 110 may be in communication with one or more of atoken requestor 115, amerchant 130, anacquirer 135, apayment processing network 140, and anissuer 150. Each of thetoken requestor 115, themerchant 130, theacquirer 135, thepayment processing network 140, and theissuer 150 may be embodied by one or more computers. - The consumer 120 (i.e., a device operated by the consumer 120) may be in communication with the
token requestor 115, theissuer 150, and themerchant 130. Furthermore, themerchant 130, theacquirer 135, thepayment processing network 140, theissuer 150, and atoken network 145 may all be in operative communication with each other through any suitable communication channel or communications network. A suitable communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like. - The
token vault 110 may be associated with thepayment processing network 140, theissuer 150, theacquirer 135, or themerchant 130. Thetoken vault 110 can receive a token request from thetoken requestor 115, the request including information (e.g., a PAN) that identifies a payment account. Thetoken vault 110 can issue a token that can be used as surrogate payment account information. A record of the token may be stored at thetoken vault 110, and the record may include the token, token expiration date, associated payment account information, token assurance information, token requestor information, and/or any other suitable information. - The
token vault 110 may also generate a unique non-transactable payment account identifier that may be a static non-payment identifier. Thetoken vault 110 may associate the non-transactable payment account identifier with a PAN, so that the non-transactable payment account identifier is associated with a payment account. - In addition to providing the token, the
token vault 110 may provide a non-transactable payment account identifier to thetoken requestor 115 in response to a token request. Thus, thetoken vault 110 can provide both payment information (via a token) and identification (via a non-transactable payment account identifier) without providing the actual PAN associated with the payment account. In some embodiments, the non-transactable payment account identifier may first be generated and associated with the payment account the first time a token is requested for the payment account. The non-transactable payment account identifier may be identified and provided along with tokens in response to any future token requests. - The
token vault 110 may also be capable of de-tokenizing a token and providing payment account information in response to receiving the token. For example, thetoken vault 110 may receive requests for payment account information from thepayment processing network 140,issuer 150,acquirer 135, and/ormerchant 130. Thetoken vault 110 may receive a de-tokenization request including a token, identify payment account information that is associated with the token, and provide the payment account information to the de-tokenization requestor. - The
token vault 110 may be an example of a token service computer. The token service computer may comprise a processor and a computer readable medium. The computer readable medium comprising code, executable by the processor, for implementing a method. The method comprises receiving a token request comprising a primary account identifier from a token requestor computer, determining a transactable payment token and a non-transactable payment account identifier associated with the primary account identifier, and transmitting the transactable payment token and the non-transactable payment account identifier to the token requestor computer. If the token requestor computer is not a payment device, the token requestor computer passes the transactable payment token and the non-transactable payment account identifier to the payment device. The transactable payment token and the non-transactable payment account identifier are both passed from the consumer's payment device to an access device to conduct a transaction. The transactable payment token is used by the access device to process a payment for the transaction instead of the primary account identifier. The non-transactable payment account identifier is used as a reference for the primary account identifier to perform an operation that is not a payment transaction. - In some embodiments, the de-tokenization requestor may be the
payment processing network 140, which may request the payment account information for authorization purposes. In some embodiments, the de-tokenization requestor may be themerchant 130 which may wish to have the payment account information forconsumer 120 identification purposes. - The
token requestor 115 may request a token on behalf of theconsumer 120. Thetoken requestor 115 may be a digital wallet provider, amerchant 130,payment processing network 140, a payment device (e.g., the consumer's mobile phone), or any other suitable entity. Theconsumer 120 may wish to purchase a good and/or service from themerchant 130 and thetoken requestor 115 may retrieve a token from thetoken vault 110 for theconsumer 120 to use for the purchase. - The
merchant 130 is capable providing goods and/or services to theconsumer 120. In some embodiments, themerchant 130 may receive payment information comprising a token and a non-transactable payment account identifier from the consumer 120 (i.e., a payment device operated by the consumer 120) in a payment transaction. After receiving the token and the non-transactable payment account identifier, themerchant 130 may send the token and the non-transactable payment account identifier to theacquirer 135 for payment authorization. - In some embodiments, the
merchant 130 may use the non-transactable payment account identifier for tracking consumer activity. The non-transactable payment account identifier may be static, so that the same non-transactable payment account identifier is provided each time aconsumer 120 uses a certain payment account at amerchant 130, even if the token is variable. For example, in some embodiments, one payment account may be associated with several digital wallets, and each digital wallet may have a different token associated with the same payment account. Themerchant 130 may receive the same non-transactable payment account identifier whenever any of these different tokens are received. Thus, themerchant 130 may be able to recognize a payment account by a received non-transactable payment account identifier. It is also possible for the merchant 130 (or other party) to request that the consumer that is associated with the non-transactable account identifier provide additional information about the consumer (e.g., name, home address, telephone number, zip code, etc.) so that themerchant 130 has additional information to link the consumer to the non-transactable account identifier. - The
merchant 130 may use the non-transactable payment account identifier as a consumer identifier instead of a PAN. Themerchant 130 may keep a record ofconsumer 120 trends by recording transactions that involve the non-transactable payment account identifier. In some embodiments, the non-transactable payment account identifier may comprise 16, 18, or 19 digits and can be formatted as a PAN so thatmerchants 130 can easily integrate a non-transactable payment account identifier into an existing consumer-tracking system that typically uses a PAN for consumer tracking. The non-transactable payment account identifier may replace a PAN for any suitable identification purpose. Aconsumer 120 may have more than one payment account, and thus theconsumer 120 may be associated with multiple non-transactable payment account identifiers. A non-transactable payment account identifier may also be formatted to indicate anissuer 150 and/or atoken vault 110. - In some embodiments, the
merchant 130 may use the non-transactable payment account identifier and associated consumer purchase record for other applications including value added services such as loyalty programs, backend applications, and reporting. For example, the non-transactable payment account identifier may function as aconsumer 120 loyalty identifier for tracking loyalty points and providing rewards or special offers. - The merchant 130 (or other entity) may also use the non-transactable payment account identifier for fraud/risk checks during authorization. For example, the
merchant 130 may be able to detect high-velocity transactions. If too many transactions (associated with the same payment token or multiple payment tokens corresponding to an underlying real account identifier) associated with the non-transactable payment account identifier occur within a certain amount of time, themerchant 130 may suspect fraudulent activity. The merchant may then reject further transactions involving the non-transactable payment account identifier. Alternatively, themerchant 130 may mark the non-transactable payment account identifier as high-risk or put the non-transactable payment account identifier on a “blacklist.” Themerchant 130 may also use the non-transactable payment account identifier to review fraud/risk levels after a transaction is authorized. - The
merchant 130 may use the non-transactable payment account identifier to access past transactions. For example, themerchant 130 may use the non-transactable payment account identifier to identify a past transaction for a refund or an inquiry. - The non-transactable payment account identifier may also be used for providing a transaction feed to third party value added applications. For example, the
merchant 130 may inform third party applications aboutconsumer 120 purchases and trends that are tracked via the non-transactable payment account identifier. A third-party may use a transaction feed for providing rewards or offers to the consumer in real time or offline (e.g. in a statement of credit). - The
acquirer 135 may be associated with themerchant 130, and may manage authorization requests on behalf of themerchant 130. Theacquirer 135 may receive an authorization request message including the token and non-transactable payment account identifier from themerchant 130 and send the authorization request message to apayment processing network 140. Thepayment processing network 140 may be associated with the token and may be identified by one or more fields within the token. - The
acquirer 135 may use the non-transactable payment account identifier for online fraud analysis, offline fraud analysis, loyalty services, third party loyalty programs, reporting to merchants, or any other suitable purpose. For example, in some embodiments, theacquirer 135 may flag a payment account (identified by a non-transactable payment account identifier) and an associatedmerchant 130 for fraud/risk level scoring. In another example, a non-transactable payment account identifier may be used for providing card-linked offers. In another example, theacquirer 135 may provide a consumer transaction report to merchants, the report including transactions that involved a certain non-transactable payment account identifier. - In some embodiments, the
merchant 130 and/or theacquirer 135 may be able to provide a non-transactable payment account identifier to thetoken vault 110 and then receive associated payment account information. Additionally, in some embodiments, themerchant 130 and/or theacquirer 135 may provide payment account information to thetoken vault 110, and then receive an associated non-transactable payment account identifier. For example, amerchant 130 may send a “Get PAN” request that includes the non-transactable payment account identifier to thetoken vault 110, and thetoken vault 110 may respond with the PAN information. Alternatively, themerchant 130 may send a “Get non-transactable payment account identifier” request including the PAN and/or the transactable payment token to thetoken vault 110, and receive a non-transactable payment account identifier associated with the PAN. - The
acquirer 135, thepayment processing network 140, and theissuer 150, may operate suitable routing tables to route authorization request messages using real account identifiers such as PANs or tokens. Token routing data may be provided or maintained by thetoken vault 110, and may be communicated to any of the entities inFIG. 1 . - The
payment processing network 140 may be disposed between theacquirer 135 and theissuer 150. Thepayment processing network 140 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. For example, thepayment processing network 140 may comprise a server computer, coupled to a network interface (e.g. by an external communication interface), and a database(s) of information. An exemplary payment processing network may include VisaNet™. Payment processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. Thepayment processing network 140 may use any suitable wired or wireless network, including the Internet. - The
payment processing network 140 may be able to de-tokenize any tokens in any authorization request message that is received. For example, thepayment processing network 140 may receive an authorization request message including a token and non-transactable payment account identifier, send the token and non-transactable payment account identifier to thetoken vault 110, receive associated payment account information from thetoken vault 110, and forward the authorization request message to theissuer 150 with the payment account information. Thepayment processing network 140 may also receive an authorization response message with the payment account information, and replace some or all of the payment account information with the token and/or non-transactable payment account identifier before forwarding the message to theacquirer 135. - In some embodiments, the
token vault 110 and thepayment processing network 140 may form a token service system. The token service system comprises a token service computer comprising a first processor and a first computer readable medium, the first computer readable medium comprising code, executable by the first processor to implement a method. The method includes receiving a token request associated with account information, determining a non-transactable payment account identifier and a transactable payment token associated with the account information, and providing the non-transactable payment account identifier and the transactable payment token associated with the account information. The method also includes a payment processing network computer in communication with the token service computer. The payment processing network computer comprises a second processor and a second computer readable medium, the second computer readable medium comprising code, executable by the second processor for implementing a method. The method comprises receiving an authorization request message including the transactable payment token and the non-transactable payment account identifier from a merchant, adding the account information to the authorization request message, sending the authorization request message to an issuer, receiving an authorization response message including the account information from the issuer, replacing the account information with the transactable payment token and the non-transactable payment account identifier in the authorization response message, and sending the authorization response message to the merchant. - The
token network 145 may also be able to provide de-tokenization services. Thetoken network 145 may include another payment processing network, another token vault, and/or another token requestor. For example, in some embodiments, theconsumer 120 may receive a token that is associated with a payment processing network of thetoken network 145. In order to de-tokenize the token for authorization, thepayment processing network 140 may send the token and non-transactable payment account identifier to thetoken network 145, which may then return the payment account information. In some embodiments, thetoken network 145 may wish to de-tokenize a token that is associated with thepayment processing network 140, and may obtain associated payment account information by similarly communicating with thepayment processing network 140 andtoken vault 110. - A
method 200 according to embodiments of the invention can be described with respect toFIG. 2 . The steps shown in themethod 200 may be performed sequentially or in any suitable order in embodiments of the invention. - In a purchase transaction, the
consumer 120 may purchase a good or service at amerchant 130. Themerchant 130 may then request that theconsumer 120 provide payment information to conduct the purchase. Instead of providing a credit card number to themerchant 130, theconsumer 120 can use a token to conduct the payment transaction. Theconsumer 120 may cause thetoken requestor 115 to request a token to conduct the transaction. In this example, thetoken requestor 115 may be the consumer's mobile phone or may be a digital wallet that is associated with the consumer's mobile phone. Thetoken requestor 115 may then send a token request to thetoken vault 110 on behalf of theconsumer 120. - The token may be requested or provided using any suitable form of communication. In some embodiments, a token request may be in an electronic message format, such as an e-mail, a short messaging service (SMS) message, a multimedia messaging service (MMS) message, a hypertext transfer protocol (HTTP) request message, a transmission control protocol (TCP) packet, a web form submission. The token request may be directed to any suitable location, such as an e-mail address, a telephone number, an internet protocol (IP) address, or a uniform resource locator (URL). In some embodiments, a token request may comprise a mix of different message types, such as both email and SMS messages.
- Further, the token request may include any suitable type of information. For example, the token request may include an account identifier (e.g., a PAN) associated with an account that is to be used to pay for the good or service, a token requestor ID, or any other suitable information.
- In step S210, the
token vault 110 may receive the token request from thetoken requestor 115. As noted above, the token request may include information about the payment account for which a token is desired. - In step S220, in response to the token request, the
token vault 110 may determine (e.g., generate or identify) a non-transactable payment account identifier and associate the non-transactable payment account identifier with the payment account information of theconsumer 120. Thetoken vault 110 may store a record of the non-transactable payment account identifier and associated payment account information in a database if desired. - The non-transactable payment account identifier may be determined in any suitable manner. For example, the non-transactable payment account identifier may be generated using an algorithm that converts a real PAN into the non-transactable payment account identifier. In some embodiments, the algorithm may be an encryption algorithm such as DES, triple DES, etc. In another example, a listing of non-transactable payment account identifiers may be generated in advance and a non-transactable payment account identifier could be assigned to each received token request.
- In step S230, the
token vault 110 may then determine (e.g., identify or generate) a token that represents or is associated with the indicated payment account information. Thetoken vault 110 may maintain a record including the account information, the token associated with the account information, the non-transactable payment account identifier associated with the account information, a token expiration date, a token assurance level, and/or any other suitable information in a database. - The token may be determined in any suitable manner. For example, the non-transactable payment account identifier may be generated using an algorithm that converts a real PAN into the token. In another example, a listing of tokens may be generated in advance and a token could be assigned to each received token request.
- In step S240, the
token vault 110 may then transmit the token and the non-transactable payment account identifier to thetoken requestor 115 in a token response message. In other embodiments, the token and the non-transactable token may be transmitted to thetoken requestor 115 in multiple messages. The token response message may have the same or different form or format as the previously described token request message. It may also have additional information that was not present in the token request message. For example, the token response message may include other information such as the time period in which the token would be valid. - The
token requestor 115 may provide the information to the consumer 120 (i.e., a payment device operated by the consumer 120), which may then provide the token and non-transactable payment account identifier to themerchant 130. Or, thetoken requestor 115 may provide the information to themerchant 130. Any suitable mode of communication may be used to provide the information to themerchant 130. - As will be described in further detail below, in some embodiments, the token is provided as payment information and the non-transactable payment account identifier is provided as extended token data or additional VAS data. In some embodiments, the
token requestor 115 orconsumer 120 may generate a QR code that may include the token and the non-transactable payment account identifier in a transaction payload. Theconsumer 120 may provide the QR code to themerchant 130 via an access device. Any other suitable communication mechanism (e.g., a contactless mechanism) may be used to pass the token and the non-transactable payment account identifier (as well as any other transaction information) to the merchant. - In some embodiments, the
merchant 130 may then use the non-transactable payment account identifier to identify a purchase record of theconsumer 120 and may update the record with the current transaction. Themerchant 130 may use the non-transactable payment account identifier-identifiedconsumer 120 record for various applications including online fraud analysis, offline fraud analysis, value added services (e.g. loyalty, backend applications, reporting), third-party transaction feeds, or any other suitable purposes. - The
merchant 130 may forward the token, the non-transactable payment account identifier, and other information to theacquirer 135 in an authorization request message. The token may be in the data field in the authorization request message normally reserved for the PAN, while the non-transactable payment account identifier may be placed in a supplemental or discretionary data field such as Field 55. If desired, the data in the supplemental discretionary data field may follow a tag-length-value data format. - The
acquirer 135, in turn, may send the authorization request message to thepayment processing network 140. Theacquirer 135 may also use the non-transactable payment account identifier for identifying theconsumer 120, online fraud analysis, offline fraud analysis, loyalty services, third party loyalty programs, value added services (e.g. loyalty, backend applications), third-party transaction feeds, reporting to merchants, or any other suitable purposes. - In step S250, the
payment processing network 140 may receive the authorization request message. After thepayment processing network 140 receives the authorization request message, it extracts the token from the authorization request message and then de-tokenizes it. In some embodiments, it can do this by requesting the payment account information from thetoken vault 110. In some embodiments, if the token is associated with another payment processing network that is a part of a differenttoken network 145, thepayment processing network 140 may request the payment account information from thetoken network 145. - The
token vault 110 may receive the token and/or non-transactable payment account identifier from thepayment processing network 140. In step S260, thetoken vault 110 may identify the associated payment account information in the token record, and send the payment account information to thepayment processing network 140. - In step S270, the
payment processing network 140 may replace the token in the authorization request message with the payment account information. For example, if the account information includes a PAN, then the token is removed from the PAN data field in the authorization request message. The PAN is then added back into the authorization request message. The non-transactable payment account identifier may remain in a supplemental data field. Once this is done, thepayment processing network 140 may forward the authorization request message to theissuer 150. - After the
issuer 150 receives the authorization request message, theissuer 150 may analyze it and may determine whether or not to authorize the transaction. Theissuer 150 may determine if the account associated with the authorization request message has sufficient funds or credit. It may also determine that the transaction is not inherently risky. If the transaction is authorized by theissuer 150, theissuer 150 may send an authorization response including the payment account information and an approval code to thepayment processing network 140. - In step S280, the
payment processing network 140 receives the authorization response message including the payment account information from theissuer 150. Thepayment processing network 140 may then query thetoken vault 110 for information associated with the payment account information, such as the token and non-transactable payment account identifier. Thetoken vault 110 may identify the requested information in the token record and provide it to thepayment processing network 140. - In step S290, the
payment processing network 140 may add the token, non-transactable payment account identifier, or any other suitable transaction information into the authorization response message, and may remove some or all of the payment account information from the message. For example, in some embodiments, the last four digits of a PAN may remain in the message, even though the real PAN is removed and is replaced with the token. The non-transactable payment account identifier may remain in a supplemental data field. - In step S295, the
payment processing network 140 may then forward the message to theacquirer 135. Theacquirer 135 may forward the message to themerchant 130, which may inform theconsumer 120 of the authorization results. Themerchant 130 may update the non-transactable payment account identifier-identifiedconsumer 120 transaction record with the authorization results. - At the end of the day or at some other predetermined interval of time, a clearing and settlement process between the
issuer 150, thepayment processing network 140, and theacquirer 135 may occur. In the clearing and settlement process, account information and token exchanges that are similar to those in the above-described authorization processing steps can occur. - Subsequent transactions using different transactable payment tokens using the same payment device may use the same non-transactable payment account identifier.
- As shown above, because the non-transactable payment account identifier passes through a number of entities in the payments system, each of those entities may retrieve, store, analyze, and process the transaction data associated with the non-transactable payment account identifier. This is the case, even though different payment tokens are used for different transactions conducted with the same underlying account or payment device.
-
FIG. 3 shows a block diagram of another embodiment of the invention.FIG. 3 shows a diagram of a more detailed system that can incorporate a non-transactable payment account identifier. -
FIG. 3 shows apayment device 302 and a POS terminal 306 (which is an example of an access device) which may be located at a merchant. ThePOS terminal 306 may communicate with anacquirer computer 310, apayment processing network 312, and anissuer computer 314. - The
payment device 302 may be in communication with awallet server computer 316, which may comprise a value added services module (which may include VAS data) 316A and apayment module 316B. Thewallet server computer 316 may communicate with an external value addedservices computer 318 as well as a cloud basedpayments platform 320 and atokenization service computer 322. Thetokenization service computer 322 may communicate with thepayment processing network 312. - The
payment device 302 may comprise a data transmitapplication 302A and amobile wallet application 302B. For clarity of illustration, some of the hardware and software elements in thepayment device 302 are not shown inFIG. 3 . Thepayment device 302 may additionally include a data processor, and a communication interface (e.g., a contactless interface), a memory, a computer readable medium, input devices (e.g., input keys, a microphone, etc.), output devices (e.g., a touchscreen, speaker, etc.), and an antenna (e.g., for long range communication). Thepayment device 302 may be in the form of a payment card, a key fob, a mobile phone, a tablet computer, a wearable device, etc. - The
POS terminal 306 may comprise a data receiveapplication 306A, a payment API (application program interface) 306B, a POS shopping application 306C, and a local value added services (VAS)application 306D. For clarity of illustration, some of the hardware and software elements in thePOS terminal 306 are not shown inFIG. 3 . ThePOS terminal 306 may additionally include a data processor, and a communication interface (e.g., a contactless interface, a data reader such as a card reader), a memory, a computer readable medium, input devices (e.g., input keys, a microphone, etc.), output devices (e.g., a touchscreen, speaker, etc.), and an antenna (e.g., for long range communication). - The
wallet server 316 may comprise a data processor, a memory and a computer readable medium. TheVAS module 316A and thepayment module 316B may reside in the memory and/or the computer readable medium. Thewallet server 316 may store payment account data (e.g., transactable payment tokens) that may be used by thepayment device 302 to conduct purchase transactions. - The external value added
services computer 318 may be operated by an entity that is different than the other entities shown inFIG. 3 . It may provide value added data (described above and below) to thewallet server 316 and thepayment device 302. - The cloud based
payments platform 320 may include a gateway that supplies transactable payment tokens, non-transactable payment account identifiers and other information directly or indirectly to thepayment device 302. - The
tokenization service computer 322 can perform tokenization services and can include the above described token vault. -
FIG. 4 shows a flow diagram illustrating methods that can be used with the system illustrated inFIG. 3 . In particular, methods illustrating the use of the non-transactable account identifier with value added services data can be described with reference toFIGS. 3 and 4 . - In embodiments of the invention, non-payment data can be provided by merchant or third party applications, which may be used primarily by a merchant POS terminal (and optionally by an acquirer) to provide value added services to consumers. Merchants prefer to have non-payment information (e.g., loyalty IDs, coupon IDs, order numbers, etc.) with payment credentials to provide value added services. Merchants currently get this information in different forms (e.g., manually, cards, multiple apps, etc.) through multiple consumer interactions. This mode of providing such non-payment information is inconvenient for consumers. As illustrated below, embodiments of the invention can combine non-payment data from one or more data sources with payment data in a single data element, which may be transmitted from a payment device to a POS terminal.
- Referring to
FIG. 4 , in step S400, awallet application 302B in a payment device 302 (e.g., a mobile phone) may send a token request to atokenization service computer 322. The token request may include an account identifier such as a PAN or some other identifier related to the account. Further details on token requests are provided above. - In step S402, after the token request is received by the
tokenization service computer 322, thetokenization service computer 322 performs any desired fraud or status checks on the token request. If the checks indicate that a token can be issued, thetokenization service computer 322 can transmit a token to thewallet application 302B in thepayment device 302. In addition to the token, thetokenization service computer 322 may transmit other information including one or more of a token expiration date, a token requestor ID, a digital wallet ID, and a non-transactable payment account identifier to thewallet application 302B on thepayment device 302. The token and the other information may be transmitted to thewallet application 302B in thepayment device 302 in a single communication or in multiple communications. - In step S404, before or after step S402, one or more value added
service data sources wallet application 302B on thepayment device 302. The data sources may include value addedservices data 316A from thewallet server 316 or value added data from the external value addedservices computer 318. Examples of value added services data may include one or more of a loyalty identifier (e.g., a frequent flier account number) held by the consumer, a coupon identifier, and an order number for a past or current purchase. - The
wallet application 302B passes the data from thetoken service computer 322 and the value added service data source(s) 316, 318 to the data transmitapplication 302A in thepayment device 302A. The data transmitapplication 302A operating in conjunction with a data processor on thepayment device 302A generates a transaction payload and it may be in the form of a data element such as a QR code. Other data elements such as a cryptogram may be generated by thepayment device 302A and may be included in the transaction payload. By incorporating value added services data from thewallet application 302B in thepayment device 302 with the token, value added services that can benefit the consumer or others can be easily provided at the point of transaction. - The value added services data may be in any suitable form, and may include any suitable type of data. It may include strings of characters, image files, videos, etc. Each piece of value added data may have a tag value associated with it. The tag may be defined by the entity (e.g., a payment processing network) that originates or processes the value added services data. Table 1 below provides examples of value added services data.
-
TABLE 1 Exemplary value added services data list Value added services data Description Data Type Merchant loyalty ID Loyalty ID issued by a Alphanumeric merchant and processed at a POS terminal Alternate loyalty Loyalty ID in the form of a E-mail address credential - e-mail consumer e-mail address Alternate loyalty Loyalty ID in the form of a Numeric credential - phone phone number Order confirmation Order number placed by Alphanumeric consumer at merchant - for remote order and pickup Offer code Coupon/Offer code locally Numeric redeemable by the merchant POS terminal Employee ID Employee ID at retailer Alphanumeric which makes them eligible for special discounts Zip code Zip code which may be Numeric used for data analysis Ticket number Ticket number which may Alpha Numeric be processed by a POS terminal Token Requestor URL of Token Requestor URL (Wallet) URL (Wallet) Service for merchant POS to close the loop - After the
wallet application 302B receives the value added services data, the token, the non-transactable account identifier, and any other suitable information in the token response from thetokenization service computer 322, the data transmitapplication 302A may obtain and consolidate this information into a single data element. The single data element can be transmitted to thePOS terminal 306 at the merchant. For instance, the data transmitapplication 302A may be a QR code generation module, which may generate a single QR code which encodes the token, the non-transactable account identifier, and any value added services data. Other information that may be included in the single data element may include cryptograms or other information that may be generated by thepayment device 302. In other embodiments, multiple data elements can be generated to encode the token and its associated data, as well as the value added services data. - After the single data element is generated by the
payment device 302, in step S406, it is then passed to data receiveapplication 306A in thePOS terminal 306. The data receiveapplication 306A, working in conjunction with a data processor in thePOS terminal 306, may then convert the single data element into the original data that was used to form the single data element. The POS shopping application 306C in thePOS terminal 306 can then optionally retrieve any additional value added service data (e.g., coupons) from a local value addedservice data store 306D or from the external value addedservices computer 318, and can perform any desired processing. For example, in some embodiments, the value added services data could be a coupon that is redeemable at the merchant that operates thePOS terminal 306. The POS shopping application 306C may reduce the amount of the transaction by the value of the coupon when generating an authorization request message for the amount that will be owed by the consumer when conducting the transaction. - After the POS shopping application determines the amount of the payment transaction, the
POS terminal 306 then generates an authorization request message comprising at least some of the elements in the transaction payload received from thepayment device 302. The token may be in the data field in the authorization request message normally reserved for the PAN, while the non-transactable payment account identifier may be placed in a supplemental or discretionary data field such as Field 55. If desired, the data in the supplemental discretionary data field may follow a tag-length-value data format. - In step S408, the authorization request message is transmitted by the
POS terminal 306 via thepayment API 306B to theacquirer computer 310. The authorization request message may comprise any suitable data including the token and the non-transactable payment account identifier. It may also include the token expiration date, the cryptogram from thepayment device 302, the token requestor identifier, the digital wallet identifier, and a POS terminal entry mode. - The POS terminal entry mode may identify the mode in which the
POS terminal 306 received the transaction payload from thepayment device 302. For example, the POS terminal entry mode may indicate that a QR code was the mechanism that was used to transmit the transaction payload from thepayment device 302 to thePOS terminal 306. This information can be useful to a downstream payment processor. For example, some modes of data transmission are inherently more secure or reliable than other modes of data transmission. This information can be used, for example, to improve transaction fraud scoring. - In step S410, after receiving the authorization request message from the
POS terminal 306, the authorization request message is then transmitted from theacquirer computer 310 to thepayment processing network 312. - After the
payment processing network 312 receives the authorization request message, it may then alter the authorization request message. For example, a computer in thepayment processing network 312 may provide the token, the token expiration date, and any other appropriate information to thetokenization service computer 322. If the token is valid, thetokenization service computer 322 may then provide the real account identifier to thepayment processing network 312. The payment processing network can then replace the token and the token expiration date in the authorization request message with the real account identifier (e.g., a PAN) and the expiration date for the real account identifier. - In step S412, the modified authorization request message is then transmitted by the
payment processing network 312 to theissuer computer 314. - The
issuer computer 314 then determines whether or not the transaction should be authorized. It may conduct any appropriate fraud or credit checks to determine whether or not to approve of the transaction. After this analysis occurs, in step S414, theissuer computer 314 then generates and sends an authorization response message comprising the real account identifier back to the paymentprocessing network computer 312. - The
payment processing network 312 may then substitute the token for the real account identifier in the authorization response message. Thepayment processing network 312 may also provide other information in the authorization response message including, but not limited to a PAN product ID (e.g., an ID that indicates that the PAN is associated with a credit card with a higher customer status), the last four digits of the real account identifier, the token assurance level, the non-transactable payment account identifier, and the token requestor identifier. - In step S416, after the
payment processing network 312 modifies the authorization response message, thepayment processing network 312 may transmit the modified authorization response message to theacquirer computer 310. - In step S418, after the
acquirer computer 310 receives the authorization response message, theacquirer computer 310 may transmit the authorization response message to thePOS terminal 306. - At the end of the day or at some other predetermined interval of time, a clearing and settlement process between the
issuer computer 314, thepayment processing network 312, and theacquirer computer 310 may occur. In the clearing and settlement process, account information and token exchanges that are similar to those in the above-described authorization processing steps can occur. - Subsequent transactions using different transactable payment tokens using the same payment device may use the same non-transactable payment account identifier.
- As shown above, because the non-transactable payment account identifier passes through a number of entities in the payments system, each of those entities may retrieve, store, analyze, and process the transaction data associated with the non-transactable payment account identifier. This is the case, even though different payment tokens are used for different transactions conducted with the same underlying account or payment device.
- Embodiments of the invention have a number of advantages. For example, the non-transactable payment account identifier allows merchants to track consumer spending habits, analyze fraud/risk, provide transaction feeds to third party applications, etc. without requiring sensitive payment account information, such as a PAN. Thus, tokens may be used to make a consumer's payment account information more secure without interfering with a merchant's programs. Instead of tracking a payment account by several digital wallet-specific tokens, potentially leading to multiple detached records for one consumer, the merchant (or other entity) may be able to aggregate all token spending records for one payment account via the non-transactable payment account identifier.
-
FIG. 5 is a high level block diagram of a computer system that may be used to implement any of the entities or components described above. The subsystems shown inFIG. 5 are interconnected via asystem bus 500. Additional subsystems include aprinter 508,keyboard 516, fixeddisk 518, and monitor 512, which is coupled todisplay adapter 510. Peripherals and input/output (I/O) devices, which couple to I/O controller 502, can be connected to the computer system by any number of means known in the art, such as a serial port. For example,serial port 514 orexternal interface 520 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection viasystem bus 300 allows thecentral processor 506 to communicate with each subsystem and to control the execution of instructions fromsystem memory 504 or the fixeddisk 518, as well as the exchange of information between subsystems. Thesystem memory 504 and/or the fixed disk may embody a computer-readable medium. - As described, the inventive service may involve implementing one or more functions, processes, operations or method steps. In some embodiments, the functions, processes, operations or method steps may be implemented as a result of the execution of a set of instructions or software code by a suitably-programmed computing device, microprocessor, data processor, or the like. The set of instructions or software code may be stored in a memory or other form of data storage element which is accessed by the computing device, microprocessor, etc. In other embodiments, the functions, processes, operations or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.
- Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
- While certain exemplary embodiments have been described in detail and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not intended to be restrictive of the broad invention, and that this invention is not to be limited to the specific arrangements and constructions shown and described, since various other modifications may occur to those with ordinary skill in the art.
- As used herein, the use of “a”, “an” or “the” is intended to mean “at least one”, unless specifically indicated to the contrary.
Claims (20)
1.-20. (canceled)
21. A method comprising:
receiving, by a computer, a request comprising a non-transactable payment account identifier from an entity of one or more entities;
determining, by the computer, information associated with the non-transactable payment account identifier; and
transmitting, by the computer, the information associated with the non-transactable payment account identifier to the entity.
22. The method of claim 21 , wherein the non-transactable payment account identifier is formatted as a primary account number.
23. The method of claim 21 , wherein the non-transactable payment account identifier is static over time and over any number of transactions.
24. The method of claim 21 , wherein the one or more entities comprises a payment processing network configured to process credit and debit card transactions.
25. The method of claim 21 , wherein the request comprises a token associated with the non-transactable payment account identifier.
26. The method of claim 21 , wherein the request is an authorization request message, and wherein the entity is an acquirer computer.
27. The method of claim 21 , wherein the information associated with the non-transactable payment account identifier includes a primary account number.
28. A method comprising:
receiving a request comprising a primary account identifier from a token requestor computer;
determining a transactable payment token and a non-transactable payment account identifier associated with the primary account identifier; and
transmitting the transactable payment token and the non-transactable payment account identifier to the token requestor computer.
29. The method of claim 28 , wherein the non-transactable payment account identifier is static over time and over any number of transactions.
30. The method of claim 28 , wherein the non-transactable payment account identifier is formatted as a primary account number.
31. The method of claim 28 , further comprising:
associating and storing the primary account identifier and the non-transactable payment account identifier in a database.
32. The method of claim 28 , wherein the non-transactable payment account identifier is mathematically derived from the primary account identifier.
33. The method of claim 28 , wherein the token requestor computer is a mobile device operated by a user.
34. A computer comprising:
a processor; and
a non-transitory computer readable medium comprising code, executable by the processor for implementing a method comprising:
receiving a request comprising a primary account identifier from a token requestor computer,
determining a transactable payment token and a non-transactable payment account identifier associated with the primary account identifier; and
transmitting the transactable payment token and the non-transactable payment account identifier to the token requestor computer.
35. The computer of claim 34 , wherein the non-transactable payment account identifier is static over time and over any number of transactions.
36. The computer of claim 34 , wherein the non-transactable payment account identifier is formatted as a primary account number.
37. The computer of claim 34 , wherein the method further comprises:
associating and storing the primary account identifier and the non-transactable payment account identifier in a database.
38. The computer of claim 34 , wherein the non-transactable payment account identifier is mathematically derived from the primary account identifier.
39. The method of claim 34 , wherein the token requestor computer is a mobile device operated by a user.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/293,488 US20190197552A1 (en) | 2014-01-14 | 2019-03-05 | Payment account identifier system |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201461927381P | 2014-01-14 | 2014-01-14 | |
US14/597,072 US9846878B2 (en) | 2014-01-14 | 2015-01-14 | Payment account identifier system |
US15/814,994 US10062079B2 (en) | 2014-01-14 | 2017-11-16 | Payment account identifier system |
US16/052,354 US10269018B2 (en) | 2014-01-14 | 2018-08-01 | Payment account identifier system |
US16/293,488 US20190197552A1 (en) | 2014-01-14 | 2019-03-05 | Payment account identifier system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/052,354 Continuation US10269018B2 (en) | 2014-01-14 | 2018-08-01 | Payment account identifier system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20190197552A1 true US20190197552A1 (en) | 2019-06-27 |
Family
ID=53521733
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/597,072 Active 2036-02-28 US9846878B2 (en) | 2014-01-14 | 2015-01-14 | Payment account identifier system |
US15/814,994 Active US10062079B2 (en) | 2014-01-14 | 2017-11-16 | Payment account identifier system |
US16/052,354 Active US10269018B2 (en) | 2014-01-14 | 2018-08-01 | Payment account identifier system |
US16/293,488 Abandoned US20190197552A1 (en) | 2014-01-14 | 2019-03-05 | Payment account identifier system |
Family Applications Before (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/597,072 Active 2036-02-28 US9846878B2 (en) | 2014-01-14 | 2015-01-14 | Payment account identifier system |
US15/814,994 Active US10062079B2 (en) | 2014-01-14 | 2017-11-16 | Payment account identifier system |
US16/052,354 Active US10269018B2 (en) | 2014-01-14 | 2018-08-01 | Payment account identifier system |
Country Status (1)
Country | Link |
---|---|
US (4) | US9846878B2 (en) |
Families Citing this family (211)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140019352A1 (en) | 2011-02-22 | 2014-01-16 | Visa International Service Association | Multi-purpose virtual card transaction apparatuses, methods and systems |
US8762263B2 (en) | 2005-09-06 | 2014-06-24 | Visa U.S.A. Inc. | System and method for secured account numbers in proximity devices |
US7739169B2 (en) | 2007-06-25 | 2010-06-15 | Visa U.S.A. Inc. | Restricting access to compromised account information |
US7937324B2 (en) | 2007-09-13 | 2011-05-03 | Visa U.S.A. Inc. | Account permanence |
US8219489B2 (en) | 2008-07-29 | 2012-07-10 | Visa U.S.A. Inc. | Transaction processing using a global unique identifier |
US20100114768A1 (en) | 2008-10-31 | 2010-05-06 | Wachovia Corporation | Payment vehicle with on and off function |
US10867298B1 (en) | 2008-10-31 | 2020-12-15 | Wells Fargo Bank, N.A. | Payment vehicle with on and off function |
US9715681B2 (en) | 2009-04-28 | 2017-07-25 | Visa International Service Association | Verification of portable consumer devices |
US9038886B2 (en) | 2009-05-15 | 2015-05-26 | Visa International Service Association | Verification of portable consumer devices |
US10846683B2 (en) | 2009-05-15 | 2020-11-24 | Visa International Service Association | Integration of verification tokens with mobile communication devices |
US9105027B2 (en) | 2009-05-15 | 2015-08-11 | Visa International Service Association | Verification of portable consumer device for secure services |
US8534564B2 (en) | 2009-05-15 | 2013-09-17 | Ayman Hammad | Integration of verification tokens with mobile communication devices |
US8893967B2 (en) | 2009-05-15 | 2014-11-25 | Visa International Service Association | Secure Communication of payment information to merchants using a verification token |
US10140598B2 (en) | 2009-05-20 | 2018-11-27 | Visa International Service Association | Device including encrypted data for expiration date and verification value creation |
BR112012017000A2 (en) | 2010-01-12 | 2016-04-05 | Visa Int Service Ass | method |
US9245267B2 (en) | 2010-03-03 | 2016-01-26 | Visa International Service Association | Portable account number for consumer payment account |
US8615709B2 (en) | 2010-04-29 | 2013-12-24 | Monotype Imaging Inc. | Initiating font subsets |
US9342832B2 (en) | 2010-08-12 | 2016-05-17 | Visa International Service Association | Securing external systems with account token substitution |
US10586227B2 (en) | 2011-02-16 | 2020-03-10 | Visa International Service Association | Snap mobile payment apparatuses, methods and systems |
CN103765453B (en) | 2011-02-16 | 2018-08-14 | 维萨国际服务协会 | Snap mobile payment device, method and system |
SG193510A1 (en) | 2011-02-22 | 2013-10-30 | Visa Int Service Ass | Universal electronic payment apparatuses, methods and systems |
CN103503010B (en) | 2011-03-04 | 2017-12-29 | 维萨国际服务协会 | Ability to pay is bound to the safety element of computer |
WO2012142045A2 (en) | 2011-04-11 | 2012-10-18 | Visa International Service Association | Multiple tokenization for authentication |
US9582598B2 (en) | 2011-07-05 | 2017-02-28 | Visa International Service Association | Hybrid applications utilizing distributed models and views apparatuses, methods and systems |
US10121129B2 (en) | 2011-07-05 | 2018-11-06 | Visa International Service Association | Electronic wallet checkout platform apparatuses, methods and systems |
US9355393B2 (en) | 2011-08-18 | 2016-05-31 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US9704155B2 (en) | 2011-07-29 | 2017-07-11 | Visa International Service Association | Passing payment tokens through an hop/sop |
US10242358B2 (en) | 2011-08-18 | 2019-03-26 | Visa International Service Association | Remote decoupled application persistent state apparatuses, methods and systems |
US10825001B2 (en) | 2011-08-18 | 2020-11-03 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US9710807B2 (en) | 2011-08-18 | 2017-07-18 | Visa International Service Association | Third-party value added wallet features and interfaces apparatuses, methods and systems |
US10223730B2 (en) | 2011-09-23 | 2019-03-05 | Visa International Service Association | E-wallet store injection search apparatuses, methods and systems |
US11354723B2 (en) | 2011-09-23 | 2022-06-07 | Visa International Service Association | Smart shopping cart with E-wallet store injection search |
US10223710B2 (en) | 2013-01-04 | 2019-03-05 | Visa International Service Association | Wearable intelligent vision device apparatuses, methods and systems |
EP3770839A1 (en) | 2012-01-05 | 2021-01-27 | Visa International Service Association | Data protection with translation |
US9830595B2 (en) | 2012-01-26 | 2017-11-28 | Visa International Service Association | System and method of providing tokenization as a service |
AU2013214801B2 (en) | 2012-02-02 | 2018-06-21 | Visa International Service Association | Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems |
US20130215126A1 (en) * | 2012-02-17 | 2013-08-22 | Monotype Imaging Inc. | Managing Font Distribution |
US10282724B2 (en) | 2012-03-06 | 2019-05-07 | Visa International Service Association | Security system incorporating mobile device |
US20130297501A1 (en) | 2012-05-04 | 2013-11-07 | Justin Monk | System and method for local data conversion |
US9524501B2 (en) | 2012-06-06 | 2016-12-20 | Visa International Service Association | Method and system for correlating diverse transaction data |
US9547769B2 (en) | 2012-07-03 | 2017-01-17 | Visa International Service Association | Data protection hub |
US9256871B2 (en) | 2012-07-26 | 2016-02-09 | Visa U.S.A. Inc. | Configurable payment tokens |
US9665722B2 (en) | 2012-08-10 | 2017-05-30 | Visa International Service Association | Privacy firewall |
AU2013315510B2 (en) | 2012-09-11 | 2019-08-22 | Visa International Service Association | Cloud-based Virtual Wallet NFC Apparatuses, methods and systems |
US10176478B2 (en) | 2012-10-23 | 2019-01-08 | Visa International Service Association | Transaction initiation determination system utilizing transaction data elements |
US9911118B2 (en) | 2012-11-21 | 2018-03-06 | Visa International Service Association | Device pairing via trusted intermediary |
US10304047B2 (en) | 2012-12-07 | 2019-05-28 | Visa International Service Association | Token generating component |
US9741051B2 (en) | 2013-01-02 | 2017-08-22 | Visa International Service Association | Tokenization and third-party interaction |
US10740731B2 (en) | 2013-01-02 | 2020-08-11 | Visa International Service Association | Third party settlement |
US11055710B2 (en) | 2013-05-02 | 2021-07-06 | Visa International Service Association | Systems and methods for verifying and processing transactions using virtual currency |
SG10202008740YA (en) | 2013-05-15 | 2020-10-29 | Visa Int Service Ass | Mobile tokenization hub |
US10878422B2 (en) | 2013-06-17 | 2020-12-29 | Visa International Service Association | System and method using merchant token |
US10489852B2 (en) * | 2013-07-02 | 2019-11-26 | Yodlee, Inc. | Financial account authentication |
CN105874495B (en) | 2013-07-24 | 2021-08-10 | 维萨国际服务协会 | System and method for ensuring data transfer risk using tokens |
AP2016009010A0 (en) | 2013-07-26 | 2016-01-31 | Visa Int Service Ass | Provisioning payment credentials to a consumer |
SG10201801086RA (en) | 2013-08-08 | 2018-03-28 | Visa Int Service Ass | Methods and systems for provisioning mobile devices with payment credentials |
US10496986B2 (en) | 2013-08-08 | 2019-12-03 | Visa International Service Association | Multi-network tokenization processing |
AU2014331673B2 (en) | 2013-10-11 | 2018-05-17 | Mastercard International Incorporated | Network token system |
US9978094B2 (en) | 2013-10-11 | 2018-05-22 | Visa International Service Association | Tokenization revocation list |
US10515358B2 (en) | 2013-10-18 | 2019-12-24 | Visa International Service Association | Contextual transaction token methods and systems |
US10489779B2 (en) | 2013-10-21 | 2019-11-26 | Visa International Service Association | Multi-network token bin routing with defined verification parameters |
US10366387B2 (en) | 2013-10-29 | 2019-07-30 | Visa International Service Association | Digital wallet system and method |
RU2019111186A (en) | 2013-12-19 | 2019-05-07 | Виза Интернэшнл Сервис Ассосиэйшн | METHODS AND SYSTEMS OF CLOUD TRANSACTIONS |
US9922322B2 (en) | 2013-12-19 | 2018-03-20 | Visa International Service Association | Cloud-based transactions with magnetic secure transmission |
US10433128B2 (en) | 2014-01-07 | 2019-10-01 | Visa International Service Association | Methods and systems for provisioning multiple devices |
US10026087B2 (en) | 2014-04-08 | 2018-07-17 | Visa International Service Association | Data passed in an interaction |
US9942043B2 (en) * | 2014-04-23 | 2018-04-10 | Visa International Service Association | Token security on a communication device |
SG11201608973TA (en) | 2014-05-01 | 2016-11-29 | Visa Int Service Ass | Data verification using access device |
SG11201609216YA (en) | 2014-05-05 | 2016-12-29 | Visa Int Service Ass | System and method for token domain control |
US8990121B1 (en) | 2014-05-08 | 2015-03-24 | Square, Inc. | Establishment of a secure session between a card reader and a mobile device |
WO2015179637A1 (en) | 2014-05-21 | 2015-11-26 | Visa International Service Association | Offline authentication |
US11017384B2 (en) * | 2014-05-29 | 2021-05-25 | Apple Inc. | Apparatuses and methods for using a primary user device to provision credentials onto a secondary user device |
US20150348024A1 (en) * | 2014-06-02 | 2015-12-03 | American Express Travel Related Services Company, Inc. | Systems and methods for provisioning transaction data to mobile communications devices |
US11023890B2 (en) | 2014-06-05 | 2021-06-01 | Visa International Service Association | Identification and verification for provisioning mobile application |
US9780953B2 (en) | 2014-07-23 | 2017-10-03 | Visa International Service Association | Systems and methods for secure detokenization |
US10484345B2 (en) | 2014-07-31 | 2019-11-19 | Visa International Service Association | System and method for identity verification across mobile applications |
US9775029B2 (en) | 2014-08-22 | 2017-09-26 | Visa International Service Association | Embedding cloud-based functionalities in a communication device |
US10140615B2 (en) | 2014-09-22 | 2018-11-27 | Visa International Service Association | Secure mobile device credential provisioning using risk decision non-overrides |
CN111866873B (en) | 2014-09-26 | 2023-09-05 | 维萨国际服务协会 | Remote server encrypted data storage system and method |
US11257074B2 (en) | 2014-09-29 | 2022-02-22 | Visa International Service Association | Transaction risk based token |
US10015147B2 (en) | 2014-10-22 | 2018-07-03 | Visa International Service Association | Token enrollment system and method |
GB201419016D0 (en) | 2014-10-24 | 2014-12-10 | Visa Europe Ltd | Transaction Messaging |
US10325261B2 (en) * | 2014-11-25 | 2019-06-18 | Visa International Service Association | Systems communications with non-sensitive identifiers |
WO2016086154A1 (en) | 2014-11-26 | 2016-06-02 | Visa International Service Association | Tokenization request via access device |
SG11201703526VA (en) | 2014-12-12 | 2017-05-30 | Visa Int Service Ass | Provisioning platform for machine-to-machine devices |
US10257185B2 (en) | 2014-12-12 | 2019-04-09 | Visa International Service Association | Automated access data provisioning |
SG10201500276VA (en) * | 2015-01-14 | 2016-08-30 | Mastercard Asia Pacific Pte Ltd | Method and system for making a secure payment transaction |
US10096009B2 (en) | 2015-01-20 | 2018-10-09 | Visa International Service Association | Secure payment processing using authorization request |
US20160217464A1 (en) * | 2015-01-27 | 2016-07-28 | Paypal, Inc. | Mobile transaction devices enabling unique identifiers for facilitating credit checks |
US11250391B2 (en) | 2015-01-30 | 2022-02-15 | Visa International Service Association | Token check offline |
US10296885B2 (en) * | 2015-03-06 | 2019-05-21 | Mastercard International Incorporated | Extended-length payment account issuer identification numbers |
US10164996B2 (en) * | 2015-03-12 | 2018-12-25 | Visa International Service Association | Methods and systems for providing a low value token buffer |
US11429975B1 (en) | 2015-03-27 | 2022-08-30 | Wells Fargo Bank, N.A. | Token management system |
SG10201908338TA (en) | 2015-04-10 | 2019-10-30 | Visa Int Service Ass | Browser integration with cryptogram |
CN106156648B (en) * | 2015-04-13 | 2020-09-04 | 腾讯科技(深圳)有限公司 | Sensitive operation processing method and device |
US9998978B2 (en) | 2015-04-16 | 2018-06-12 | Visa International Service Association | Systems and methods for processing dormant virtual access devices |
US10115215B2 (en) | 2015-04-17 | 2018-10-30 | Monotype Imaging Inc. | Pairing fonts for presentation |
US10152714B2 (en) * | 2015-04-29 | 2018-12-11 | Capital One Services, LLP | System to automatically restore payment purchasing power |
US10552834B2 (en) | 2015-04-30 | 2020-02-04 | Visa International Service Association | Tokenization capable authentication framework |
EP3308321B1 (en) * | 2015-06-09 | 2021-08-04 | Datex Inc. | Peripheral bus security interface and method |
EP3859637A1 (en) * | 2015-07-17 | 2021-08-04 | CardinalCommerce Corporation | System and method for tokenization |
CN105046486A (en) * | 2015-07-17 | 2015-11-11 | 百度在线网络技术(北京)有限公司 | NFC-based mobile payment method and device |
US11537262B1 (en) | 2015-07-21 | 2022-12-27 | Monotype Imaging Inc. | Using attributes for font recommendations |
US11170364B1 (en) | 2015-07-31 | 2021-11-09 | Wells Fargo Bank, N.A. | Connected payment card systems and methods |
CN106470184B (en) * | 2015-08-14 | 2020-06-26 | 阿里巴巴集团控股有限公司 | Security authentication method, device and system |
US11308483B2 (en) | 2015-08-25 | 2022-04-19 | Paypal, Inc. | Token service provider for electronic/mobile commerce transactions |
US11308485B2 (en) | 2016-07-15 | 2022-04-19 | Paypal, Inc. | Processing a transaction using electronic tokens |
US10607215B2 (en) * | 2015-09-30 | 2020-03-31 | Bank Of America Corporation | Account tokenization for virtual currency resources |
US10453059B2 (en) | 2015-09-30 | 2019-10-22 | Bank Of America Corporation | Non-intrusive geo-location determination associated with transaction authorization |
AU2016337614A1 (en) | 2015-10-15 | 2018-03-15 | Visa International Service Association | Instant token issuance system |
EP3156957A1 (en) * | 2015-10-16 | 2017-04-19 | Mastercard International Incorporated | System and method of enabling asset leasing on a token enabled payment card |
US10943216B2 (en) * | 2015-10-27 | 2021-03-09 | Mastercard International Incorporated | Systems and methods for updating stored cardholder account data |
US20170124563A1 (en) * | 2015-10-30 | 2017-05-04 | Ncr Corporation | Account identifier used for crediting |
US10706400B1 (en) * | 2015-11-19 | 2020-07-07 | Wells Fargo Bank, N.A. | Systems and methods for financial operations performed at a contactless ATM |
US10535047B1 (en) * | 2015-11-19 | 2020-01-14 | Wells Fargo Bank N.A. | Systems and methods for financial operations performed at a contactless ATM |
SG11201803495VA (en) | 2015-12-04 | 2018-05-30 | Visa Int Service Ass | Unique code for token verification |
US11593780B1 (en) | 2015-12-10 | 2023-02-28 | Block, Inc. | Creation and validation of a secure list of security certificates |
CN108476227B (en) | 2016-01-07 | 2021-04-20 | 维萨国际服务协会 | System and method for device push provisioning |
US11080696B2 (en) | 2016-02-01 | 2021-08-03 | Visa International Service Association | Systems and methods for code display and use |
US11501288B2 (en) | 2016-02-09 | 2022-11-15 | Visa International Service Association | Resource provider account token provisioning and processing |
WO2017139772A1 (en) * | 2016-02-12 | 2017-08-17 | Visa International Service Association | Authentication systems and methods using location matching |
US20170243181A1 (en) * | 2016-02-24 | 2017-08-24 | Mastercard International Incorporated | Methods and systems for replacing a primary account number (pan) with a unique identfier |
US10579999B2 (en) * | 2016-03-14 | 2020-03-03 | Facebook, Inc. | Network payment tokenization for processing payment transactions |
US20170270519A1 (en) * | 2016-03-17 | 2017-09-21 | Thomas Purves | Enabling a secure card on file option for electronic merchant applications |
US10313321B2 (en) | 2016-04-07 | 2019-06-04 | Visa International Service Association | Tokenization of co-network accounts |
US11250432B2 (en) * | 2016-04-13 | 2022-02-15 | America Express Travel Related Services Company, Inc. | Systems and methods for reducing fraud risk for a primary transaction account |
WO2017184121A1 (en) | 2016-04-19 | 2017-10-26 | Visa International Service Association | Systems and methods for performing push transactions |
US20170316402A1 (en) * | 2016-04-28 | 2017-11-02 | Mastercard International Incorporated | System for mapping a temporary account identifier to a compromised account identifier |
US11250424B2 (en) | 2016-05-19 | 2022-02-15 | Visa International Service Association | Systems and methods for creating subtokens using primary tokens |
EP3466017B1 (en) | 2016-06-03 | 2021-05-19 | Visa International Service Association | Subtoken management system for connected devices |
US10755267B2 (en) * | 2016-06-08 | 2020-08-25 | American Express Travel Related Services Company, Inc. | Systems and methods for a merchant-specific payment token |
WO2017218485A1 (en) * | 2016-06-15 | 2017-12-21 | Mastercard International Incorporated | Systems and methods for bridging transactions between eft payment networks and payment card networks |
US11068899B2 (en) | 2016-06-17 | 2021-07-20 | Visa International Service Association | Token aggregation for multi-party transactions |
CN115187242A (en) | 2016-06-24 | 2022-10-14 | 维萨国际服务协会 | Unique token authentication verification value |
US12130937B1 (en) | 2016-07-01 | 2024-10-29 | Wells Fargo Bank, N.A. | Control tower for prospective transactions |
US11935020B1 (en) | 2016-07-01 | 2024-03-19 | Wells Fargo Bank, N.A. | Control tower for prospective transactions |
US11386223B1 (en) | 2016-07-01 | 2022-07-12 | Wells Fargo Bank, N.A. | Access control tower |
US10992679B1 (en) | 2016-07-01 | 2021-04-27 | Wells Fargo Bank, N.A. | Access control tower |
US11615402B1 (en) | 2016-07-01 | 2023-03-28 | Wells Fargo Bank, N.A. | Access control tower |
US11886611B1 (en) | 2016-07-01 | 2024-01-30 | Wells Fargo Bank, N.A. | Control tower for virtual rewards currency |
SG11201808998RA (en) | 2016-07-11 | 2018-11-29 | Visa Int Service Ass | Encryption key exchange process using access device |
WO2018017068A1 (en) | 2016-07-19 | 2018-01-25 | Visa International Service Association | Method of distributing tokens and managing token relationships |
CA3032284A1 (en) * | 2016-07-29 | 2018-02-01 | Benjamin HAMMEL | Integrated credential data management techniques |
US10509779B2 (en) | 2016-09-14 | 2019-12-17 | Visa International Service Association | Self-cleaning token vault |
US10803461B2 (en) | 2016-09-30 | 2020-10-13 | Square, Inc. | Fraud detection in portable payment readers |
US9940612B1 (en) | 2016-09-30 | 2018-04-10 | Square, Inc. | Fraud detection in portable payment readers |
US10423965B2 (en) * | 2016-10-17 | 2019-09-24 | Mufg Union Bank, N.A. | Method and apparatus for establishing and maintaining PCI DSS compliant transaction flows for banking entities leveraging non-EMV tokens |
US10438195B2 (en) * | 2016-10-28 | 2019-10-08 | Visa International Service Association | Token creation and provisioning |
AU2017364118A1 (en) | 2016-11-28 | 2019-05-02 | Visa International Service Association | Access identifier provisioning to application |
US10404703B1 (en) | 2016-12-02 | 2019-09-03 | Worldpay, Llc | Systems and methods for third-party interoperability in secure network transactions using tokenized data |
WO2018112546A1 (en) * | 2016-12-21 | 2018-06-28 | Safepay Australia Pty Ltd | A transaction processing system and method |
US11315137B1 (en) | 2016-12-29 | 2022-04-26 | Wells Fargo Bank, N.A. | Pay with points virtual card |
US11423395B1 (en) | 2016-12-29 | 2022-08-23 | Wells Fargo Bank, N.A. | Pay with points virtual card |
US10762495B2 (en) | 2016-12-30 | 2020-09-01 | Square, Inc. | Third-party access to secure hardware |
US10783517B2 (en) * | 2016-12-30 | 2020-09-22 | Square, Inc. | Third-party access to secure hardware |
US10608882B2 (en) * | 2017-02-16 | 2020-03-31 | International Business Machines Corporation | Token-based lightweight approach to manage the active-passive system topology in a distributed computing environment |
US10721226B1 (en) | 2017-03-10 | 2020-07-21 | Wells Fargo Bank, N.A. | User-level token for user authentication via a user device |
US11763303B1 (en) * | 2017-03-10 | 2023-09-19 | Wells Fargo Bank, N.A. | Identity management service via a user-level token |
US10915899B2 (en) | 2017-03-17 | 2021-02-09 | Visa International Service Association | Replacing token on a multi-token user device |
US11556936B1 (en) | 2017-04-25 | 2023-01-17 | Wells Fargo Bank, N.A. | System and method for card control |
US10902418B2 (en) | 2017-05-02 | 2021-01-26 | Visa International Service Association | System and method using interaction token |
US11494765B2 (en) | 2017-05-11 | 2022-11-08 | Visa International Service Association | Secure remote transaction system using mobile devices |
US10762520B2 (en) | 2017-05-31 | 2020-09-01 | Paypal, Inc. | Encryption of digital incentive tokens within images |
US10893306B2 (en) * | 2017-05-31 | 2021-01-12 | Paypal, Inc. | Digital encryption of tokens within videos |
US11062388B1 (en) | 2017-07-06 | 2021-07-13 | Wells Fargo Bank, N.A | Data control tower |
US10491389B2 (en) | 2017-07-14 | 2019-11-26 | Visa International Service Association | Token provisioning utilizing a secure authentication system |
US11334750B2 (en) | 2017-09-07 | 2022-05-17 | Monotype Imaging Inc. | Using attributes for predicting imagery performance |
US11151547B2 (en) | 2017-09-20 | 2021-10-19 | Paypal, Inc. | Using a consumer digital wallet as a payment method in a merchant digital wallet |
US10909429B2 (en) | 2017-09-27 | 2021-02-02 | Monotype Imaging Inc. | Using attributes for identifying imagery for selection |
US11657602B2 (en) | 2017-10-30 | 2023-05-23 | Monotype Imaging Inc. | Font identification from imagery |
US11188887B1 (en) | 2017-11-20 | 2021-11-30 | Wells Fargo Bank, N.A. | Systems and methods for payment information access management |
US11144945B2 (en) * | 2017-12-07 | 2021-10-12 | Visa International Service Association | Method, system, and computer program product for communicating loyalty program identification data |
EP3499440A1 (en) * | 2017-12-18 | 2019-06-19 | Mastercard International Incorporated | Authentication of goods |
EP3503001A1 (en) | 2017-12-20 | 2019-06-26 | Mastercard International Incorporated | Authentication of goods |
US11855971B2 (en) * | 2018-01-11 | 2023-12-26 | Visa International Service Association | Offline authorization of interactions and controlled tasks |
US20190228410A1 (en) * | 2018-01-24 | 2019-07-25 | Mastercard International Incorporated | Method and system for generating and using contextual cryptograms for proximity and e-commerce payment |
SG11202008451RA (en) | 2018-03-07 | 2020-09-29 | Visa Int Service Ass | Secure remote token release with online authentication |
GB201805933D0 (en) * | 2018-04-10 | 2018-05-23 | Visa Europe Ltd | Electronic Transaction System |
US11025575B2 (en) * | 2018-06-12 | 2021-06-01 | Oracle Financial Services Software Limited | Message recognition system and method configurable to define new message formats |
US11256789B2 (en) | 2018-06-18 | 2022-02-22 | Visa International Service Association | Recurring token transactions |
CN112740207A (en) | 2018-08-22 | 2021-04-30 | 维萨国际服务协会 | Method and system for token provisioning and processing |
CN112805737A (en) | 2018-10-08 | 2021-05-14 | 维萨国际服务协会 | Techniques for token proximity transactions |
US20200143381A1 (en) * | 2018-11-06 | 2020-05-07 | Paypal, Inc. | System and Method for Obtaining a Temporary CVV using Tokenization Rails |
WO2020102484A1 (en) | 2018-11-14 | 2020-05-22 | Visa International Service Association | Cloud token provisioning of multiple tokens |
US20200193415A1 (en) * | 2018-12-14 | 2020-06-18 | Jpmorgan Chase Bank, N.A. | Systems and methods for using integrated pay-on-demand virtual cards |
US11853995B2 (en) * | 2019-01-22 | 2023-12-26 | Vaughn Dabney | Systems and methods for processing encoded symbols to facilitate secured communication between database systems of two entities and to update database tuples associated with the database systems |
US11853997B2 (en) | 2019-02-27 | 2023-12-26 | International Business Machines Corporation | Using quick response (QR) codes to collect recurring payments |
US10623275B1 (en) | 2019-02-27 | 2020-04-14 | Bank Of America Corporation | Network operational decision engine |
US10963888B2 (en) | 2019-04-10 | 2021-03-30 | Advanced New Technologies Co., Ltd. | Payment complaint method, device, server and readable storage medium |
CN110264210B (en) * | 2019-05-06 | 2023-08-08 | 创新先进技术有限公司 | Account correctness detection method and device |
CN113518990A (en) | 2019-05-17 | 2021-10-19 | 维萨国际服务协会 | Virtual access credential interaction system and method |
WO2020251563A1 (en) * | 2019-06-12 | 2020-12-17 | Visa International Service Association | System and method for authorizing a transaction |
CN113711257A (en) * | 2019-06-26 | 2021-11-26 | 维萨国际服务协会 | Methods, systems, and computer program products for processing payment transactions via an agent guarantor |
US11144919B2 (en) * | 2019-10-17 | 2021-10-12 | Visa International Service Association | System, method, and computer program product for guaranteeing a payment authorization response |
US20230342776A1 (en) * | 2019-10-28 | 2023-10-26 | Visa International Service Association | Combined token and value assessment processing |
US12217243B1 (en) * | 2019-11-27 | 2025-02-04 | Worldpay, Llc | Methods and systems for securely facilitating cross-platform token compatibility via multi-tokenization |
WO2021119495A1 (en) | 2019-12-13 | 2021-06-17 | Visa International Service Association | Token management system and method |
WO2021222734A1 (en) * | 2020-05-01 | 2021-11-04 | Visa International Service Association | Digital tag |
US11625723B2 (en) * | 2020-05-28 | 2023-04-11 | Paypal, Inc. | Risk assessment through device data using machine learning-based network |
US10992606B1 (en) | 2020-09-04 | 2021-04-27 | Wells Fargo Bank, N.A. | Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets |
EP4252169A4 (en) * | 2020-11-24 | 2023-12-20 | Visa International Service Association | SYSTEMS, METHODS AND COMPUTER PROGRAM PRODUCTS FOR DEVICE AUTHENTICATION |
US20220172198A1 (en) * | 2020-11-28 | 2022-06-02 | International Business Machines Corporation | Real-time blockchain settlement network |
US11546338B1 (en) | 2021-01-05 | 2023-01-03 | Wells Fargo Bank, N.A. | Digital account controls portal and protocols for federated and non-federated systems and devices |
US12141800B2 (en) | 2021-02-12 | 2024-11-12 | Visa International Service Association | Interaction account tokenization system and method |
US20220327436A1 (en) * | 2021-04-09 | 2022-10-13 | International Business Machines Corporation | Processing attendee information for a virtual event |
CN117480515A (en) * | 2021-05-26 | 2024-01-30 | 维萨国际服务协会 | Systems, methods, and computer program products for an account-to-account transaction network |
US20230153795A1 (en) * | 2021-11-17 | 2023-05-18 | Jpmorgan Chase Bank, N.A. | Systems and methods for use and management of issuer provided payment tokens |
US12045821B1 (en) * | 2022-03-30 | 2024-07-23 | Amazon Technologies, Inc. | System to facilitate payment processing |
US12155641B1 (en) | 2022-04-15 | 2024-11-26 | Wells Fargo Bank, N.A. | Network access tokens and meta-application programming interfaces for enhanced inter-enterprise system data promulgation and profiling |
US20240330912A1 (en) * | 2023-03-29 | 2024-10-03 | The Clearing House Payments Company | Secure token exchange and controls and interfaces therefor |
US20250063045A1 (en) * | 2023-08-15 | 2025-02-20 | Citibank, N.A. | Access control for requests to services |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130238455A1 (en) * | 2010-04-09 | 2013-09-12 | Kevin Laracey | Methods and systems for selecting accounts and offers in payment transactions |
US20150112870A1 (en) * | 2013-10-18 | 2015-04-23 | Sekhar Nagasundaram | Contextual transaction token methods and systems |
US20150127547A1 (en) * | 2013-10-11 | 2015-05-07 | Glenn Leon Powell | Network token system |
US20160267466A1 (en) * | 2015-03-13 | 2016-09-15 | Phillip Kumnick | Device with multiple identifiers |
US20180018660A1 (en) * | 2016-07-15 | 2018-01-18 | Paypal, Inc. | Processing a transaction using electronic tokens |
Family Cites Families (425)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5613012A (en) | 1994-11-28 | 1997-03-18 | Smarttouch, Llc. | Tokenless identification system for authorization of electronic transactions and electronic transmissions |
US5781438A (en) | 1995-12-19 | 1998-07-14 | Pitney Bowes Inc. | Token generation process in an open metering system |
US6044360A (en) | 1996-04-16 | 2000-03-28 | Picciallo; Michael J. | Third party credit card |
US5913203A (en) | 1996-10-03 | 1999-06-15 | Jaesent Inc. | System and method for pseudo cash transactions |
US5953710A (en) | 1996-10-09 | 1999-09-14 | Fleming; Stephen S. | Children's credit or debit card system |
GB9624127D0 (en) | 1996-11-20 | 1997-01-08 | British Telecomm | Transaction system |
US5949044A (en) | 1997-06-13 | 1999-09-07 | Walker Asset Management Limited Partnership | Method and apparatus for funds and credit line transfers |
US6163771A (en) | 1997-08-28 | 2000-12-19 | Walker Digital, Llc | Method and device for generating a single-use financial account number |
US7177835B1 (en) | 1997-08-28 | 2007-02-13 | Walker Digital, Llc | Method and device for generating a single-use financial account number |
US6000832A (en) | 1997-09-24 | 1999-12-14 | Microsoft Corporation | Electronic online commerce card with customer generated transaction proxy number for online transactions |
US5883810A (en) | 1997-09-24 | 1999-03-16 | Microsoft Corporation | Electronic online commerce card with transactionproxy number for online transactions |
US6014635A (en) | 1997-12-08 | 2000-01-11 | Shc Direct, Inc. | System and method for providing a discount credit transaction network |
US6385596B1 (en) | 1998-02-06 | 2002-05-07 | Liquid Audio, Inc. | Secure online music distribution system |
US6980670B1 (en) | 1998-02-09 | 2005-12-27 | Indivos Corporation | Biometric tokenless electronic rewards system and method |
US6636833B1 (en) | 1998-03-25 | 2003-10-21 | Obis Patents Ltd. | Credit card system and method |
US6422462B1 (en) | 1998-03-30 | 2002-07-23 | Morris E. Cohen | Apparatus and methods for improved credit cards and credit card transactions |
IL125826A (en) | 1998-08-17 | 2001-05-20 | Ur Jonathan Shem | Method for preventing unauthorized use of credit cards in remote payments and an optional supplemental-code card for use therein |
US8799153B2 (en) | 1998-08-31 | 2014-08-05 | Mastercard International Incorporated | Systems and methods for appending supplemental payment data to a transaction message |
US6327578B1 (en) | 1998-12-29 | 2001-12-04 | International Business Machines Corporation | Four-party credit/debit payment protocol |
US7571139B1 (en) | 1999-02-19 | 2009-08-04 | Giordano Joseph A | System and method for processing financial transactions |
US6227447B1 (en) | 1999-05-10 | 2001-05-08 | First Usa Bank, Na | Cardless payment system |
US7194437B1 (en) | 1999-05-14 | 2007-03-20 | Amazon.Com, Inc. | Computer-based funds transfer system |
US7908216B1 (en) | 1999-07-22 | 2011-03-15 | Visa International Service Association | Internet payment, authentication and loading system using virtual smart card |
WO2001008066A1 (en) | 1999-07-26 | 2001-02-01 | Iprivacy Llc | Electronic purchase of goods over a communication network including physical delivery while securing private and personal information |
US6748367B1 (en) | 1999-09-24 | 2004-06-08 | Joonho John Lee | Method and system for effecting financial transactions over a public network without submission of sensitive information |
WO2001035304A1 (en) | 1999-11-10 | 2001-05-17 | Krasnyansky Serge M | On-line payment system |
WO2001045056A1 (en) | 1999-12-17 | 2001-06-21 | Chantilley Corporation Limited | Secure transaction systems |
US7426750B2 (en) | 2000-02-18 | 2008-09-16 | Verimatrix, Inc. | Network-based content distribution system |
US20010029485A1 (en) | 2000-02-29 | 2001-10-11 | E-Scoring, Inc. | Systems and methods enabling anonymous credit transactions |
TW550477B (en) | 2000-03-01 | 2003-09-01 | Passgate Corp | Method, system and computer readable medium for Web site account and e-commerce management from a central location |
US7865414B2 (en) | 2000-03-01 | 2011-01-04 | Passgate Corporation | Method, system and computer readable medium for web site account and e-commerce management from a central location |
AU2001243473A1 (en) | 2000-03-07 | 2001-09-17 | American Express Travel Related Services Company, Inc. | System for facilitating a transaction |
AU4365801A (en) | 2000-03-15 | 2001-09-24 | Mastercard International Inc | Method and system for secure payments over a computer network |
US20100228668A1 (en) | 2000-04-11 | 2010-09-09 | Hogan Edward J | Method and System for Conducting a Transaction Using a Proximity Device and an Identifier |
US6990470B2 (en) | 2000-04-11 | 2006-01-24 | Mastercard International Incorporated | Method and system for conducting secure payments over a computer network |
US20100223186A1 (en) | 2000-04-11 | 2010-09-02 | Hogan Edward J | Method and System for Conducting Secure Payments |
US7379919B2 (en) | 2000-04-11 | 2008-05-27 | Mastercard International Incorporated | Method and system for conducting secure payments over a computer network |
US7177848B2 (en) | 2000-04-11 | 2007-02-13 | Mastercard International Incorporated | Method and system for conducting secure payments over a computer network without a pseudo or proxy account number |
US20070129955A1 (en) | 2000-04-14 | 2007-06-07 | American Express Travel Related Services Company, Inc. | System and method for issuing and using a loyalty point advance |
CA2406001A1 (en) | 2000-04-14 | 2001-10-25 | American Express Travel Related Services Company, Inc. | A system and method for using loyalty points |
CA2305249A1 (en) | 2000-04-14 | 2001-10-14 | Branko Sarcanin | Virtual safe |
US6592044B1 (en) | 2000-05-15 | 2003-07-15 | Jacob Y. Wong | Anonymous electronic card for generating personal coupons useful in commercial and security transactions |
WO2001092989A2 (en) | 2000-05-26 | 2001-12-06 | Interchecks, Llc | Methods and systems for network based electronic purchasing system |
US6891953B1 (en) | 2000-06-27 | 2005-05-10 | Microsoft Corporation | Method and system for binding enhanced software features to a persona |
US6938019B1 (en) | 2000-08-29 | 2005-08-30 | Uzo Chijioke Chukwuemeka | Method and apparatus for making secure electronic payments |
AU2001286985A1 (en) | 2000-09-01 | 2002-03-13 | Infospace, Inc. | Method and system for facilitating the transfer of funds utilizing a telephonic identifier |
US20020073045A1 (en) | 2000-10-23 | 2002-06-13 | Rubin Aviel D. | Off-line generation of limited-use credit card numbers |
US7996288B1 (en) | 2000-11-15 | 2011-08-09 | Iprivacy, Llc | Method and system for processing recurrent consumer transactions |
US6931382B2 (en) | 2001-01-24 | 2005-08-16 | Cdck Corporation | Payment instrument authorization technique |
GB2372616A (en) | 2001-02-23 | 2002-08-28 | Hewlett Packard Co | Transaction method and apparatus using two part tokens |
US7292999B2 (en) | 2001-03-15 | 2007-11-06 | American Express Travel Related Services Company, Inc. | Online card present transaction |
US7237117B2 (en) | 2001-03-16 | 2007-06-26 | Kenneth P. Weiss | Universal secure registry |
EP1381987A4 (en) | 2001-03-26 | 2010-09-22 | 3M Future Ltd | Transaction authorisation system |
US20020147913A1 (en) | 2001-04-09 | 2002-10-10 | Lun Yip William Wai | Tamper-proof mobile commerce system |
US7650314B1 (en) | 2001-05-25 | 2010-01-19 | American Express Travel Related Services Company, Inc. | System and method for securing a recurrent billing transaction |
US8060448B2 (en) | 2001-05-30 | 2011-11-15 | Jones Thomas C | Late binding tokens |
JP4363800B2 (en) | 2001-06-11 | 2009-11-11 | ソニー株式会社 | Electronic commerce support apparatus, electronic commerce support method, and computer program |
US7805378B2 (en) | 2001-07-10 | 2010-09-28 | American Express Travel Related Servicex Company, Inc. | System and method for encoding information in magnetic stripe format for use in radio frequency identification transactions |
US20060237528A1 (en) | 2001-07-10 | 2006-10-26 | Fred Bishop | Systems and methods for non-traditional payment |
US8737954B2 (en) | 2001-08-21 | 2014-05-27 | Bookit Oy Ajanvarauspalvelu | Managing recurring payments from mobile terminals |
US7444676B1 (en) | 2001-08-29 | 2008-10-28 | Nader Asghari-Kamrani | Direct authentication and authorization system and method for trusted network of financial institutions |
US7103576B2 (en) | 2001-09-21 | 2006-09-05 | First Usa Bank, Na | System for providing cardless payment |
US6901387B2 (en) | 2001-12-07 | 2005-05-31 | General Electric Capital Financial | Electronic purchasing method and apparatus for performing the same |
US7805376B2 (en) | 2002-06-14 | 2010-09-28 | American Express Travel Related Services Company, Inc. | Methods and apparatus for facilitating a transaction |
US7904360B2 (en) | 2002-02-04 | 2011-03-08 | Alexander William EVANS | System and method for verification, authentication, and notification of a transaction |
US7890393B2 (en) | 2002-02-07 | 2011-02-15 | Ebay, Inc. | Method and system for completing a transaction between a customer and a merchant |
AUPS087602A0 (en) | 2002-03-04 | 2002-03-28 | Ong, Yong Kin (Michael) | Electronic fund transfer system |
US20040210498A1 (en) | 2002-03-29 | 2004-10-21 | Bank One, National Association | Method and system for performing purchase and other transactions using tokens with multiple chips |
WO2003083619A2 (en) | 2002-03-29 | 2003-10-09 | Bank One, Delaware, N.A. | System and process for performing purchase transaction using tokens |
US20030191709A1 (en) | 2002-04-03 | 2003-10-09 | Stephen Elston | Distributed payment and loyalty processing for retail and vending |
GB2387253B (en) | 2002-04-03 | 2004-02-18 | Swivel Technologies Ltd | System and method for secure credit and debit card transactions |
US7707120B2 (en) | 2002-04-17 | 2010-04-27 | Visa International Service Association | Mobile account authentication service |
WO2003091849A2 (en) | 2002-04-23 | 2003-11-06 | The Clearing House Service Company L.L.C. | Payment identification code system |
US8412623B2 (en) | 2002-07-15 | 2013-04-02 | Citicorp Credit Services, Inc. | Method and system for a multi-purpose transactional platform |
US7209561B1 (en) | 2002-07-19 | 2007-04-24 | Cybersource Corporation | System and method for generating encryption seed values |
US20040127256A1 (en) | 2002-07-30 | 2004-07-01 | Scott Goldthwaite | Mobile device equipped with a contactless smart card reader/writer |
US7353382B2 (en) | 2002-08-08 | 2008-04-01 | Fujitsu Limited | Security framework and protocol for universal pervasive transactions |
US7801826B2 (en) | 2002-08-08 | 2010-09-21 | Fujitsu Limited | Framework and system for purchasing of goods and services |
US7606560B2 (en) | 2002-08-08 | 2009-10-20 | Fujitsu Limited | Authentication services using mobile device |
US6805287B2 (en) | 2002-09-12 | 2004-10-19 | American Express Travel Related Services Company, Inc. | System and method for converting a stored value card to a credit card |
AU2003296927A1 (en) | 2002-11-05 | 2004-06-07 | Todd Silverstein | Remote purchasing system and method |
GB2396472A (en) | 2002-12-18 | 2004-06-23 | Ncr Int Inc | System for cash withdrawal |
US7827101B2 (en) | 2003-01-10 | 2010-11-02 | First Data Corporation | Payment system clearing for transactions |
TW200412524A (en) | 2003-01-15 | 2004-07-16 | Lee Fung Chi | A small amount paying/receiving system |
US8082210B2 (en) | 2003-04-29 | 2011-12-20 | The Western Union Company | Authentication for online money transfers |
GB0318000D0 (en) | 2003-07-31 | 2003-09-03 | Ncr Int Inc | Mobile applications |
US20050199709A1 (en) | 2003-10-10 | 2005-09-15 | James Linlor | Secure money transfer between hand-held devices |
US7567936B1 (en) | 2003-10-14 | 2009-07-28 | Paradox Technical Solutions Llc | Method and apparatus for handling pseudo identities |
US20050080730A1 (en) | 2003-10-14 | 2005-04-14 | First Data Corporation | System and method for secure account transactions |
US20050108178A1 (en) | 2003-11-17 | 2005-05-19 | Richard York | Order risk determination |
US7543739B2 (en) | 2003-12-17 | 2009-06-09 | Qsecure, Inc. | Automated payment card fraud detection and location |
CN1914895B (en) | 2004-01-20 | 2018-03-09 | 黄金富 | System and method for safe money payment with lock bank computer account by telephone |
US7580898B2 (en) | 2004-03-15 | 2009-08-25 | Qsecure, Inc. | Financial transactions with dynamic personal account numbers |
US7584153B2 (en) | 2004-03-15 | 2009-09-01 | Qsecure, Inc. | Financial transactions with dynamic card verification values |
GB0407369D0 (en) | 2004-03-31 | 2004-05-05 | British Telecomm | Trust tokens |
US20140019352A1 (en) | 2011-02-22 | 2014-01-16 | Visa International Service Association | Multi-purpose virtual card transaction apparatuses, methods and systems |
US20050269401A1 (en) | 2004-06-03 | 2005-12-08 | Tyfone, Inc. | System and method for securing financial transactions |
WO2005119607A2 (en) | 2004-06-03 | 2005-12-15 | Tyfone, Inc. | System and method for securing financial transactions |
US8412837B1 (en) | 2004-07-08 | 2013-04-02 | James A. Roskind | Data privacy |
US7264154B2 (en) | 2004-07-12 | 2007-09-04 | Harris David N | System and method for securing a credit account |
US7287692B1 (en) | 2004-07-28 | 2007-10-30 | Cisco Technology, Inc. | System and method for securing transactions in a contact center environment |
GB0420409D0 (en) | 2004-09-14 | 2004-10-20 | Waterleaf Ltd | Online commercial transaction system and method of operation thereof |
US7051929B2 (en) | 2004-10-18 | 2006-05-30 | Gongling Li | Secure credit card having daily changed security number |
US7548889B2 (en) | 2005-01-24 | 2009-06-16 | Microsoft Corporation | Payment information security for multi-merchant purchasing environment for downloadable products |
US7849020B2 (en) | 2005-04-19 | 2010-12-07 | Microsoft Corporation | Method and apparatus for network transactions |
WO2006113834A2 (en) | 2005-04-19 | 2006-10-26 | Microsoft Corporation | Network commercial transactions |
US20060235795A1 (en) | 2005-04-19 | 2006-10-19 | Microsoft Corporation | Secure network commercial transactions |
US7793851B2 (en) | 2005-05-09 | 2010-09-14 | Dynamics Inc. | Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card |
US20080035738A1 (en) | 2005-05-09 | 2008-02-14 | Mullen Jeffrey D | Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card |
WO2006135779A2 (en) | 2005-06-10 | 2006-12-21 | American Express Travel Related Services Company, Inc. | System and method for mass transit merchant payment |
US8762263B2 (en) | 2005-09-06 | 2014-06-24 | Visa U.S.A. Inc. | System and method for secured account numbers in proximity devices |
US8352376B2 (en) | 2005-10-11 | 2013-01-08 | Amazon Technologies, Inc. | System and method for authorization of transactions |
US8205791B2 (en) | 2005-10-11 | 2012-06-26 | National Payment Card Association | Payment system and methods |
US7853995B2 (en) | 2005-11-18 | 2010-12-14 | Microsoft Corporation | Short-lived certificate authority service |
US20070136193A1 (en) | 2005-12-13 | 2007-06-14 | Bellsouth Intellectual Property Corporation | Methods, transactional cards, and systems using account identifers customized by the account holder |
US8275312B2 (en) | 2005-12-31 | 2012-09-25 | Blaze Mobile, Inc. | Induction triggered transactions using an external NFC device |
US8352323B2 (en) | 2007-11-30 | 2013-01-08 | Blaze Mobile, Inc. | Conducting an online payment transaction using an NFC enabled mobile communication device |
US20070170247A1 (en) | 2006-01-20 | 2007-07-26 | Maury Samuel Friedman | Payment card authentication system and method |
EP1979864A1 (en) | 2006-01-30 | 2008-10-15 | CPNI Inc. | A system and method for authorizing a funds transfer or payment using a phone number |
US8001055B2 (en) | 2006-02-21 | 2011-08-16 | Weiss Kenneth P | Method, system and apparatus for secure access, payment and identification |
US8234220B2 (en) | 2007-02-21 | 2012-07-31 | Weiss Kenneth P | Universal secure registry |
AU2007223334B2 (en) | 2006-03-02 | 2012-07-12 | Visa International Service Association | Method and system for performing two factor authentication in mail order and telephone order transactions |
US8225385B2 (en) | 2006-03-23 | 2012-07-17 | Microsoft Corporation | Multiple security token transactions |
US9065643B2 (en) | 2006-04-05 | 2015-06-23 | Visa U.S.A. Inc. | System and method for account identifier obfuscation |
US7818264B2 (en) | 2006-06-19 | 2010-10-19 | Visa U.S.A. Inc. | Track data encryption |
US20070245414A1 (en) | 2006-04-14 | 2007-10-18 | Microsoft Corporation | Proxy Authentication and Indirect Certificate Chaining |
WO2007148234A2 (en) | 2006-04-26 | 2007-12-27 | Yosef Shaked | System and method for authenticating a customer's identity and completing a secure credit card transaction without the use of a credit card number |
US20070291995A1 (en) | 2006-06-09 | 2007-12-20 | Rivera Paul G | System, Method, and Apparatus for Preventing Identity Fraud Associated With Payment and Identity Cards |
US20080015988A1 (en) | 2006-06-28 | 2008-01-17 | Gary Brown | Proxy card authorization system |
US10019708B2 (en) | 2006-08-25 | 2018-07-10 | Amazon Technologies, Inc. | Utilizing phrase tokens in transactions |
US7469151B2 (en) | 2006-09-01 | 2008-12-23 | Vivotech, Inc. | Methods, systems and computer program products for over the air (OTA) provisioning of soft cards on devices with wireless communications capabilities |
US20080228646A1 (en) | 2006-10-04 | 2008-09-18 | Myers James R | Method and system for managing a non-changing payment card account number |
DE112007002744T5 (en) | 2006-11-16 | 2009-10-08 | Net1 Ueps Technologies, Inc. | Secured financial transactions |
US7848980B2 (en) | 2006-12-26 | 2010-12-07 | Visa U.S.A. Inc. | Mobile payment system and method using alias |
US20090006262A1 (en) | 2006-12-30 | 2009-01-01 | Brown Kerry D | Financial transaction payment processor |
US7841539B2 (en) | 2007-02-15 | 2010-11-30 | Alfred Hewton | Smart card with random temporary account number generation |
US20080201264A1 (en) | 2007-02-17 | 2008-08-21 | Brown Kerry D | Payment card financial transaction authenticator |
US20080243702A1 (en) | 2007-03-30 | 2008-10-02 | Ricoh Company, Ltd. | Tokens Usable in Value-Based Transactions |
US7896238B2 (en) | 2007-04-03 | 2011-03-01 | Intellectual Ventures Holding 32 Llc | Secured transaction using color coded account identifiers |
US7938318B2 (en) | 2007-04-03 | 2011-05-10 | Intellectual Ventures Holding 32 Llc | System and method for controlling secured transaction using directionally coded account identifiers |
EP3575951A1 (en) | 2007-04-17 | 2019-12-04 | Visa USA, Inc. | Method and system for authenticating a party to a transaction |
US8109436B1 (en) | 2007-04-26 | 2012-02-07 | United Services Automobile Association (Usaa) | Secure card |
US7784685B1 (en) | 2007-04-26 | 2010-08-31 | United Services Automobile Association (Usaa) | Secure card |
US7959076B1 (en) | 2007-04-26 | 2011-06-14 | United Services Automobile Association (Usaa) | Secure card |
US7891563B2 (en) | 2007-05-17 | 2011-02-22 | Shift4 Corporation | Secure payment card transactions |
CA2688762C (en) | 2007-05-17 | 2016-02-23 | Shift4 Corporation | Secure payment card transactions |
US7770789B2 (en) | 2007-05-17 | 2010-08-10 | Shift4 Corporation | Secure payment card transactions |
US7841523B2 (en) | 2007-05-17 | 2010-11-30 | Shift4 Corporation | Secure payment card transactions |
US7971261B2 (en) | 2007-06-12 | 2011-06-28 | Microsoft Corporation | Domain management for digital media |
US7739169B2 (en) | 2007-06-25 | 2010-06-15 | Visa U.S.A. Inc. | Restricting access to compromised account information |
US8121942B2 (en) | 2007-06-25 | 2012-02-21 | Visa U.S.A. Inc. | Systems and methods for secure and transparent cardless transactions |
JP2009015548A (en) | 2007-07-04 | 2009-01-22 | Omron Corp | Drive assisting device and method, and program |
US8326758B2 (en) | 2007-08-06 | 2012-12-04 | Enpulz, L.L.C. | Proxy card representing many monetary sources from a plurality of vendors |
US8494959B2 (en) | 2007-08-17 | 2013-07-23 | Emc Corporation | Payment card with dynamic account number |
US7849014B2 (en) | 2007-08-29 | 2010-12-07 | American Express Travel Related Services Company, Inc. | System and method for facilitating a financial transaction with a dynamically generated identifier |
US9070129B2 (en) | 2007-09-04 | 2015-06-30 | Visa U.S.A. Inc. | Method and system for securing data fields |
US7937324B2 (en) | 2007-09-13 | 2011-05-03 | Visa U.S.A. Inc. | Account permanence |
US9747598B2 (en) | 2007-10-02 | 2017-08-29 | Iii Holdings 1, Llc | Dynamic security code push |
US8095113B2 (en) | 2007-10-17 | 2012-01-10 | First Data Corporation | Onetime passwords for smart chip cards |
US20090106160A1 (en) | 2007-10-19 | 2009-04-23 | First Data Corporation | Authorizations for mobile contactless payment transactions |
CN101425894B (en) | 2007-10-30 | 2012-03-21 | 阿里巴巴集团控股有限公司 | Service implementing system and method |
US8249985B2 (en) | 2007-11-29 | 2012-08-21 | Bank Of America Corporation | Sub-account mechanism |
US20090157555A1 (en) | 2007-12-12 | 2009-06-18 | American Express Travel Related Services Company, | Bill payment system and method |
US8117129B2 (en) | 2007-12-21 | 2012-02-14 | American Express Travel Related Services Company, Inc. | Systems, methods and computer program products for performing mass transit merchant transactions |
US20090159710A1 (en) | 2007-12-24 | 2009-06-25 | Dynamics Inc. | Cards and devices with magnetic emulators and magnetic reader read-head detectors |
US8224702B2 (en) | 2007-12-28 | 2012-07-17 | Ebay, Inc. | Systems and methods for facilitating financial transactions over a network |
WO2009089099A1 (en) | 2008-01-04 | 2009-07-16 | M2 International Ltd. | Dynamic card verification value |
FR2926938B1 (en) | 2008-01-28 | 2010-03-19 | Paycool Dev | METHOD OF AUTHENTICATING AND SIGNING A USER TO AN APPLICATION SERVICE USING A MOBILE PHONE AS A SECOND FACTOR IN COMPLEMENT AND INDEPENDENTLY OF A FIRST FACTOR |
US8255971B1 (en) | 2008-03-03 | 2012-08-28 | Jpmorgan Chase Bank, N.A. | Authentication system and method |
US8578176B2 (en) | 2008-03-26 | 2013-11-05 | Protegrity Corporation | Method and apparatus for tokenization of sensitive sets of characters |
US20090248583A1 (en) | 2008-03-31 | 2009-10-01 | Jasmeet Chhabra | Device, system, and method for secure online transactions |
US20090327131A1 (en) | 2008-04-29 | 2009-12-31 | American Express Travel Related Services Company, Inc. | Dynamic account authentication using a mobile device |
US20090276347A1 (en) | 2008-05-01 | 2009-11-05 | Kargman James B | Method and apparatus for use of a temporary financial transaction number or code |
US9715709B2 (en) | 2008-05-09 | 2017-07-25 | Visa International Services Association | Communication device including multi-part alias identifier |
US8651374B2 (en) | 2008-06-02 | 2014-02-18 | Sears Brands, L.L.C. | System and method for payment card industry enterprise account number elimination |
US20090307140A1 (en) | 2008-06-06 | 2009-12-10 | Upendra Mardikar | Mobile device over-the-air (ota) registration and point-of-sale (pos) payment |
US9269010B2 (en) | 2008-07-14 | 2016-02-23 | Jumio Inc. | Mobile phone payment system using integrated camera credit card reader |
US8090650B2 (en) | 2008-07-24 | 2012-01-03 | At&T Intellectual Property I, L.P. | Secure payment service and system for interactive voice response (IVR) systems |
US8219489B2 (en) | 2008-07-29 | 2012-07-10 | Visa U.S.A. Inc. | Transaction processing using a global unique identifier |
US9053474B2 (en) | 2008-08-04 | 2015-06-09 | At&T Mobility Ii Llc | Systems and methods for handling point-of-sale transactions using a mobile device |
US8281991B2 (en) | 2008-08-07 | 2012-10-09 | Visa U.S.A. Inc. | Transaction secured in an untrusted environment |
US8403211B2 (en) | 2008-09-04 | 2013-03-26 | Metabank | System, program product and methods for retail activation and reload associated with partial authorization transactions |
US8965811B2 (en) | 2008-10-04 | 2015-02-24 | Mastercard International Incorporated | Methods and systems for using physical payment cards in secure E-commerce transactions |
US20100094755A1 (en) | 2008-10-09 | 2010-04-15 | Nelnet Business Solutions, Inc. | Providing payment data tokens for online transactions utilizing hosted inline frames |
US20100106644A1 (en) | 2008-10-23 | 2010-04-29 | Diversinet Corp. | System and Method for Authorizing Transactions Via Mobile Devices |
US8126449B2 (en) | 2008-11-13 | 2012-02-28 | American Express Travel Related Services Company, Inc. | Servicing attributes on a mobile device |
US8196813B2 (en) | 2008-12-03 | 2012-06-12 | Ebay Inc. | System and method to allow access to a value holding account |
US8838503B2 (en) | 2008-12-08 | 2014-09-16 | Ebay Inc. | Unified identity verification |
US8060449B1 (en) | 2009-01-05 | 2011-11-15 | Sprint Communications Company L.P. | Partially delegated over-the-air provisioning of a secure element |
US10037524B2 (en) | 2009-01-22 | 2018-07-31 | First Data Corporation | Dynamic primary account number (PAN) and unique key per card |
US10354321B2 (en) | 2009-01-22 | 2019-07-16 | First Data Corporation | Processing transactions with an extended application ID and dynamic cryptograms |
US8606638B2 (en) | 2009-03-02 | 2013-12-10 | First Data Corporation | Systems, methods and apparatus for facilitating transactions using a mobile device |
US20100235284A1 (en) | 2009-03-13 | 2010-09-16 | Gidah, Inc. | Method and systems for generating and using tokens in a transaction handling system |
US8595098B2 (en) | 2009-03-18 | 2013-11-26 | Network Merchants, Inc. | Transmission of sensitive customer information during electronic-based transactions |
US8567670B2 (en) | 2009-03-27 | 2013-10-29 | Intersections Inc. | Dynamic card verification values and credit transactions |
US8584251B2 (en) | 2009-04-07 | 2013-11-12 | Princeton Payment Solutions | Token-based payment processing system |
US20100258620A1 (en) | 2009-04-10 | 2010-10-14 | Denise Torreyson | Methods and systems for linking multiple accounts |
EP2419888A4 (en) | 2009-04-16 | 2017-03-08 | Telefonaktiebolaget LM Ericsson (publ) | Method, server, computer program and computer program product for communicating with secure element |
EP2425386A2 (en) | 2009-04-30 | 2012-03-07 | Donald Michael Cardina | Systems and methods for randomized mobile payment |
US8725122B2 (en) | 2009-05-13 | 2014-05-13 | First Data Corporation | Systems and methods for providing trusted service management services |
US8534564B2 (en) | 2009-05-15 | 2013-09-17 | Ayman Hammad | Integration of verification tokens with mobile communication devices |
US10140598B2 (en) | 2009-05-20 | 2018-11-27 | Visa International Service Association | Device including encrypted data for expiration date and verification value creation |
US20100306076A1 (en) | 2009-05-29 | 2010-12-02 | Ebay Inc. | Trusted Integrity Manager (TIM) |
TWI402775B (en) | 2009-07-16 | 2013-07-21 | Mxtran Inc | Financial transaction system, automated teller machine (atm), and method for operating an atm |
AU2010282680A1 (en) | 2009-08-10 | 2012-03-08 | Visa International Service Association | Systems and methods for enrolling users in a payment service |
US8818882B2 (en) | 2009-08-24 | 2014-08-26 | Visa International Service Association | Alias identity and reputation validation engine |
US8799666B2 (en) | 2009-10-06 | 2014-08-05 | Synaptics Incorporated | Secure user authentication using biometric information |
MX2012004397A (en) | 2009-10-13 | 2012-08-15 | Square Inc | Systems and methods for financial transaction through miniaturized card reader. |
US8447699B2 (en) | 2009-10-13 | 2013-05-21 | Qualcomm Incorporated | Global secure service provider directory |
WO2011047331A2 (en) | 2009-10-16 | 2011-04-21 | Visa International Service Association | Anti-phishing system and method including list with user data |
US20110246317A1 (en) | 2009-10-23 | 2011-10-06 | Apriva, Llc | System and device for facilitating a transaction through use of a proxy account code |
US8296568B2 (en) | 2009-10-27 | 2012-10-23 | Google Inc. | Systems and methods for authenticating an electronic transaction |
US8433116B2 (en) | 2009-11-03 | 2013-04-30 | Mela Sciences, Inc. | Showing skin lesion information |
US9633351B2 (en) | 2009-11-05 | 2017-04-25 | Visa International Service Association | Encryption switch processing |
US10255591B2 (en) | 2009-12-18 | 2019-04-09 | Visa International Service Association | Payment channel returning limited use proxy dynamic value |
US8595812B2 (en) | 2009-12-18 | 2013-11-26 | Sabre Inc. | Tokenized data security |
US9324066B2 (en) | 2009-12-21 | 2016-04-26 | Verizon Patent And Licensing Inc. | Method and system for providing virtual credit card services |
US8788429B2 (en) | 2009-12-30 | 2014-07-22 | First Data Corporation | Secure transaction management |
BR112012017000A2 (en) | 2010-01-12 | 2016-04-05 | Visa Int Service Ass | method |
CA2787041C (en) | 2010-01-19 | 2020-02-25 | Mike Lindelsee | Remote variable authentication processing |
EP2526517B1 (en) | 2010-01-19 | 2018-08-08 | Visa International Service Association | Token based transaction authentication |
US8615468B2 (en) | 2010-01-27 | 2013-12-24 | Ca, Inc. | System and method for generating a dynamic card value |
US9501773B2 (en) | 2010-02-02 | 2016-11-22 | Xia Dai | Secured transaction system |
WO2011106716A1 (en) | 2010-02-25 | 2011-09-01 | Secureauth Corporation | Security device provisioning |
US9245267B2 (en) | 2010-03-03 | 2016-01-26 | Visa International Service Association | Portable account number for consumer payment account |
US8458487B1 (en) | 2010-03-03 | 2013-06-04 | Liaison Technologies, Inc. | System and methods for format preserving tokenization of sensitive information |
US20110238511A1 (en) | 2010-03-07 | 2011-09-29 | Park Steve H | Fuel dispenser payment system and method |
US8533860B1 (en) | 2010-03-21 | 2013-09-10 | William Grecia | Personalized digital media access system—PDMAS part II |
US8887308B2 (en) | 2010-03-21 | 2014-11-11 | William Grecia | Digital cloud access (PDMAS part III) |
US8402555B2 (en) | 2010-03-21 | 2013-03-19 | William Grecia | Personalized digital media access system (PDMAS) |
US20110238573A1 (en) | 2010-03-25 | 2011-09-29 | Computer Associates Think, Inc. | Cardless atm transaction method and system |
US8380177B2 (en) | 2010-04-09 | 2013-02-19 | Paydiant, Inc. | Mobile phone payment processing methods and systems |
US8336088B2 (en) | 2010-04-19 | 2012-12-18 | Visa International Service Association | Alias management and value transfer claim processing |
WO2011153505A1 (en) | 2010-06-04 | 2011-12-08 | Visa International Service Association | Payment tokenization apparatuses, methods and systems |
US8442914B2 (en) | 2010-07-06 | 2013-05-14 | Mastercard International Incorporated | Virtual wallet account with automatic-loading |
US8571939B2 (en) | 2010-07-07 | 2013-10-29 | Toshiba Global Commerce Solutions Holdings Corporation | Two phase payment link and authorization for mobile devices |
US8453226B2 (en) | 2010-07-16 | 2013-05-28 | Visa International Service Association | Token validation for advanced authorization |
WO2012012445A2 (en) | 2010-07-19 | 2012-01-26 | Universal Commerce, Inc. | Mobile system and method for payments and non-financial transactions |
US20120028609A1 (en) | 2010-07-27 | 2012-02-02 | John Hruska | Secure financial transaction system using a registered mobile device |
US9342832B2 (en) | 2010-08-12 | 2016-05-17 | Visa International Service Association | Securing external systems with account token substitution |
CN101938520B (en) | 2010-09-07 | 2015-01-28 | 中兴通讯股份有限公司 | Mobile terminal signature-based remote payment system and method |
US20120066078A1 (en) | 2010-09-10 | 2012-03-15 | Bank Of America Corporation | Overage service using overage passcode |
US8898086B2 (en) | 2010-09-27 | 2014-11-25 | Fidelity National Information Services | Systems and methods for transmitting financial account information |
US9558481B2 (en) | 2010-09-28 | 2017-01-31 | Barclays Bank Plc | Secure account provisioning |
US20120095852A1 (en) | 2010-10-15 | 2012-04-19 | John Bauer | Method and system for electronic wallet access |
US20120095865A1 (en) | 2010-10-15 | 2012-04-19 | Ezpayy, Inc. | System And Method For Mobile Electronic Purchasing |
US10176477B2 (en) | 2010-11-16 | 2019-01-08 | Mastercard International Incorporated | Methods and systems for universal payment account translation |
US8577336B2 (en) | 2010-11-18 | 2013-11-05 | Mobilesphere Holdings LLC | System and method for transaction authentication using a mobile communication device |
WO2012073014A1 (en) | 2010-11-29 | 2012-06-07 | Mobay Technologies Limited | A system for verifying electronic transactions |
US9141945B2 (en) | 2010-12-02 | 2015-09-22 | Appmobi Iplc, Inc. | Secure distributed single action payment system |
US8762284B2 (en) | 2010-12-16 | 2014-06-24 | Democracyontheweb, Llc | Systems and methods for facilitating secure transactions |
US8807440B1 (en) | 2010-12-17 | 2014-08-19 | Google Inc. | Routing secure element payment requests to an alternate application |
EP2656281A4 (en) | 2010-12-20 | 2015-01-14 | Antonio Claudiu Eram | System and method for mobile payments enablement and order fulfillment |
US20120173431A1 (en) | 2010-12-30 | 2012-07-05 | First Data Corporation | Systems and methods for using a token as a payment in a transaction |
US20120185386A1 (en) | 2011-01-18 | 2012-07-19 | Bank Of America | Authentication tool |
WO2012098555A1 (en) | 2011-01-20 | 2012-07-26 | Google Inc. | Direct carrier billing |
US8725644B2 (en) | 2011-01-28 | 2014-05-13 | The Active Network, Inc. | Secure online transaction processing |
US20120203664A1 (en) | 2011-02-09 | 2012-08-09 | Tycoon Unlimited, Inc. | Contactless wireless transaction processing system |
US20120203666A1 (en) | 2011-02-09 | 2012-08-09 | Tycoon Unlimited, Inc. | Contactless wireless transaction processing system |
WO2012116221A1 (en) | 2011-02-23 | 2012-08-30 | Mastercard International, Inc. | Demand deposit account payment system |
WO2012118870A1 (en) | 2011-02-28 | 2012-09-07 | Visa International Service Association | Secure anonymous transaction apparatuses, methods and systems |
CN103503010B (en) | 2011-03-04 | 2017-12-29 | 维萨国际服务协会 | Ability to pay is bound to the safety element of computer |
US20120231844A1 (en) | 2011-03-11 | 2012-09-13 | Apriva, Llc | System and device for facilitating a transaction by consolidating sim, personal token, and associated applications for electronic wallet transactions |
US20120233004A1 (en) | 2011-03-11 | 2012-09-13 | James Bercaw | System for mobile electronic commerce |
US20120246071A1 (en) | 2011-03-21 | 2012-09-27 | Nikhil Jain | System and method for presentment of nonconfidential transaction token identifier |
US9883387B2 (en) | 2011-03-24 | 2018-01-30 | Visa International Service Association | Authentication using application authentication element |
WO2012142045A2 (en) | 2011-04-11 | 2012-10-18 | Visa International Service Association | Multiple tokenization for authentication |
WO2012142370A2 (en) | 2011-04-15 | 2012-10-18 | Shift4 Corporation | Method and system for enabling merchants to share tokens |
US9818111B2 (en) | 2011-04-15 | 2017-11-14 | Shift4 Corporation | Merchant-based token sharing |
US9256874B2 (en) | 2011-04-15 | 2016-02-09 | Shift4 Corporation | Method and system for enabling merchants to share tokens |
US8688589B2 (en) | 2011-04-15 | 2014-04-01 | Shift4 Corporation | Method and system for utilizing authorization factor pools |
WO2012145530A2 (en) | 2011-04-20 | 2012-10-26 | Visa International Service Association | Managing electronic tokens in a transaction processing system |
WO2012151590A2 (en) | 2011-05-05 | 2012-11-08 | Transaction Network Services, Inc. | Systems and methods for enabling mobile payments |
US20130204793A1 (en) | 2011-05-17 | 2013-08-08 | Kevin S. Kerridge | Smart communication device secured electronic payment system |
US9059980B2 (en) | 2011-05-26 | 2015-06-16 | First Data Corporation | Systems and methods for authenticating mobile devices |
US8943574B2 (en) | 2011-05-27 | 2015-01-27 | Vantiv, Llc | Tokenizing sensitive data |
US10395256B2 (en) | 2011-06-02 | 2019-08-27 | Visa International Service Association | Reputation management in a transaction processing system |
US8538845B2 (en) | 2011-06-03 | 2013-09-17 | Mozido, Llc | Monetary transaction system |
EP2715633A4 (en) | 2011-06-03 | 2014-12-17 | Visa Int Service Ass | Virtual wallet card selection apparatuses, methods and systems |
RU2602394C2 (en) | 2011-06-07 | 2016-11-20 | Виза Интернешнл Сервис Ассосиэйшн | Payment privacy tokenisation apparatus, methods and systems |
US10318932B2 (en) | 2011-06-07 | 2019-06-11 | Entit Software Llc | Payment card processing system with structure preserving encryption |
WO2012167941A1 (en) | 2011-06-09 | 2012-12-13 | Gemalto Sa | Method to validate a transaction between a user and a service provider |
US9355393B2 (en) | 2011-08-18 | 2016-05-31 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US9947010B2 (en) * | 2011-07-15 | 2018-04-17 | Mastercard International Incorporated | Methods and systems for payments assurance |
US9639828B2 (en) | 2011-07-15 | 2017-05-02 | Visa International Service Association | Method and system for hosted order page/silent order post plus fraud detection |
US8606712B2 (en) * | 2011-07-21 | 2013-12-10 | Bank Of America Corporation | Multi-stage filtering for fraud detection with account event data filters |
US9704155B2 (en) | 2011-07-29 | 2017-07-11 | Visa International Service Association | Passing payment tokens through an hop/sop |
US20130054412A1 (en) | 2011-08-22 | 2013-02-28 | American Express Travel Related Services Company, Inc. | Methods and systems for contactless payments for online ecommerce checkout |
US20130218769A1 (en) | 2011-08-23 | 2013-08-22 | Stacy Pourfallah | Mobile Funding Method and System |
WO2013028901A2 (en) | 2011-08-23 | 2013-02-28 | Visa International Service Association | Authentication process for value transfer machine |
BR112014004374B1 (en) | 2011-08-30 | 2021-09-21 | Simplytapp, Inc | METHOD FOR SECURE APPLICATION-BASED PARTICIPATION IN A PAYMENT CARD TRANSACTION AUTHORIZATION PROCESS BY A MOBILE DEVICE, SYSTEM FOR SECURE APPLICATION-BASED PARTICIPATION BY A MOBILE DEVICE IN POINT OF SALE INQUIRIES |
US20130339253A1 (en) | 2011-08-31 | 2013-12-19 | Dan Moshe Sincai | Mobile Device Based Financial Transaction System |
US8171525B1 (en) | 2011-09-15 | 2012-05-01 | Google Inc. | Enabling users to select between secure service providers using a central trusted service manager |
US8838982B2 (en) | 2011-09-21 | 2014-09-16 | Visa International Service Association | Systems and methods to secure user identification |
US8453223B2 (en) | 2011-09-23 | 2013-05-28 | Jerome Svigals | Method, device and system for secure transactions |
CN103890793A (en) | 2011-10-01 | 2014-06-25 | 英特尔公司 | Cloud based credit card emulation |
BR112014008941A2 (en) | 2011-10-12 | 2017-05-02 | C-Sam Inc | platform that enables secure multilayer mobile transactions |
US9229964B2 (en) | 2011-10-27 | 2016-01-05 | Visa International Business Machines Corporation | Database cloning and migration for quality assurance |
US9830596B2 (en) | 2011-11-01 | 2017-11-28 | Stripe, Inc. | Method for conducting a transaction between a merchant site and a customer's electronic device without exposing payment information to a server-side application of the merchant site |
CN104025507B (en) | 2011-11-01 | 2017-02-22 | 谷歌公司 | Systems, methods, and computer program products for interfacing multiple service provider trusted service managers and secure elements |
US20130124364A1 (en) | 2011-11-13 | 2013-05-16 | Millind Mittal | System and method of electronic payment using payee provided transaction identification codes |
US9165321B1 (en) | 2011-11-13 | 2015-10-20 | Google Inc. | Optimistic receipt flow |
US9348896B2 (en) | 2011-12-05 | 2016-05-24 | Visa International Service Association | Dynamic network analytics system |
US8656180B2 (en) | 2011-12-06 | 2014-02-18 | Wwpass Corporation | Token activation |
US8972719B2 (en) | 2011-12-06 | 2015-03-03 | Wwpass Corporation | Passcode restoration |
US8555079B2 (en) | 2011-12-06 | 2013-10-08 | Wwpass Corporation | Token management |
US20130159178A1 (en) | 2011-12-14 | 2013-06-20 | Firethorn Mobile, Inc. | System and Method For Loading A Virtual Token Managed By A Mobile Wallet System |
US20130159184A1 (en) | 2011-12-15 | 2013-06-20 | Visa International Service Association | System and method of using load network to associate product or service with a consumer token |
US20140040139A1 (en) | 2011-12-19 | 2014-02-06 | Sequent Software, Inc. | System and method for dynamic temporary payment authorization in a portable communication device |
US9053481B2 (en) | 2011-12-21 | 2015-06-09 | Mastercard International Incorporated | Methods and systems for providing a payment account with adaptive interchange |
US9077769B2 (en) | 2011-12-29 | 2015-07-07 | Blackberry Limited | Communications system providing enhanced trusted service manager (TSM) verification features and related methods |
US20130254117A1 (en) | 2011-12-30 | 2013-09-26 | Clay W. von Mueller | Secured transaction system and method |
EP3770839A1 (en) | 2012-01-05 | 2021-01-27 | Visa International Service Association | Data protection with translation |
US8566168B1 (en) | 2012-01-05 | 2013-10-22 | Sprint Communications Company L.P. | Electronic payment using a proxy account number stored in a secure element |
US9830595B2 (en) | 2012-01-26 | 2017-11-28 | Visa International Service Association | System and method of providing tokenization as a service |
US10643191B2 (en) | 2012-01-27 | 2020-05-05 | Visa International Service Association | Mobile services remote deposit capture |
US8595850B2 (en) | 2012-01-30 | 2013-11-26 | Voltage Security, Inc. | System for protecting sensitive data with distributed tokenization |
EP2624190A1 (en) | 2012-02-03 | 2013-08-07 | Pieter Dubois | Authentication of payment transactions using an alias |
WO2013116726A1 (en) | 2012-02-03 | 2013-08-08 | Ebay Inc. | Adding card to mobile wallet using nfc |
US20130212019A1 (en) | 2012-02-10 | 2013-08-15 | Ulf Mattsson | Tokenization of payment information in mobile environments |
US20130212017A1 (en) | 2012-02-14 | 2013-08-15 | N.B. Development Services Inc. | Transaction system and method of conducting a transaction |
US20130226813A1 (en) | 2012-02-23 | 2013-08-29 | Robert Matthew Voltz | Cyberspace Identification Trust Authority (CITA) System and Method |
WO2013138528A1 (en) | 2012-03-14 | 2013-09-19 | Visa International Service Association | Point-of-transaction account feature redirection apparatuses, methods and systems |
US9092776B2 (en) | 2012-03-15 | 2015-07-28 | Qualcomm Incorporated | System and method for managing payment in transactions with a PCD |
US20130246259A1 (en) | 2012-03-15 | 2013-09-19 | Firethorn Mobile, Inc. | System and method for managing payment in transactions with a pcd |
US9105021B2 (en) | 2012-03-15 | 2015-08-11 | Ebay, Inc. | Systems, methods, and computer program products for using proxy accounts |
US20130246267A1 (en) | 2012-03-15 | 2013-09-19 | Ebay Inc. | Systems, Methods, and Computer Program Products for Using Proxy Accounts |
US20130254102A1 (en) | 2012-03-20 | 2013-09-26 | First Data Corporation | Systems and Methods for Distributing Tokenization and De-Tokenization Services |
US9818098B2 (en) | 2012-03-20 | 2017-11-14 | First Data Corporation | Systems and methods for facilitating payments via a peer-to-peer protocol |
US20130254028A1 (en) | 2012-03-22 | 2013-09-26 | Corbuss Kurumsal Telekom Hizmetleri A.S. | System and method for conducting mobile commerce |
US20130262315A1 (en) | 2012-03-30 | 2013-10-03 | John Hruska | System for Secure Purchases Made by Scanning Barcode Using a Registered Mobile Phone Application Linked to a Consumer-Merchant Closed Loop Financial Proxy Account System |
US20130262302A1 (en) | 2012-04-02 | 2013-10-03 | Jvl Ventures, Llc | Systems, methods, and computer program products for provisioning payment accounts into mobile wallets and managing events |
US10515359B2 (en) | 2012-04-02 | 2019-12-24 | Mastercard International Incorporated | Systems and methods for processing mobile payments by provisioning credentials to mobile devices without secure elements |
PL2836971T3 (en) | 2012-04-13 | 2018-05-30 | Mastercard International Inc | Systems, methods, and computer readable media for conducting a transaction using cloud based credentials |
JP5795453B2 (en) | 2012-04-18 | 2015-10-14 | グーグル・インコーポレーテッド | Payment transaction processing without secure elements |
US20130282588A1 (en) | 2012-04-22 | 2013-10-24 | John Hruska | Consumer, Merchant and Mobile Device Specific, Real-Time Dynamic Tokenization Activation within a Secure Mobile-Wallet Financial Transaction System |
US10275764B2 (en) | 2012-05-04 | 2019-04-30 | Mastercard International Incorporated | Transaction data tokenization |
US20130297501A1 (en) | 2012-05-04 | 2013-11-07 | Justin Monk | System and method for local data conversion |
US20130311382A1 (en) | 2012-05-21 | 2013-11-21 | Klaus S. Fosmark | Obtaining information for a payment transaction |
US9521548B2 (en) | 2012-05-21 | 2016-12-13 | Nexiden, Inc. | Secure registration of a mobile device for use with a session |
WO2013179271A2 (en) | 2012-06-01 | 2013-12-05 | Mani Venkatachalam Sthanu Subra | Method and system for human assisted secure payment by phone to an insecure third-party service provider |
US9524501B2 (en) | 2012-06-06 | 2016-12-20 | Visa International Service Association | Method and system for correlating diverse transaction data |
US20140007213A1 (en) | 2012-06-29 | 2014-01-02 | Wepay, Inc. | Systems and methods for push notification based application authentication and authorization |
US9059972B2 (en) | 2012-07-03 | 2015-06-16 | International Business Machines Corporation | Issuing, presenting and challenging mobile device identification documents |
US9547769B2 (en) | 2012-07-03 | 2017-01-17 | Visa International Service Association | Data protection hub |
US9043609B2 (en) | 2012-07-19 | 2015-05-26 | Bank Of America Corporation | Implementing security measures for authorized tokens used in mobile transactions |
US20140025585A1 (en) | 2012-07-19 | 2014-01-23 | Bank Of America Corporation | Distributing authorized tokens to conduct mobile transactions |
US20140025581A1 (en) | 2012-07-19 | 2014-01-23 | Bank Of America Corporation | Mobile transactions using authorized tokens |
US9846861B2 (en) | 2012-07-25 | 2017-12-19 | Visa International Service Association | Upstream and downstream data conversion |
US9256871B2 (en) | 2012-07-26 | 2016-02-09 | Visa U.S.A. Inc. | Configurable payment tokens |
US10339524B2 (en) | 2012-07-31 | 2019-07-02 | Worldpay, Llc | Systems and methods for multi-merchant tokenization |
US10346838B2 (en) | 2012-07-31 | 2019-07-09 | Worldpay, Llc | Systems and methods for distributed enhanced payment processing |
US10152711B2 (en) | 2012-07-31 | 2018-12-11 | Worldpay, Llc | Systems and methods for arbitraged enhanced payment processing |
WO2014022778A1 (en) | 2012-08-03 | 2014-02-06 | Vasco Data Security, Inc. | User-convenient authentication method and apparatus using a mobile authentication application |
US9665722B2 (en) | 2012-08-10 | 2017-05-30 | Visa International Service Association | Privacy firewall |
US20140052532A1 (en) | 2012-08-17 | 2014-02-20 | Google Inc. | Portable device wireless reader and payment transaction terminal functionality with other portable devices |
EP2891107A4 (en) | 2012-08-28 | 2016-04-13 | Visa Int Service Ass | Protecting assets on a device |
AU2013315510B2 (en) | 2012-09-11 | 2019-08-22 | Visa International Service Association | Cloud-based Virtual Wallet NFC Apparatuses, methods and systems |
US9390412B2 (en) | 2012-10-16 | 2016-07-12 | Visa International Service Association | Dynamic point of sale system integrated with reader device |
US10176478B2 (en) | 2012-10-23 | 2019-01-08 | Visa International Service Association | Transaction initiation determination system utilizing transaction data elements |
US9911118B2 (en) | 2012-11-21 | 2018-03-06 | Visa International Service Association | Device pairing via trusted intermediary |
US20140164243A1 (en) | 2012-12-07 | 2014-06-12 | Christian Aabye | Dynamic Account Identifier With Return Real Account Identifier |
US9741051B2 (en) | 2013-01-02 | 2017-08-22 | Visa International Service Association | Tokenization and third-party interaction |
CN105378776A (en) | 2013-02-26 | 2016-03-02 | 维萨国际服务协会 | Methods and systems for providing payment credentials |
US9249241B2 (en) | 2013-03-27 | 2016-02-02 | Ut-Battelle, Llc | Surface-functionalized mesoporous carbon materials |
US20160092874A1 (en) | 2013-04-04 | 2016-03-31 | Visa International Service Association | Method and system for conducting pre-authorized financial transactions |
US20140310183A1 (en) | 2013-04-15 | 2014-10-16 | Lance Weber | Embedded acceptance system |
US20140331265A1 (en) | 2013-05-01 | 2014-11-06 | Microsoft Corporation | Integrated interactive television entertainment system |
US11055710B2 (en) | 2013-05-02 | 2021-07-06 | Visa International Service Association | Systems and methods for verifying and processing transactions using virtual currency |
US20140330722A1 (en) | 2013-05-02 | 2014-11-06 | Prasanna Laxminarayanan | System and method for using an account sequence identifier |
US20140337217A1 (en) * | 2013-05-09 | 2014-11-13 | Mastercard International Incorporated | Card present fraud prevention method using airline passenger detail |
US9760886B2 (en) | 2013-05-10 | 2017-09-12 | Visa International Service Association | Device provisioning using partial personalization scripts |
SG10202008740YA (en) | 2013-05-15 | 2020-10-29 | Visa Int Service Ass | Mobile tokenization hub |
US10878422B2 (en) | 2013-06-17 | 2020-12-29 | Visa International Service Association | System and method using merchant token |
US20160132878A1 (en) | 2013-07-02 | 2016-05-12 | Visa International Service Association | Payment Card Including User Interface for Use with Payment Card Acceptance Terminal |
CA2918066A1 (en) | 2013-07-15 | 2015-01-22 | Visa International Service Association | Secure remote payment transaction processing |
CN105874495B (en) | 2013-07-24 | 2021-08-10 | 维萨国际服务协会 | System and method for ensuring data transfer risk using tokens |
SG10201801086RA (en) | 2013-08-08 | 2018-03-28 | Visa Int Service Ass | Methods and systems for provisioning mobile devices with payment credentials |
US10496986B2 (en) | 2013-08-08 | 2019-12-03 | Visa International Service Association | Multi-network tokenization processing |
CA2921008A1 (en) | 2013-08-15 | 2015-02-19 | Visa International Service Association | Secure remote payment transaction processing using a secure element |
SG11201602093TA (en) | 2013-09-20 | 2016-04-28 | Visa Int Service Ass | Secure remote payment transaction processing including consumer authentication |
US9978094B2 (en) | 2013-10-11 | 2018-05-22 | Visa International Service Association | Tokenization revocation list |
US10489779B2 (en) | 2013-10-21 | 2019-11-26 | Visa International Service Association | Multi-network token bin routing with defined verification parameters |
US10366387B2 (en) | 2013-10-29 | 2019-07-30 | Visa International Service Association | Digital wallet system and method |
US20150127529A1 (en) | 2013-11-05 | 2015-05-07 | Oleg Makhotin | Methods and systems for mobile payment application selection and management using an application linker |
US20150142673A1 (en) | 2013-11-18 | 2015-05-21 | Mark Nelsen | Methods and systems for token request management |
WO2015077247A1 (en) | 2013-11-19 | 2015-05-28 | Visa International Service Association | Automated account provisioning |
US20150161597A1 (en) | 2013-12-09 | 2015-06-11 | Kaushik Subramanian | Transactions using temporary credential data |
RU2019111186A (en) | 2013-12-19 | 2019-05-07 | Виза Интернэшнл Сервис Ассосиэйшн | METHODS AND SYSTEMS OF CLOUD TRANSACTIONS |
US9922322B2 (en) | 2013-12-19 | 2018-03-20 | Visa International Service Association | Cloud-based transactions with magnetic secure transmission |
US10445718B2 (en) | 2013-12-27 | 2019-10-15 | Visa International Service Association | Processing a transaction using multiple application identifiers |
US10108409B2 (en) | 2014-01-03 | 2018-10-23 | Visa International Service Association | Systems and methods for updatable applets |
US10433128B2 (en) | 2014-01-07 | 2019-10-01 | Visa International Service Association | Methods and systems for provisioning multiple devices |
US20150199679A1 (en) | 2014-01-13 | 2015-07-16 | Karthikeyan Palanisamy | Multiple token provisioning |
CA2936985A1 (en) | 2014-02-04 | 2015-08-13 | Visa International Service Association | Token verification using limited use certificates |
AU2015231418A1 (en) | 2014-03-18 | 2016-09-29 | Visa International Service Association | Systems and methods for locally derived tokens |
US20150278799A1 (en) | 2014-03-27 | 2015-10-01 | Karthikeyan Palanisamy | System incorporating wireless share process |
US10026087B2 (en) | 2014-04-08 | 2018-07-17 | Visa International Service Association | Data passed in an interaction |
US9942043B2 (en) | 2014-04-23 | 2018-04-10 | Visa International Service Association | Token security on a communication device |
SG11201608973TA (en) | 2014-05-01 | 2016-11-29 | Visa Int Service Ass | Data verification using access device |
SG11201609216YA (en) | 2014-05-05 | 2016-12-29 | Visa Int Service Ass | System and method for token domain control |
EP3143573A4 (en) | 2014-05-13 | 2018-01-24 | Visa International Service Association | Master applet for secure remote payment processing |
US11023890B2 (en) | 2014-06-05 | 2021-06-01 | Visa International Service Association | Identification and verification for provisioning mobile application |
US9780953B2 (en) | 2014-07-23 | 2017-10-03 | Visa International Service Association | Systems and methods for secure detokenization |
US10484345B2 (en) | 2014-07-31 | 2019-11-19 | Visa International Service Association | System and method for identity verification across mobile applications |
US9779345B2 (en) | 2014-08-11 | 2017-10-03 | Visa International Service Association | Mobile device with scannable image including dynamic data |
US9775029B2 (en) | 2014-08-22 | 2017-09-26 | Visa International Service Association | Embedding cloud-based functionalities in a communication device |
US9813245B2 (en) | 2014-08-29 | 2017-11-07 | Visa International Service Association | Methods for secure cryptogram generation |
CN111866873B (en) | 2014-09-26 | 2023-09-05 | 维萨国际服务协会 | Remote server encrypted data storage system and method |
US11257074B2 (en) | 2014-09-29 | 2022-02-22 | Visa International Service Association | Transaction risk based token |
SG11201702277UA (en) | 2014-10-10 | 2017-04-27 | Visa Int Service Ass | Methods and systems for partial personalization during mobile application update |
US10015147B2 (en) | 2014-10-22 | 2018-07-03 | Visa International Service Association | Token enrollment system and method |
US10325261B2 (en) | 2014-11-25 | 2019-06-18 | Visa International Service Association | Systems communications with non-sensitive identifiers |
WO2016086154A1 (en) | 2014-11-26 | 2016-06-02 | Visa International Service Association | Tokenization request via access device |
US10257185B2 (en) | 2014-12-12 | 2019-04-09 | Visa International Service Association | Automated access data provisioning |
SG11201703526VA (en) | 2014-12-12 | 2017-05-30 | Visa Int Service Ass | Provisioning platform for machine-to-machine devices |
US10096009B2 (en) | 2015-01-20 | 2018-10-09 | Visa International Service Association | Secure payment processing using authorization request |
CN112260826B (en) | 2015-01-27 | 2023-12-26 | 维萨国际服务协会 | Method for secure credential provisioning |
US11250391B2 (en) | 2015-01-30 | 2022-02-15 | Visa International Service Association | Token check offline |
US10977657B2 (en) | 2015-02-09 | 2021-04-13 | Visa International Service Association | Token processing utilizing multiple authorizations |
CA2970746A1 (en) | 2015-02-13 | 2016-08-18 | Visa International Service Association | Peer forward authorization of digital requests |
US9998978B2 (en) | 2015-04-16 | 2018-06-12 | Visa International Service Association | Systems and methods for processing dormant virtual access devices |
AU2016337614A1 (en) | 2015-10-15 | 2018-03-15 | Visa International Service Association | Instant token issuance system |
US11501288B2 (en) | 2016-02-09 | 2022-11-15 | Visa International Service Association | Resource provider account token provisioning and processing |
US10313321B2 (en) | 2016-04-07 | 2019-06-04 | Visa International Service Association | Tokenization of co-network accounts |
-
2015
- 2015-01-14 US US14/597,072 patent/US9846878B2/en active Active
-
2017
- 2017-11-16 US US15/814,994 patent/US10062079B2/en active Active
-
2018
- 2018-08-01 US US16/052,354 patent/US10269018B2/en active Active
-
2019
- 2019-03-05 US US16/293,488 patent/US20190197552A1/en not_active Abandoned
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130238455A1 (en) * | 2010-04-09 | 2013-09-12 | Kevin Laracey | Methods and systems for selecting accounts and offers in payment transactions |
US20150127547A1 (en) * | 2013-10-11 | 2015-05-07 | Glenn Leon Powell | Network token system |
US20150112870A1 (en) * | 2013-10-18 | 2015-04-23 | Sekhar Nagasundaram | Contextual transaction token methods and systems |
US20160267466A1 (en) * | 2015-03-13 | 2016-09-15 | Phillip Kumnick | Device with multiple identifiers |
US20180018660A1 (en) * | 2016-07-15 | 2018-01-18 | Paypal, Inc. | Processing a transaction using electronic tokens |
Also Published As
Publication number | Publication date |
---|---|
US20150199689A1 (en) | 2015-07-16 |
US20180341948A1 (en) | 2018-11-29 |
US9846878B2 (en) | 2017-12-19 |
US10062079B2 (en) | 2018-08-28 |
US20180075455A1 (en) | 2018-03-15 |
US10269018B2 (en) | 2019-04-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10269018B2 (en) | Payment account identifier system | |
US20210368012A1 (en) | System and method for token domain control | |
JP7522872B2 (en) | INTEROPERABLE NETWORK TOKEN PROCESSING SYSTEM AND METHOD - Patent application | |
US12002049B2 (en) | System communications with non-sensitive identifiers | |
US12074974B2 (en) | Method and system for access token processing | |
US12120117B2 (en) | Method and system for token provisioning and processing | |
US12111897B2 (en) | Method and system for processing action data |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
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: NON FINAL ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |