US20150032625A1 - Systems and methods for communicating risk using token assurance data - Google Patents

Systems and methods for communicating risk using token assurance data Download PDF

Info

Publication number
US20150032625A1
US20150032625A1 US14/340,344 US201414340344A US2015032625A1 US 20150032625 A1 US20150032625 A1 US 20150032625A1 US 201414340344 A US201414340344 A US 201414340344A US 2015032625 A1 US2015032625 A1 US 2015032625A1
Authority
US
United States
Prior art keywords
token
payment
issuer
computer
network
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.)
Pending
Application number
US14/340,344
Inventor
Matthew Dill
Prasanna Laxminarayanan
Glenn Powell
John F. Sheets
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Visa International Service Association
Original Assignee
Visa International Service Association
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority to US201361858087P priority Critical
Priority to US201361863863P priority
Priority to US201461935036P priority
Application filed by Visa International Service Association filed Critical Visa International Service Association
Priority to US14/340,344 priority patent/US20150032625A1/en
Assigned to VISA INTERNATIONAL SERVICE ASSOCIATION reassignment VISA INTERNATIONAL SERVICE ASSOCIATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LAXMINARAYANAN, PRASANNA, DILL, MATTHEW, CARPENTER, ANDREW, POWELL, GLENN, SHEETS, JOHN
Publication of US20150032625A1 publication Critical patent/US20150032625A1/en
Application status is Pending legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/385Use of an alias or a single-use code
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification
    • G06Q20/4016Transaction verification involving fraud or risk level assessment in transaction processing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42Anonymization, e.g. involving pseudonyms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash

Abstract

Systems and methods for communicating risk using token assurance data are provided. A network token system provides a platform that can be leveraged by external entities (e.g., third party wallets, e-commerce merchants, payment enablers/payment service providers, etc.) or internal payment processing network systems that have the need to use the tokens to facilitate payment transactions. An authorization request message can include a token assurance level code that is indicative of a token assurance level associated with a generated token. External or internal entities may use the token assurance level to evaluate risk associated with a payment transaction that uses the token.

Description

    CROSS-REFERENCES TO RELATED APPLICATIONS
  • This application is a non-provisional application of and claims the benefit of priority to U.S. Provisional Application No. 61/858,087, filed on Jul. 24, 2013, U.S. Provisional Application No. 61/863,863, filed on Aug. 8, 2013, and U.S. Provisional Application No. 61/935,036, filed on Feb. 3, 2014, which are herein incorporated by reference in their entirety for all purposes.
  • BACKGROUND
  • In a traditional electronic payment transaction, a consumer's PAN (primary account number) information is exposed to various entities involved during the transaction lifecycle. The PAN is passed from a merchant terminal, to an acquirer system, a payment processing network, payment gateways, etc.
  • Because the PAN can be exposed at various points in the transaction lifecycle, some have suggested that payment “tokens” be used to conduct payment transactions. A token serves as an additional security layer to the PAN and in effect becomes a proxy/surrogate to the PAN and may be used in place of PAN while submitting transactions. The use of payment tokens instead of PANs can reduce the risk of fraudulent activity since the real PAN is never exposed.
  • While conventional efforts to use payment tokens have been useful, a number of additional problems need to be solved. For example, because the real PAN is not apparent from a corresponding token, it is difficult to identify the source of the token or the issuer of the token. On the one hand, the token is intended to hide information. On the other hand, it would be useful to identify from the payment token the origin or the issuer of the token and a level of confidence that the user attempting to use the token is in fact the actual cardholder. Currently, techniques for identifying this information do not exist.
  • Embodiments of the invention address these and other problems, individually and collectively.
  • BRIEF SUMMARY
  • In some embodiments of the invention, a network token system is provided. The network token system provides a platform that can be leveraged by various entities such as third party wallet providers, merchants, acquirers, payment processors, etc. that use tokens to facilitate payment transactions. In the network token system, a token registry vault can provide interfaces for various entities (e.g., mobile devices, issuers, merchants, mobile wallet providers, acquirers, etc.) to request payment tokens, request information about payment tokens or otherwise process payment tokens. The network token system further provides for services such as a token assurance level. The token assurance level may be represented in the form of a token assurance level code that may be understood by the various entities in the network token system.
  • One embodiment of the invention is directed to a method comprising receiving, by a server computer, an authorization request message comprising a payment token, wherein the payment token is associated with a real account identifier. The method further comprises determining, by the server computer, the real account identifier associated with the payment token. The method also comprises generating, by the server computer, a modified authorization request message comprising the real account identifier, wherein the modified authorization request message comprises a token assurance level code indicative of a level of confidence associated with the payment token. Further, the method comprises transmitting, by the server computer, the modified authorization request message to an issuer for approval.
  • In some embodiments, the issuer approval is based at least in part on the token assurance level code.
  • In some embodiments, the level of confidence associated with the payment token comprises a level of confidence that the payment token was requested by an account holder of an underlying payment account associated with the real account identifier.
  • In some embodiments, the token assurance level code indicates an authentication method associated with the payment token.
  • In some embodiments, the authentication method comprises at least one of: no authentication, network authentication, or issuer authentication.
  • In some embodiments, the token assurance level code is based at least in part on a transaction history associated with the real account identifier.
  • In some embodiments, the authorization request message is received by the server computer from a merchant computer.
  • In some embodiments, the method additionally includes receiving an authorization response message from the issuer, generating a modified authorization response message comprising the payment token and the token assurance level code, and transmitting the modified authorization response message to a merchant computer.
  • In some embodiments, before receiving the authorization request message, the payment token is generated and provided to the server computer by an account issuer.
  • In some embodiments, the token assurance level code is generated at the time the payment token is generated.
  • Another embodiment of the invention is directed to a server computer comprising a processor and a computer readable medium comprising code, executable by the processor, for implementing a method. The method comprises determining, by the server computer, the real account identifier associated with the payment token. The method also comprises generating, by the server computer, a modified authorization request message comprising the real account identifier, wherein the modified authorization request comprises a token assurance level code indicative of a level of confidence associated with the payment token. The method further comprises transmitting, by the server computer, the modified authorization request message to an issuer for approval.
  • These and other embodiments of the invention are described in further detail below.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 shows a block diagram of a typical transaction processing system for electronic payment transactions using issuer accounts, in accordance with some embodiments of the invention.
  • FIG. 2 shows a block diagram of a transaction processing system utilizing a network token system, in accordance with some embodiments of the invention.
  • FIG. 3 shows a block diagram of a token processing server computer, in accordance with some embodiments of the invention.
  • FIGS. 4A-4B show exemplary authentication methods that can be used to determine token assurance levels, in accordance with some embodiments of the invention.
  • FIG. 5 shows a flow diagram for an exemplary transaction flow for NFC at the point-of-sale, in accordance with some embodiments of the invention.
  • FIG. 6 shows a flow diagram for an exemplary flow for a card-on-file/e-commerce transaction, in accordance with some embodiments of the invention.
  • FIG. 7 is a flowchart of an exemplary method for transmitting a token assurance level code to an issuer or other entity, in accordance with some embodiments of the invention.
  • FIG. 8 shows a block diagram of a computer apparatus.
  • DETAILED DESCRIPTION
  • Embodiments are directed at systems, methods, and devices for communicating risk using a token assurance level. As explained above, tokenization can involve the replacement or exchange of original payment credentials (e.g., a primary account number (PAN)) for substitute data (e.g., a non-financial identifier or a substitute PAN). A token can be used to initiate or manage transaction activity. Tokens can also improve transaction security.
  • However, even though tokens provide a certain level of improved transaction security, it is still desirable for a confidence level or risk assessment to be associated with a token because it may reduce the risk of a fraudulent transaction. The confidence level or risk assessment can be referred to as a token assurance level. Essentially, the token assurance level provides a certain level of “assurance” that the user using the token is in fact the genuine cardholder.
  • In some embodiments, the token assurance level is based on how the cardholder, card credential, and/or the token have been authenticated by the payment processing network on-behalf-of issuer, the issuer, the merchant, or any other entity in the payment transaction. In some embodiments, the token assurance level may indicate that no authentication has occurred with respect to the cardholder, card credential, and/or the token.
  • In some embodiments, the token assurance level may be used for additional risk assessment by the payment processing network and/or issuer prior to approving a payment transaction.
  • In some embodiments, determination of the token assurance level can be done at the time of the token request. In other embodiments, determination of the token assurance level can be after generation of the token in response to a token request.
  • In some embodiments, the token assurance level can be represented by a token assurance level code within an authorization request message and/or an authorization response message.
  • In some embodiments, liability and dispute processing for token payment transactions may be tied to the token assurance level. For example, an entity may bear the liability for a transaction if the token assurance level is low and the entity approves the transaction which ends up being a fraudulent transaction.
  • In some embodiments of the invention, token assurance levels may be used in various transactions that use various presentment modes (e.g., QR™ Code, contactless, remote e-commerce, proximity e-commerce, etc.) for submitting a token as part of a transaction.
  • In embodiments of the invention, an entity (e.g., third party wallets, issuers, payment service providers, payment enablers, etc.) can register with the network token system to request a token requestor identifier. The network token system can store the token to PAN relationship and the token requestor relationship in a token vault. The registered entity can provide their respective token requestor identifier with a token request to the network token system to use its services. For example, the token requestor can request the issuance of a token via API (Application Programming Interface) messaging or a batch request. The network token system can identify and validate the requesting entity based on the token requestor identifier before responding to the token request. Additionally, the network token system can determine a token assurance level to be associated with the token prior to responding to the token request.
  • In embodiments of the invention, token request messages may allow a token requestor to request a token to thereby tokenize a PAN. After the token is received by the token requester, the token may be provided to a merchant to conduct a payment transaction. The token may then be subsequently provided to an acquirer, payment processing network, and/or an issuer in an authorization request message and/or clearing messages. In some cases, the token may be replaced by a real PAN before an authorization or clearing message is received by an issuer.
  • Some embodiments of the invention can provide an assurance level for a token in a transaction. The token assurance level may indicate a trust level of the token to PAN/consumer binding. In some embodiments, a token assurance level can be determined based on a type of identification and verification process performed and the entity that performed the identity and verification process. For example, the network token system can determine a token assurance level based on the authentication of the consumer, payment account credentials and the token by executing one or more authentication methods. The authentication process can be performed by a payment network and can be network authenticated or can be performed by an issuer to be issuer authenticated. The token assurance level may be determined when issuing a token and may be updated if additional identity and verification processes are performed.
  • Using embodiments of the invention, consumers and issuers may benefit from new and more secure ways to pay and improved approval levels. Since token assurance levels can be associated with tokens, the risk of fraudulent transactions using tokens is greatly reduced.
  • Prior to discussing embodiments of the invention, description of some terms may be helpful in understanding embodiments of the invention.
  • A “token” may include any identifier for a payment account that is a substitute for an account identifier. 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 primary account identifier or primary account number (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.
  • In some embodiments, the token format may allow entities in the payment system to identify the issuer associated with the token. For example, the format of the token may include a token issuer identifier that allows an entity to identify an issuer. For instance, the token issuer identifier may be associated with an issuer's BIN of the underlying PAN in order to support the existing payment flow. The token issuer identifier may be a different number than the issuer's BIN and may be static. For example, if the issuer's BIN for an issuer is 412345, the token issuer identifier may be 528325 and this number may be static for all tokens issued from or for that issuer. In some embodiments, the token issuer identifier range (e.g., issuer BIN range) may have the same attributes as the associated issuer card range and can be included in an issuer identifier routing table (e.g., BIN routing table). The issuer identifier routing table may be provided to the relevant entities in the payment system (e.g., merchants and acquirers).
  • In some embodiments, a token issuer identifier range (e.g., token BIN range) may be 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) associated with issuing tokens. For example, in some embodiments, one or more token BIN ranges can be allocated to each issuer BIN/card range that is associated with an issuer per card volumes for that range. In some embodiments, the token BIN range and allocation can have the same format and definition of the existing BIN routing table format used by relevant entities in the payment processing system. 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. As such, the non-payment tokens may comprise different token issuer identifiers or may not comprise token issuer identifiers. 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 with the payment system.
  • “Provisioning” may include a process of providing data for use. For example, provisioning may include providing, delivering, or enabling a token on a device. Provisioning may be completed by any entity within or external to the transaction system. For example, in some embodiments, tokens may be provisioned by an issuer or a payment processing network onto a mobile device. The provisioned tokens may have corresponding token data stored and maintained in a token vault or token registry. In some embodiments, a token vault or token registry may generate a token that may then be provisioned or delivered to a device. In some embodiments, an issuer may specify a token range from which token generation and provisioning can occur. Further, in some embodiments, an issuer may generate and notify a token vault of a token.
  • “Token attributes” may include any feature or information about a token. For example, token attributes may include any 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, token attributes may determine how a token may be used in place of a real account identifier (e.g., PAN) for a transaction. For example, the token attributes may include a type of token, frequency of use, token expiration date and/or expiration time, a number of associated tokens, a transaction lifecycle expiration date, and any additional information that may be relevant to any entity within a transaction processing system. 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 generation of tokens. In some embodiments, a network token system, payment processing 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 type of token may include any information or indicator of how a token may be used. For example, a type of token may be “payment” or “non-payment” to identify the token as being a payment token or a non-payment token. A payment token may include a high value token that can be used in place of a real account identifier (e.g., PAN) to generate original and/or subsequent transactions for a consumer account and/or card.
  • Another token type may be a “static” or “dynamic” token type for static and dynamic tokens, respectively. For example, a static token may include a token that may be issued by a payment processing network or issuer that may be issued in place of an account identifier (e.g., PAN) and may be used for the duration of the underlying account identifier (e.g., PAN). As such, static tokens may be used to submit any number of transactions and may not change for each transaction. Static tokens may be securely stored on the consumer device (e.g., stored in a secure memory or secure element of a mobile device) or in the cloud by the token requestor and may be delivered securely to a mobile device. However, static tokens may include sensitive information that may be protected as they may be used to perform multiple transactions over long periods of time.
  • Alternatively, dynamic tokens can include tokens that are limited or restricted in use (e.g., limited by time, amount threshold (aggregated amount or single-transaction amount), or by number of uses). As such, dynamic tokens can be generated and delivered on a per-transaction or on an as needed basis to the end user to initiate a payment transaction through a registered and authenticated device and/or channel. For example, a one-time use dynamic token can be used at electronic-commerce (e-commerce) websites and if the dynamic token is intercepted by a third party, the dynamic token may be useless because it has been used and is thus worthless for future transactions.
  • Non-payment tokens may include tokens which are not substitutes for real account identifiers (e.g., PANs). For example, non-payment tokens may be used by merchant/acquirer systems for analytics, offers, customer support, marketing, etc. However, non-payment tokens may not be used to generate original and subsequent transactions using real account identifiers (e.g., PANs) or other account identifiers. Accordingly, non-payment tokens may include low value tokens that may be used for non-payment transactions or transaction services by an entity within the transaction processing system.
  • A “frequency of use” of a token may indicate how many times a token can be used in a transaction. For example, a frequency of use may indicate how many times a token may successfully be used in a payment transaction. For example, a token may include a frequency of use of single-use or multiple-use. A single-use token may be used to generate one transaction. After the first-use of the single-use token, any subsequent use for initiating a transaction can be deemed invalid and a subsequent transaction may be denied. A multi-use token can be used to initiate multiple transactions.
  • A “real account identifier” may include an original account identifier associated with a 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 (BIN) that may identify an issuer associated with the real account identifier.
  • A “payment token issuer identifier” may include any series of characters, numbers, or other identifiers that may be used to identify an issuer associated with a payment token. For example, a payment token issuer identifier may include a token BIN that identifies a particular issuer associated with an account identified using the token. 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”).
  • 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., QR™ code, bar code, 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 a 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.
  • “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 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).
  • “Token exchange” or “de-tokenization” is a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with an associated primary account number (PAN) that was associated with the payment token during tokenization of the PAN. 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).
  • “Authentication” is a process by which the credential of an endpoint (including but not limited to applications, people, devices, processes, and systems) can be verified to ensure that the endpoint is who they are declared to be.
  • An “original” transaction may include any transaction including an authorization provided by an issuer or an authorization provided on-behalf-of an issuer.
  • A “substitute” transaction may be any transaction that is associated with an original transaction and that takes place after the original transaction, including repeat, refunds, reversals or exceptions (chargebacks, re-presentments, etc.).
  • A “requestor” may be an application, a device, a process, or a system that is configured to perform actions associated with tokens. For example, a requestor can request registration with a network token system, request token generation, token activation. token de-activation, token exchange, other token life-cycle 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). Some non-limiting examples of a requestor may include third party wallet providers, issuers, acquirers, merchants, and/or payment processing networks. A requestor may be referred to as a token requestor when requesting generation of a new token or requesting a new use of an existing token from a network token system. In some embodiments, a token requestor can request tokens for multiple domains and/or channels. Token requestors may include, for example, card-on-file merchants, acquirers, acquirer processors, and payment gateways acting on behalf of merchants, payment enables (e.g., original equipment manufacturers, mobile network operators, etc.), digital wallet providers, and/or card issuers.
  • A “token requestor identifier” may include any characters, numerals, or other identifiers associated with an entity associated with a network token system. For example, a token requestor identifier may be associated with an entity that is registered with the network token system. In some embodiments, a unique token requestor identifier may be assigned for each domain for a token request associated with the same token requestor. For example, a token requestor identifier 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 identifier may include any format or type of information. For example, in one embodiment, the token requestor identifier may include a numerical value such as a ten digit or an eleven digit number (e.g., 4678012345). In some embodiments, a token requestor identifier 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.).
  • An “end-user” may include any application, consumer, process, or system that is configured to interact with a requestor for tokenization/de-tokenization/token management services. For example, an end-user may include a consumer, a merchant, a mobile device, or any other suitable entity that may be associated with a requestor in the network token system.
  • 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, accountholder, or user.
  • A “card-on-file (COF)” holder may include any entities that store account details (e.g., card details, payment account identifiers, PANs, etc.) for use in transactions. For example, a COF entity may store payment information on file for various types of periodic payments such as monthly utility payments, periodic shopping transactions, or any other periodic or future transaction. Because payment credentials and/or associated tokens are stored at an entity for a future transaction, the transactions initiated by a COF entity include card-not-present (CNP) transactions. Another type of card-not-present (CNP) transaction includes e-commerce or electronic commerce transactions that are initiated between remote parties (e.g., a consumer device and a merchant web server computer).
  • An “authorization request message” may be an electronic message that is sent to a payment processing network and/or an issuer of a payment account 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 a payment account. In some embodiments of the invention, an authorization request message may include a payment token, an expiration date, a token presentment mode, a token requestor identifier, an application cryptogram, and an assurance level data. The payment token may include a payment token issuer identifier that may be a substitute for a real issuer identifier for an issuer. For example, the real issuer identifier may be part of a BIN range associated with the issuer. 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), 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, 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 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 terminal) 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 typically be 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. The server computer may be associated with an entity such as a payment processing network, a wallet provider, a merchant, an authentication cloud, an acquirer or an issuer.
  • I. Exemplary Network Token Processing Systems
  • FIG. 1 shows a block diagram of a typical transaction processing system 100 configured to use real issuer identifiers (e.g., bank identification numbers (BINs)) to route authorization request messages during transaction processing. For example, payment credentials issued for consumers may include real issuer identifiers (e.g., BINs) that may be used to identify the issuer (and payment processing network) associated with the account being used to initiate the transaction.
  • The system 100 may include a consumer 110, a consumer device 120, an access device 130, a merchant computer 140, an acquirer computer 150, a payment processing network computer 160 and an issuer computer 170. In some implementations, different entities in FIG. 1 may communicate with each other using one or more communication networks such as the Internet, a cellular network, a TCP/IP network or any other suitable communication network. Note that one or more entities in the system 100 may be associated with a computer apparatus that may be implemented using some of the components as described with reference to FIG. 11.
  • The consumer 110 may be a person or an individual. The consumer 110 may utilize the consumer device 120 to initiate a transaction with a merchant by interacting with the access device 130 (e.g. point-of-sale (POS) device).
  • The consumer device 120 may be associated with a payment account of the consumer 110. In some implementations, the consumer device 120 may be a mobile device such as a mobile phone, a tablet, a PDA, a notebook, a key fob or any suitable mobile device. For example, the consumer device 120 may include a wallet or a payment application that may be associated with one or more payment accounts of the consumer 110. In some implementations, the consumer device 120 may be configured to display a machine readable code (e.g., QR™ code, bar code, etc.). The consumer device 120 may also include a camera or a scanning device capable of scanning a machine readable code. In some implementations, the consumer device 120 may be capable of communicating with the access device 130 using a short range communication technology such as NFC. For example, the consumer 110 may interact with the access device 130 by tapping or waving the consumer device 120 in proximity of the access device 130. In some implementations, the consumer device 120 may be a payment card such as a credit card, debit card, prepaid card, loyalty card, gift card, etc.
  • The access device 130 may be an access point to a transaction processing system that may comprise the acquirer computer 150, the payment processing network computer 160, and the issuer computer 170. In some implementations, the access device 130 may be associated with or operated by the merchant computer 140. For example, the access device 130 may be a point of sale device that may include a contactless reader, an electronic cash register, a display device, etc. In some implementations, the access device 130 may be configured to display transaction information in a format that may be read by the consumer device 120 (e.g., mobile phone) including a QR™ code, bar code, or any other information transfer mechanism. In some implementations, the access device 130 may be a personal computer that may be used by the consumer 110 to initiate a transaction with the merchant computer 140 (e.g., an online transaction).
  • The merchant computer 140 may be associated with a merchant. In some embodiments, the merchant computer 140 may be associated with a card-on-file (COF) merchant. For example, the card-on-file merchant may store consumer account information on file (e.g., at a merchant database) for future payment purposes such as various types of periodic payments (e.g., monthly utilities payments). In some implementations, a consumer may register with one or more merchants for card-on-file services. The merchant computer 140 may be configured to generate an authorization request for a transaction initiated by the consumer 110 using the access device 130.
  • The acquirer computer 150 may represent a traditional acquirer/acquirer processor. The acquirer is typically a system for an entity (e.g., a bank) that has a business relationship with a particular merchant, a wallet provider or another entity. The acquirer computer 150 may be communicatively coupled to the merchant computer 140 and the payment processing network 160 and may issue and manage a financial account for the merchant. The acquirer computer 150 may be configured to route the authorization request for a transaction to the issuer computer 170 via the payment processing network computer 160 and route an authorization response received via the payment processing network computer 160 to the merchant computer 140.
  • The payment processing network computer 160 may be configured to provide authorization services, and clearing and settlement services for payment transactions. The payment processing network computer 160 may include data processing subsystems, wired or wireless networks, including the internet. An example of the payment processing network computer 160 includes VisaNet™, operated by Visa®. 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 Visa Integrated Payments (VIP) system which processes authorization requests and a Base II system which performs clearing and settlement services. The payment processing network computer 160 may include a server computer. In some implementations, the payment processing network computer 160 may forward an authorization request received from the acquirer computer 150 to the issuer computer 170 via a communication channel. The payment processing network computer 160 may further forward an authorization response message received from the issuer computer 170 to the acquirer computer 150.
  • The issuer computer 170 may represent an account issuer and/or an issuer processor. Typically, the issuer computer 170 may be associated with a business entity (e.g., a bank) that may have issued an account and/or payment card (e.g., credit account, debit account, etc.) for payment transactions. In some implementations, the business entity (bank) associated with the issuer computer 170 may also function as an acquirer (e.g., the acquirer computer 150).
  • FIG. 2 illustrates a transaction processing system 200 utilizing a network token system, according to one embodiment of the invention.
  • The system 200 may include a network token system 202 in addition to one or more components of the traditional payment system 100 as shown in FIG. 1. For example, the system 200 may include a consumer 110, a merchant computer 140, an acquirer computer 150, a payment processing network computer 160 and an issuer computer 170. The system 200 may also include token interfaces 208-218 with the network token system 202 including a token requestor interface 208, a merchant token interface 210, an acquirer token interface 212, a payment processing network token interface 214, a network interface 216, and an issuer token interface 218. In some embodiments of the invention, communication amongst different entities of the system 200 may be encrypted. In some embodiments of the invention, different entities in the system 200 may communicate with one another using one or more communication networks such as TCP/IP, cellular network, etc. In one embodiment, a web service environment for the network token system 202 can provide one or more of the communication interfaces with the network token system and may provide services associated with communication including entity authentication, request authorization, message security, etc.
  • The consumer 110 may be able to initiate a transaction using a payment account identifier that may be payment card branded such as Visa®, MasterCard®, American Express®, Discover®, etc. In addition, the consumer 110 may be capable to utilize the consumer device 120 to initiate a transaction using any suitable transaction channel such as through a scan of a mobile device (e.g., using a QR™ code or bar code), a tap of a mobile device to a merchant access device (e.g., near-field communication (NFC) transaction or other contactless/proximity transaction), a click on a computer or other mobile device in order to initiate an e-commerce transaction (e.g., online transaction), or through any other channel in which a transaction may be initiated and a token may be passed to a merchant computer. For example, in some embodiments, a mobile device may be used to initiate a remote transaction from a mobile device with a token provisioned onto a secure element or other secure memory of a mobile device.
  • A token requestor 204 may include an application, a process, a device, or a system that can request a token from the network token system 202. For example, the token requestor 204 can be an issuer, an acquirer, a card-on-file merchant (also referred to as a merchant of record (MOR)), a mobile device (e.g., a wallet application or a payment application installed on the mobile device), a payment enabler, a payment service provider (PSP), a digital wallet provider (also referred to as a mobile wallet provider), an operating system (OS) provider, a telecommunications network provider, or any other entity that may be use a token or store a token for a third party. The token requestor 204 may interact with the network token system 202 using a token requestor interface 208 for the generation, use and management of tokens.
  • In one embodiment, each token requestor 204 may have to undergo an onboarding or registration process to ensure that the token requestor meets integration and security standards in order to use the tokenization services provided by the network token system 202. For example, the network token system 202 may provide services such as card registration, token generation, token issuance, token authentication and activation, token exchange, and token life-cycle management to the registered entities.
  • As part of the onboarding process, the token requestor 204 may register with the network token system 202 and may receive a token requestor identifier provided by the network token system 202. The token requestor 204 may specify configuration preferences or token attributes associated with tokens requested by the token requestor including, for example, token type (e.g., static or dynamic), supported token presentment modes (e.g., scan, contactless, e-commerce, etc.) and any other relevant token configuration information during the onboarding process. Further, the token requestor 204 may include limitations to certain channels (e.g., card-on-file, contactless, etc.) for use of requested tokens.
  • The token processing server computer 202B may generate a unique token requestor identifier for each registered token requestor. Thereafter, the registered token requestor 204 can provide the token requestor identifier as part of every network token service request to the network token system 202 as a form of identification.
  • The network token system 202 can provide registration for each entity that interacts with the network token system.
  • The token requestor 204 may be configured to request a new token or request life-cycle management actions for an existing token (e.g., change an existing token, deactivate a token, etc.). In some embodiments, a token requestor 204 may provide an account identifier (e.g., a PAN) and an expiration date with a request for a new token. The network token system 202 may use the token requestor identifier to identify and validate the token requestor 204 as well as validate a token based transaction when processing a transaction initiated using a token.
  • The network token system 202 may include a token registry database 202A and a token processing server computer 202B. The token registry database 202A may also be referred to as a “token vault.” The token registry database 202A may store and maintain issued or generated tokens as well as any other relevant information to the tokens. For example, the token registry may include a token requestor identifier and an account identifier (e.g., PAN) for each token. The token registry database 202A and the token processing computer 202B may be configured to provide services associated with the token registry including, for example, payment account registration, token generation, token issuance, token authentication and activation, token exchange, token routing, token assurance level generation, token lifecycle management, and token processing to the entities that are registered with the network token system 202. In some embodiments, different entities can communicate with and obtain services provided by the network token system 202 using their respective interfaces with the network token system 202.
  • Tokens in the token registry database 202A may include different token states that may determine whether a token may be used in a transaction as well as the actions necessary to allow a token to be used in a transaction. For example, token states may include active, inactive, suspended, on hold, deactivated, or any other indication of the availability for a token to be used in a transaction. For instance, in some embodiments, a token may be generated by the token vault and may be immediately active and available for transacting. Further, issuers may notify the payment processing network computer 160 or the network token processing server computer of tokens that are “inactive” or not currently in use. In some embodiments, the token value associated with an inactive token may be treated in the same manner as “not found,” by a token processing server computer. A token may be changed to “suspended” which includes a temporary state in which no authorizations or full financial original transactions can be performed with the token. A “deactivated” token status may include a token that may be permanently suspended and no authorizations or full financial original transactions may be performed. In some embodiments, tokens may reflect certain attributes relevant to the account identifier (e.g., PAN) being tokenized. For example, in some embodiments, the token may reflect funding source and the country associated with the underlying account identifier.
  • In some embodiments, the merchant computer 140 and the acquirer computer 150 may be provided with a token in lieu of a real account identifier (e.g., PAN) for various transaction use cases. For example, the merchant computer 140 and/or acquirer computer 150 may receive a token in the traditional PAN field of authorization request message and may forward the authorization request message to the payment processing network computer 160 for processing. The payment processing network computer 160 may replace the token with the real account identifier (e.g., PAN) and send a modified authorization request message to the issuer computer 170. In some embodiments, the authorization request message may further have the token moved to a new field in the authorization message and/or clearing message for the issuer computer 170 to receive so that the issuer may receive both the account identifier (e.g., PAN) and the token in such messages.
  • Accordingly, in some embodiments, the issuer computer 170 may be configured to receive both the real account identifier (e.g., PAN) and the token in the authorization request messages and in transaction clearing messages received from the payment processing network computer 160. Chargebacks and chargeback reversal messages may also contain both the token and the real account identifier (e.g., PAN). In some embodiments, the issuer computer 170 may choose to have the payment processing network computer 160 call out to have the issuer computer 170 provision the tokens. In some embodiments, the issuer computer 170 may provide the payment processing network computer 160 with its current token database via a bulk file interface.
  • In some embodiments, the token requestor interface 208 may be used by the token requestor 204 to interact with the network token system 202. For example, the token requestor 204 may send requests for multiple actions including token issuance, token lifecycle management (e.g., activation, deactivation, account credential update, etc.), and token authentication. In some embodiments, the token requestor interface 208 may include an application programming interface (API) or any other relevant messaging formats may be used. For example, the token requestor 204 may send a token issuance request that includes account information (e.g., a PAN and any other account details) and a token requestor identifier. Additionally, in some embodiments, the token requestor 204 may provide a bulk token request file that includes a plurality of account identifiers (e.g., PANs) and a token requestor identifier. The network token system 202 may generate and return a plurality of tokens, where each token is associated with an account identifier (e.g., PAN) from the bulk file request. In some embodiments, the token requestor 204 may optionally provide one or more token attributes with the request such as, for example, a frequency of use (e.g., single-use or multi-use), a type of token (e.g., payment or non-payment), a token expiration date and/or time, a number of requested tokens, a transaction lifecycle expiration date, etc. In some embodiments, the token request may further include one or more of an MSISDN (Mobile Subscriber Integrated Services Digital Network-Number), an account nickname (e.g., an alias), a UUID (Universally Unique Identifier) associated with the account or consumer, an IMEI (International Mobile Station Equipment Identity), an IMSI (International Mobile Subscriber Identity), a mobile application identifier, a purchase amount, etc. Additionally, in some embodiments, merchants can use the token requestor interface 208 to request for non-payment tokens (e.g., to use in analytics, loyalty, rewards, or any other business related processes).
  • Further, a token requestor 204 may request that the network token system 202 add a token to the account identifier (e.g., PAN) relationship to the token registry database 202A. The token requestor 204 may also request that the network token system 202 change the attributes for a token to account identifier (e.g., PAN) relationship in the token registry database 202A. For example, the token requestor 204 may request that the network token system 202 suspend a token due to the loss of a device by the consumer. The token requestor 204 may request that the network token system 202 deactivate a token in the token registry database 202A. In some embodiments, the corresponding record in the token registry database 202A may be marked deactivated (e.g., no longer valid for new purchases), but may remain available for exception processing for a limited period of time and may then be subsequently removed. In some embodiments, the network token system 202 may purge the tokens that have expired or that have been deactivated for a period of time on a periodic basis. Token requestors may also create batch files of token requests (e.g., add, delete or deactivate) and send them to the network token system 202 on a periodic basis.
  • In some embodiments, the token vault may comprise the following records.
  • In some embodiments of the invention, for NFC token requests, a token requestor identifier, a real account identifier (e.g., PAN), a token expiration date and a token assurance level may be stored in the token vault for each token entry.
  • For card-on-file e-commerce merchant requests, the token requestor interface 208 may be used by the token requestor 204 to interact with the network token system 202. For example, the token request may include whether the request is for a new token, change of an existing token, or deactivation of a token. The token requestor 204 may also provide a token requestor identifier, a PAN, an expiration date, a token type with the token request. In one embodiment, the AVS and CAVV data presented for the identity and verification process may only be used for authentication and is not stored in the token vault.
  • The network token system 202 may generate a token that has the same format as a PAN to minimize disruption across the payment system and has a value that does not collide with any real PAN or an active token. In some embodiments, if a token has not been used in an authorization request by the intended expiration date/time, the token may be reissued by the network token system 202.
  • In some embodiments, the network token system 202 may provide token lifecycle management services to the registered entities. Lifecycle management can be useful when a token is compromised or a payment device is lost. For example, the network token system 202 may de-activate a token and its associations when the token becomes inactive, suspended or temporarily locked. The network token system 202 may deactivate a token by temporarily locking or suspending the token for a specific token requestor. The network token system 202 may also cancel a token to permanently mark a token as deleted to prevent any future transactions. A deleted token can be used during returns/chargebacks if the same token was used to submit the corresponding original transaction for a specific token requestor. The network token system 202 may also update token attributes such as token validity timeframes (e.g., extend or reduce the timeframe) or frequencies of permitted token use. The token validity timeframe can refer to a specific number of days, hours, minutes, or a specific expiration date.
  • In some embodiments, the network token system 202 may allow the registered entities to allow the consumers to update information about the PAN, e.g., assign a different PAN to a static token. For example, the entity may provide a token requestor identifier, an old PAN and a new PAN to the network token system 202 using its interface. The network token system 202 may generate a new static token and associate it to the new PAN. The old token association could then be deactivated.
  • In some embodiments, the network token system 202 may support tokens generated by other entities such as issuers or wallet provider systems. For example, the token registry database 202A may be configured to store the PAN and token mapping and any other attributes for external tokens. The entities can provide the external tokens using their respective interfaces with the network token system 202.
  • In some embodiments, the network token system 202 may allow the registered entities to request CVV2 (Card Verification Value) values (or other types of verification values, cryptograms, etc.) for tokens using their respective interfaces. The network token system 202 may use the token to determine the real account identifier (e.g., a PAN) and can communicate with the payment processing network computer 160 (e.g., using an API) to request CVV2 values associated with the real account identifiers. These CVV2 values may be provided to the requesting entities.
  • In some embodiments of the invention, the network token system 202 may allow the registered entities to provide details of the transactions submitted using tokens using their respective interfaces. For example, a registered entity may provide a token requestor identifier, a transaction identifier, a transaction amount, a transaction date and time, a merchant identifier, a merchant address, an MSISDN, a UUID, an IMEI, etc. This data may be stored in the token registry database 202A. These details may be used for loyalty or other types of programs. For example, the transaction details can be used to identify relevant offers that might be of interest to the consumers conducting the transactions.
  • In some embodiments, the network token system 202 may allow the registered entities to request transactions made using tokens by providing the token requestor identifier, a token or token alias, and a date range (e.g., start and end date). The network token system 202 may provide a list of transactions conducted with the token or the alias within the identified date range.
  • In some embodiments, the network token system 202 may allow the registered entities to request authorization and settlement data for a given token/PAN combination and date range by providing a token requestor identifier, a PAN, a token and a date range.
  • In some embodiments, the network token system 202 may allow the registered entities to request all the tokens and their attributes assigned for a given PAN and a date range by providing a token requestor identifier, a PAN and a date range.
  • In some embodiments, the network token system 202 may allow the registered entities to request details for a specific token and PAN combination by providing a token requestor identifier, a PAN and a date range.
  • In some embodiments, the network token system 202 may provide an interface for e-commerce merchants to integrate into their web applications to initiate token generation requests for card-on-file transactions during checkout processes. For example, e-commerce merchants may provide a token requestor identifier, a PAN (card-on-file), a CVV2, an expiration date and optionally a consumer user identifier used for an e-commerce web application using the merchant token interface 210. The network token system 202 may provide in return a token and dCVV to the merchant computer 140. The token and the dCVV may be validated by the payment processing network computer 160 when it is received from the merchant computer in an authorization request message during a payment transaction.
  • In some embodiments, the network token system 202 may provide an interface for e-commerce merchants to provide an option for the consumers to request a token during checkout to use in place of a PAN. For example, the e-commerce merchants may provide a token requestor identifier, a PAN (card-on-file), a CVV2, an expiration date and optionally the consumer's first and last name, and billing address using the merchant token interface 210. The network token system 202 may authenticate the consumer/PAN before generating a token. The network token system 202 may provide a token and dCVV to the merchant computer. The token and the dCVV may be validated by the payment processing network computer 160 when it is received from the merchant computer in an authorization request message during a payment transaction.
  • In some embodiments, the network token system 202 may provide a user interface for the consumer 110. The user interface may allow the consumer to perform operations such user registration, payment account registration, token request generation, token deactivation, etc. In some embodiments, the network token system 202 may authenticate the consumer 110 and/or the PAN before generating and supplying a token to the consumer 110.
  • In some embodiments, the network token system 202 may provide a notification advice message to notify participating issuers or other entities that one of their consumers has requested a token (e.g., requested that their phone be provisioned with a token) using the network token system provisioning service. The advice message may include a message reason code (e.g., token create, token deactivate, token suspend or token resume), a token number, a token assurance level and a token requestor identifier.
  • In some embodiments, the merchant token interface 210 may allow the merchant computer 140 to communicate with the network token system 202 for tokenization and de-tokenization services such as token exchange, token processing and routing, etc. In some embodiments, the merchant token interface 210 may include an API. For example, the merchant computer 140 may use the merchant token interface 210 to request PAN information associated with a given token from the network token system 202 by providing a token requestor identifier, a token value and a date (e.g., transaction date or date range). In some embodiments, de-tokenization of a token may be requested during authorization and clearing process for a transaction. In some embodiments, the token exchange may be requested for bulk tokens.
  • In some embodiments, the acquirer token interface 212 (which may be in the form of an API) may allow the acquirer computer 150 to communicate with the network token system 202 for tokenization and de-tokenization services. Tokenization and de-tokenization services may include token exchange, token processing and routing, etc. For example, using the acquirer token interface 212, the acquirers may request that the network token system 202 provision a token on their behalf. A merchant, acquirer or a wallet provider may receive the token in response to a provisioning request message originating from an acquirer. The provisioning request message may support card-on-file provisioning and NFC provisioning. For example, the provisioning request message may include a PAN, a transaction amount, a transaction date and time, an expiration date, a merchant type, an acquirer's country code, a POS entry mode code (e.g., manual key entry, contactless device read, etc.), an acquirer's identifier code, an AVS result code, a CVV2 result code, a CAVV result code, CAV data, and any other relevant data.
  • In other embodiments, the acquirer computer 150 may use the acquirer token interface 212 to request PAN information associated with a given token from the network token system 202. This can be accomplished by providing the token along with a token requestor identifier, a token value and a date (e.g., transaction date or date range) to the acquirer token interface 212. In some embodiments, de-tokenization of a token may be requested during authorization and clearing process for a transaction via the acquirer token interface 212. In some embodiments, a token exchange process for bulk tokens can be conducted through the acquirer token interface 212.
  • In some embodiments, the payment processing network token interface 214 may allow the payment processing network computer 160 to communicate with the network token system 202 for tokenization and de-tokenization services such as token exchange, token processing and routing, etc. For example, the payment processing network computer 160 may provide a token to the network token system 202 in exchange for a PAN or vice-versa.
  • In some embodiments, network interface 216 may allow a gateway or other networks 206 (e.g., MasterCard®, American Express®, Discover®, etc.) to communicate with the network token system 202 for tokenization and de-tokenization services via the payment processing network computer 160, e.g., token exchange, token routing, etc. For example, the other networks 206 may interact with the network token system 202 or the issuer computer 170 for the exchange of a token with a PAN for transactions initiated using debit card accounts.
  • In some embodiments, the issuer token interface 218 may allow the issuer computer 170 to communicate with the network token system 202 for tokenization and de-tokenization services, e.g., token registration, token authentication, etc. In some embodiments, the participating issuers may request that the network token system 202 tokenize PANs and manage existing tokens. For example, the issuer computer 170 may provide a request via the issuer token interface 218 that the network token system 2020 create a token, deactivate a token, suspend a token, or resume a token. Further, the issuer token interface may allow an issuer to perform a token inquiry, update an account identifier (e.g., PAN) expiration date, replace an account identifier (e.g., a PAN) associated with a token, or update card art or other information associated with a token (e.g., terms and conditions, etc.). Additionally, the token processing server computer 202B may provide notifications and other information through the issuer token interface 218. For example, the notifications may include token creation notifications, device provisioning notifications, authentication results, and deactivate, suspension, and resuming token notifications.
  • In some embodiments, an issuer may generate and provide tokens to the network token system. For example, an issuer may provide the token to the payment processing network computer 160 to store in the token vault on the issuer's behalf. For example, the issuer computer 170 may provide information such as an account identifier (e.g., PAN), a token, a token assurance level, a token requestor identifier, a token expiration date, a token type, and a state of the token to the token processing server computer 202B. The token processing server computer may validate that there is no conflict with the token (i.e., that a token already exists for that value) and may generate a token entry associated with the provided token information in the token registry database 202A.
  • Additionally, in some embodiments, the issuer computer 170 may request that the payment processing network 160 generate tokens using an issuer's own account range, and not the payment processing network's token range. If the issuer token range does not conflict with another token or account issuer identifier range that is already in use, the token processing server computer 202B may generate an association or linkage between the issuer's token account range and the issuer's real issuer identifier (e.g., BIN) range. In some embodiments, the issuer token interface 218 may allow the issuers to submit bulk registration file containing the tokens generated by the issuer. In some embodiments, if the issuer computer 170 fails to respond to a token request (for individual or bulk requests) in the instances of issuer token provisioning, then the token request to the token requestor 204 may be declined. For example, the token requestor 204 may receive a notification informing the token requester that an issuer timeout has occurred.
  • FIG. 3 illustrates components of the token processing server computer 202B in one embodiment of the invention.
  • The token processing server computer 202B may include a processor 300 communicatively coupled to a network interface 302, a memory 304 and a computer readable medium 306.
  • The processor can comprise a CPU, which comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s). The CPU interacts with memory through signal passing through conductive conduits to execute stored signal program code according to conventional data processing techniques.
  • The network interface 302 may be configured to allow the network token system 202 to communicate with other entities such as the consumer device 120, merchant computer 140, acquirer computer 150, payment processing network computer 160, issuer computer 170, etc. using one or more communications networks. Network interfaces may accept, communicate, and/or connect to a communications network. Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring, wireless connection such as IEEE 802.11a-x, and/or the like. A 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 memory 304 may be used to store data. The memory 304 may be coupled to the processor 300 internally or externally (e.g., cloud based data storage) and may comprise any combination of volatile and/or non-volatile memory, for example, RAM, DRAM, ROM, flash, or any other suitable memory device.
  • The computer readable medium 306 may be in the form of a memory (e.g., flash, ROM, etc.) and may comprise code, executable by the processor 300 for implementing methods described herein. The computer readable medium 306 may include a requestor registration module 308, a card registration module 310, a token generation module 312, a verification and authentication module 314, a token exchange and routing module 316, a token life-cycle management module 318 and, a reporting and administration module 320. The computer readable medium 306 may also comprise code, executable by the processor 300 to implement a method comprising: receiving a first token request message from a first entity; analyzing the first token request message; determining the first token request message includes a request for a token; determining a first token; transmitting the first token to the first entity; receiving a second token request message from a second entity; analyzing the second token request message; determining the second token request message includes a token request associated with the first token; determining token attributes associated with the first token; and transmitting the determined token attributes to the second entity.
  • The requestor registration module 308 may comprise code which can cause the processor 300 to register each token requestor entity with the token registry database 202A and to generate a token requestor identifier for the registered entity. Some non-limiting examples of the token requestor entities may include issuers, wallet providers, payment enablers (e.g., merchant, wallet providers or OEMs having a card-on-file repository), merchants, e-commerce merchants, transit authorities, payment processing networks, acquirers, mobile devices (e.g., wallet application, payment application, etc.), or subcomponents and applications thereof. Each registered entity can use the token requestor identifier as part of each token service request with the network token system 202 which can help identify and validate the entity. In one embodiment, the registered application can provide token requestor information to the requestor registration module 308 such as an entity name, contact information, an entity type (e.g., merchant, wallet provider, payment service provider or PSP, issuer, payment enabler, acquirer, acquirer processor, etc.), token presentment modes (e.g., scan, contactless, e-commerce, etc.), token type (e.g., static/dynamic, payment/non-payment), integration and connectivity parameters, and services subscribed (e.g., token request, authentication and verification, life-cycle management, etc.) and any other relevant information for the onboarding process.
  • Referring back to FIG. 2, in some embodiments, each token requestor 204 can register with the token registry database 202A using the token requestor interface 208. For example, a graphical user interface may be used to provide token requestor information to the network token system 202. The user interface may be a conventional graphic user interface as provided by, with, and/or atop operating systems and/or operating environments such as Apple Macintosh OS, e.g., Aqua, GNUSTEP, Microsoft Windows (NT/XP), Unix X Windows (KDE, Gnome, and/or the like), mythTV, and/or the like. The user interface may allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system facilities through textual and/or graphical facilities. The user interface provides a facility through which users may affect, interact, and/or operate a computer system.
  • The requestor registration module 308 may validate the information and upon successful validation may store the token requestor details in the token registry database 202A. The requestor registration module 308 may also generate a token requestor identifier after successful registration. In one embodiment, the token requestor identifier is a ten digit numerical value. However, other formats of the token requestor identifier are possible. In some embodiments, as part of the registration process, the token registry database 202A may store requestor entity information such as a business identifier, a token requestor identifier, a token requestor type (e.g., payment enabler, merchant of record, merchant, acquirer, issuer, etc.), and a platform type (e.g., a payment enabler mobile application, payment enabler online, merchant application, payment service provider application, issuer wallet application, etc.).
  • The card registration module 310 may comprise code that can be used by the processor 300 to perform card registration by different entities. In some embodiments, the network token system 202 may allow the registered entities to register their payment cards or accounts with the network token system 202 using their respective interfaces. For example, the registered entities may provide a token requestor identifier (e.g., received at the time of registration from the requestor registration module 308), a payment account number, a CVV2, an expiration date, consumer name and contact information, a token type, an OS type/version, and any other relevant information for individual card registration or bulk card registration. In one embodiment, the card registration module 310 may store the details of all of the consumers' account details in the token registry database 202A for all successful activation and registration requests. In one embodiment, the token registry database 202A may store a token requestor identifier, a MSISDN, a payment account number, a CVV2, an expiration date, a PAN nickname or alias, a consumer postal code, a UUID, a IMEA, an IMSI, a mobile application identifier, consumer first and last name, etc. In one embodiment, the registered entities may use their respective interfaces to unregister payment accounts by providing the necessary information to network token system 202.
  • The token generation module 312 may be configured to generate a token in response to a request for a token from a token requestor. In one embodiment, the token generation module 312 may receive a token requestor identifier, an account number (e.g., PAN), an expiration date and a CVV2. In some embodiments, the token generation module 312 may also receive optional information such as a consumer name, a consumer address and zip code, a requested token type (e.g., payment static, payment dynamic, non-payment, etc.), a card verification status (e.g., AVS/CW check status), a MSISDN, a UUID, an IMEI, an OS type/version and any other suitable information. In one embodiment, the token generation module 312 may generate a token response with a token number, a token expiration date and a token assurance level. In one embodiment, the token generation module 312 may validate the token requestor identifier, determine the PAN type and generate a token from the respective token BIN ranges. The token registry database 202A may maintain the correlation between the card and the associated requestor and the token. In one embodiment, the token generation module 312 may determine if a token already exists in the token registry database 202A for the token request before generating a new token. In some embodiments, if a token cannot be provisioned, the token response may include a corresponding reason code. The token generation module 312 may also provide an interface to the token requestors to submit a bulk token request file.
  • In one embodiment, the tokens may be generated on-the-fly via API calls (e.g., using the token requestor interface 208). For example, when a request is received to tokenize a PAN, the token generation module 312 may determine a token range to assign the token. For example, the token range may be assigned based on whether the issuer is provisioning the token (e.g., issuer assigned token range) or the payment processing network is provisioning the token on-behalf-of the issuer (e.g., payment processing network assigned token range). As an example, if the payment processing network assigned token range includes “442400000-442400250”, then “4424000000005382” may be assigned as a token value. The token vault may store the relationship of the token range to the PAN and a token add record may be logged. In some embodiments, the token generation module 312 may consider the token range list associated with the PAN range before assigning a token.
  • In one embodiment, the token generation module 312 may access a token range table that represents available token ranges provisioned by the payment processing network computer 160 and token ranges have not been associated with PAN ranges. The token generation module 312 may access another table that includes minimum and maximum account ranges for the PAN and the associated token ranges. The token ranges may include the token ranges provisioned by the payment processing network computer 160 and the token ranges provisioned by the issuer computer 170.
  • In one embodiment, the merchant token interface 210 may allow the e-commerce merchants to initiate token generation requests for cards-on-file during checkout processes using those cards on file. For example, the token generation module 312 may receive a token requestor identifier, a card-on-file PAN, a CVV2, an expiration date, and optionally a consumer identifier for the e-commerce web application. The token generation module 312 may provide a token and dCVV which may be validated by the payment processing network computer 160 during the authorization process. For example, the token and dCVV may be provided to the merchant computer, which may then generate an authorization request message using the token and dCVV. The payment processing network may then receive the authorization request message and may validate the token and dCVV, or possibly replace the token and dCVV with the real account number and CVV2 value corresponding to the account number.
  • In one embodiment, the merchant token interface 210 may allow the e-commerce merchants to provide an option to the consumer 110 to request a token during checkout in place of the PAN. In such embodiments, the token generation module 312 may authenticate the consumer and/or PAN before generating a token. For example, the token generation module 312 may receive a token requestor identifier, a card-on-file PAN, a CVV2, an expiration date, and optionally a consumer name and billing address, and may provide a token and dCVV to the consumer, which may be validated by the token processing server computer 202B during transit. For example, the token and dCVV may be provided to the consumer's computer, which may be provided to the merchant computer, which may then generate an authorization request message using the token and dCVV. The payment processing network may then receive the authorization request message and may validate the token and dCVV, or possibly replace the token and dCVV with the real account number and CVV2 value corresponding to the account number.
  • The verification and authentication module 314 may be configured to execute a consumer verification and authentication process. For example, the verification and authentication module 314 can perform consumer authentication and verification through a configured authentication scheme. In one embodiment, the authentication scheme may include verification of the payment account number, CVV2 and the expiration date based on the customer information stored in a database associated with the payment processing network. In one embodiment, the authentication scheme may include direct verification of the consumer by the issuer computer 170 with consumer credentials for their online banking system.
  • In one embodiment, the authentication scheme may include verification of the consumer credentials through the issuer ACS (Access Control Server). For example, the issuer ACS service may be part of an authentication protocol such as 3-D secure protocol by Visa®. The ACS server may be associated with the issuer computer 170 that may include registered consumer account and access information. The ACS can give issuers the ability to authenticate consumers during an online purchase, thereby reducing the likelihood of fraudulent use of payment accounts. For example, the ACS can validate that the consumer is registered, performs consumer verification at the time of the transaction and provides digitally signed responses to the merchants.
  • In one embodiment, the authentication scheme may include verification of the payment account using a payment processing network consumer authentication service (e.g., Visa™ Consumer Authentication Service (VCAS)). For example, the VCAS service can authenticate the consumer on-behalf of the issuer prior to the authorization process.
  • In some embodiments, the authentication scheme may be based on the use of OTP (One time Password) or zero dollar authorization request message. For example, the OTP may be provided to the consumer 110 by the payment processing network computer 160 or the issuer computer 170. The consumer 110 can utilize the consumer device 120 to provide the OTP to the network token system 202 for authentication. In other embodiments of the invention, a zero dollar authorization request message may be sent by a merchant computer 140 to the issuer computer 170 via the acquire computer 150 and the payment processing network computer 160 to verify the identity of the consumer and/or the validity of a payment account. In one embodiment, a zero dollar transaction (i.e., an authorization request message with a zero dollar amount) may be used to verify the payment account number, any personal identifier (e.g., a PIN), address, and/or verification values (e.g., CVV, CVV2, or other variants, etc.).
  • In some embodiments, requests to provision tokens may combine consumer authentication requests with the token request. For example, authentication may be performed prior to tokenization using any of the previously discussed authentication methods. In the authentication methods, where the issuer computer 170 performs the authentication, tokenization may be performed after receiving an authentication response from the issuer computer 170.
  • In some embodiments, account or card registration, token generation, and verification and authentication may be performed as part of a single token request process. In some embodiments, for bulk requests, card registration and token generation may be performed by processing a bulk file from the token requestor 204. In such embodiments, consumer verification and authentication may be performed in a separate step. In some embodiments, the token requestor 204 can request that the authentication and verification process be performed independently multiple times for a particular card or account to reflect any changes to the levels of assurance for the token over time.
  • The token exchange and routing module 316 may comprise code, executable by the processor, to cause the processor to allow registered applications to request payment account number information for a given token. For example, the payment processing network 160, acquirer computer 150, etc, may issue a request for a token exchange during a payment transaction. In one embodiment, a registered entity can provide at least one, two or more of a token requestor identifier, a token number, a token expiration date, a token presentment mode, a transaction identifier, a transaction timestamp, a request timestamp and any other relevant information to request the payment account number information. The token exchange and routing module 316 may validate that the requesting entity is entitled to make a request for a token exchange. In one embodiment, the token exchange and routing module 316 may validate the PAN/token mapping and presentment mode based on the request timestamp and the token expiration timestamp. The token exchange and routing module 316 may retrieve the payment account number information from the token registry database 202A and provide it along with the assurance level to the requestor entity. In one embodiment, if the PAN/token mapping is not valid for the requested timestamp and presentment mode, an error message may be provided.
  • The token life-cycle management module 318 may comprise code, executable by the processor 300 to perform lifecycle operations. Lifecycle operations may include canceling a token, activating or deactivating a token, updating token attributes, renewing token with a new PAN expiration date, etc. In one embodiment, a token requestor entity may provide a token requestor identifier, a token number, a lifecycle operation identifier and one or more token attributes to the network token system 202 to perform the requested lifecycle operation on the given token. The token life-cycle management module 318 may verify the token requestor identifier and the token association based on the token registry database 202A. The token life-cycle management module 318 may perform the requested lifecycle operation on the given token number and update all the corresponding association in the token registry database 202A.
  • The token requestor 204 request a lifecycle operation using an interface. The lifecycle operation may be associated with a lost or stolen consumer device, a compromised payment account number or the token, a change in the payment account number, unsubscribing a card-on-file, etc. In another example of a lifecycle operation, a token activation operation may be requested to activate an inactive, suspended or temporarily locked token and its associations. A token de-activation operation may be requested to temporarily lock or suspend a token. A cancel token operation may be requested to permanently mark a token and its associations as deleted to prevent any future transactions. In some embodiments, a deleted token may be used during returns/chargebacks if the same token was used to submit the corresponding original transactions. A token update operation may be requested to update token attributes such as expiration date (e.g., extend or reduce the validity timeframe), timestamp, frequency of usage (based on token details provided), etc. Validity timeframe can be number of days/hours/minutes or specific expiration date.
  • In some embodiments, the network token system 202 may allow consumers to request update the association between a PAN and a static token. For example, the consumer 110 may request that his PAN be updated. This update can occur through the token requestor interface 208 or the issuer computer 170 may request that the PAN be updated via the issuer token interface 218. The registered entity may provide a token requestor identifier, the old PAN and optionally the new PAN to the token life-cycle management module 318, which can associate the new PAN to the static token or can generate a new static token for the new PAN.
  • The reporting and administration module 316 may allow the token requestors to request transaction details made using tokens by providing a token requestor identifier, a token or PAN alias and a transaction date range (e.g. a start and end date). In one embodiment, the network token system 202 may retrieve all the token transactions from the payment processing network 160 and maintain in a date store to provide the transaction details to the requesting registered entity to handle returns, chargebacks and disputes and to support analytics. The reporting and administration module 316 may provide the transaction details made using the given tokens (or tokens associated to the given PAN alias) between the given date range.
  • In some embodiments, the reporting and administration module 316 may allow the registered entities to request authorization and settlement data from a given token/PAN combination and date range. In some embodiments, the reporting and administration module 316 may allow the registered entities to request all the tokens and their attributes assigned for a given PAN and from a given date range.
  • The token assurance module 322 may be configured to determine a token assurance level associated with the token generated by the token generation module 312. The token assurance level may be determined based on the outcome of the verification and authentication performed by the verification and authentication module 314. The token assurance level may indicate assurance information associated with the token, such as an assurance indicator (e.g., requestor, network, issuer, ACS, other), an entity that performed the assurance (e.g., requestor, network issuer, others), a date the assurance was performed, a wallet/consumer device identification, an assurance level score (based on authentication method used) and any other relevant information. The token assurance module 322 can determine the token assurance level at the time of the token request, or may determine the token assurance level at a later time. The token assurance level can be used for additional risk assessment by the payment processor network or the issuer.
  • In some embodiments, token assurance level may include assurance information such as an assurance indicator, an entity that performed the authentication or assurance process (e.g., requestor, network issuer, others), the date that the assurance processing was performed, a wallet/consumer device identification indicator, an assurance level score (based on authentication method used), and any other information relevant to assurance.
  • Some examples of the token assurance information include, but is not limited to, an indication that the token has not been authenticated, an indication that the token is network authenticated, an indication that the token is issuer authenticated, or any other indication of how the token, cardholder, and/or card credential was authenticated. The token processing server computer 202B may record the token assurance level once the token vault records the authentication via verification and authentication module 314.
  • In some embodiments, the payment processing network 160 may track the token assurance level based on the authentication and request for a token binding. This may be used to inform the issuer that the token has been verified using additional authentication techniques. Further details regarding the token assurance level are described below.
  • II. Communicating Risk Using Token Assurance Data
  • FIGS. 4A-4B illustrate exemplary authentication methods to determine token assurance level in one embodiment of the invention.
  • The token assurance level may be performed by the network token system 202 to authenticate the consumer, card credentials or the token at the time of the token request or afterwards. Referring back to FIG. 3, the token assurance level may be determined by the token assurance module 322. The token assurance level may be used for additional risk assessment by the payment processing network computer 160 or the issuer computer 170. For example, an assurance level code may be passed in the authorization request message to inform the level of assurance for that token in the transaction.
  • In step 402, the token requestor 204 may send a token request 402 to the token registry database 202A. The token request 402 may include a PAN, an expiration date, a CVV2, a full address of the consumer 110, a postal code and a token requestor identifier. For example, the token request 402 may be a request for a token from the consumer device 120 (e.g., a wallet application) to initiate a transaction.
  • In step 404, the network token system 202 may provide a token response including a token assurance level, a token number and a token expiration date based on one or more authentication methods such as, but not limited to, a CVV2 check, an AVS check, a zero dollar authorization, a payment processing network OBO (on behalf of), a 3DS (3D Secure) extension issuer ACS (access control server) or a 3DS (3D Secure) extension issuer OTP (one time password), as described below. It can be appreciated that the network token system 202 may provide the token response including the token assurance level after authenticating the cardholder using the one or more authentication methods. Each of the authentication methods are described in further detail below in transaction flows 1-6.
  • Transaction flow 1 illustrates a CVV2 check authentication method. In step 1A, when the token requestor 204 sends the token request 402, the token requestor 204 may also send the PAN associated with the payment account, the expiration date and a CVV2 value to the token vault 202A which may in turn send them to the payment processing network computer 160 for a CVV2 check. This information may have been provided by the user to the token requestor 204 prior to the token request 402. For example, the CVV2 value may be a security code associated with a payment card (e.g., three digit code printed on the card).
  • In step 1B, the payment processing network computer 160 may perform the CVV2 check and send a response message to the token registry 202A to approve or decline authorization of the user. For example, the payment processing network computer 160 may compare the CVV2 value provided by the consumer 120 with the CVV2 value on record (e.g., stored in the database of the payment processing network computer 160). If the CVV2 value matches what is stored in the database, the payment processing network computer 160 may authorize the user. When the token processing server computer 202B generates the token, the token processing server computer 202B may realize that the user has been authenticated using a CVV2 check by the payment processing network computer 160 and may determine a token assurance level accordingly.
  • Transaction flow 2 illustrates an AVS check authentication method. In step 2A, when the token requestor 204 sends the token request 402, the requestor 204 may also send the PAN, expiration date, full address and the postal code associated with the cardholder to the token vault 202A which may in turn send them to the payment processing network computer 160. This information may have been provided by the cardholder (e.g., user) to the token requestor 204 prior to the token request 402. The AVS check enables elements of the billing address and the postal code provided by the consumer 110 to be compared against the issuer's records.
  • In step 2B, the payment processing network computer 160 may forward the PAN, expiration date, full address and the postal code to the issuer computer 170 for the AVS check.
  • In step 2C, the issuer computer 170 may perform the AVS check and may send a response message to the payment processing network computer 160 to approve or decline authorization of the user, for example, by comparing the billing address and the postal code provided by the consumer 110 with the data on record. For example, if the billing address and postal code provided match the data on record, the issuer computer 170 may authorize the user (e.g., cardholder or consumer).
  • In step 2D, the payment processing network computer 160 may forward the response message to the token registry 202A. When the token processing server computer 202B generates the token, the token processing server computer 202B may realize that the user has been authenticated using an AVS check by the payment processing network computer 160 and may determine a token assurance level accordingly.
  • Transaction flow 3 illustrates a zero dollar authorization authentication method. In step 3A, when the token requestor 204 sends the token request 402, the token requestor 204 may also send the PAN and the expiration date to the payment processing network computer 160 for a zero dollar authorization transaction. This information may have been provided by the user to the token requestor 204 prior to the token request 402.
  • In step 3B, the payment processing network computer 160 may forward the PAN, expiration date and the card-on-file indicator to the issuer computer 170 for zero dollar authorization.
  • In step 3C, the issuer computer 170 may perform the zero dollar authorization and may send a response message to the payment processing network computer 160 to approve or decline authorization of the user. For example, the issuer computer 170 may perform verification of the payment account number, personal identifier, address verification, and a card verification value (CVV, CVV2, or other variants, etc.) as part of the zero-dollar authorization.
  • In step 3D, the payment processing network computer 160 may forward the response message to the token registry 202A. When the token processing server computer 202B generates the token, the token processing server computer 202B may realize that the user has been authenticated using an zero dollar authorization by the payment processing network computer 160 and may determine a token assurance level accordingly.
  • Transaction flow 4 illustrates a payment processing network OBO authentication method. In step 4A, when the token requestor 204 sends the token request 402, the token requestor 204 may also send the PAN and the expiration date to the token processing server computer 202B to perform the payment processing network authorization OBO. This information may have been provided by the user to the token requestor 204 prior to the token request 402.
  • In step 4B, the token processing server computer 202B may validate the PAN and the expiration date on-behalf-of the issuer and send a response message to the token registry 202A to approve or decline authorization of the user accordingly. For example, if the PAN and expiration date can be verified on-behalf-of the issuer, the token processing server computer 202B may authorize the user. When the token processing server computer 202B generates the token, the token processing server computer 202B may realize that the user has been authenticated using a payment processing network OBO check by the token processing server computer 202B and may determine a token assurance level accordingly.
  • Transaction flow 5 illustrates a 3D Secure extension issuer ACS authentication method. In step 5A, when the token requestor 204 sends the token request 402, the token requestor 204 may also send the PAN and the expiration date associated with the payment account directly to the issuer computer 170 for a 3DS extension issuer ACS check. This information may have been provided by the user to the token requestor 204 prior to the token request 402.
  • In step 5B, the issuer computer 170 may perform the ACS check and send a response message to the token registry database 202A to approve or decline authorization of the user. For example, the issuer computer 170 may query an appropriate ACS to authenticate the data with the data provided by the consumer 110 at the time of enrollment. If the user can be authenticated using the ACS, the issuer computer 170 may approve authorization of the user. When the token processing server computer 202B generates the token, the token processing server computer 202B may realize that the user has been authenticated using a 3D Secure extension issuer ACS check by the payment processing network computer 160 and may determine a token assurance level accordingly.
  • Transaction flow 6 illustrates a 3D Secure extension issuer OTP authentication method. In step 6A, when the token requestor 204 sends the token request 402, the token requestor 204 may also send the PAN, expiration date and a one-time password (OTP) to the issuer computer 170 for a 3DS (3D Secure) extension issuer OTP (one time password) check. This information, with the exception of the OTP, may have been provided by the user to the token requestor 204 prior to the token request 402.
  • In step 6B, the issuer computer 170 may provide the generated OTP (one time password) to the consumer device 120.
  • In step 6C, the consumer device 120 may provide the OTP (one time password) to the token requestor 204. For example, the token requestor 204 may be a mobile or a wallet application. The cardholder may have entered the OTP into the mobile or wallet application running on the consumer device 120.
  • In step 6D, the token requestor 204 may provide the OTP (one time password) to the token registry database 202A for validation of the OTP.
  • In step 6E, the token registry database 202A may verify the OTP and send a message to notify the issuer computer 170 to approve or decline the authentication of the user. For example, if the OTP received matches the generated OTP, the issuer computer 170 may authenticate the user. When the token processing server computer 202B generates the token, the token processing server computer 202B may realize that the user has been authenticated using a 3D Secure extension issuer OTP check by the payment processing network computer 160 and may determine a token assurance level accordingly.
  • It can be appreciated that transaction flows 1-6 described above may occur in between steps 402 and steps 404. The token assurance levels described above may be represented in the form of a token assurance level field code that may be part of an authorization request message or an authorization response message. The token assurance level code can indicate how the cardholder, card credential, and the token have been authenticated by the payment network. For example, the token assurance level code can indicate which of the above authentication methods were used to authenticate the cardholder when the token was requested and ultimately generated. These authentication methods include, but is not limited to, a CVV2 check, an AVS check, a zero dollar authorization, a payment processing network OBO, a 3DS extension issuer ACS, and a 3DS extension issuer OTP. During the course of a normal payment transaction, the token assurance level code can be used by the issuer 170 for additional risk assessment and to obtain a certain level of confidence that the user using the token is in fact the genuine cardholder.
  • In some embodiments, the token assurance level code may be a 2-digit number that indicates the token assurance level. For example, the token assurance level code may range from 00-99, with 00 being the lowest token assurance level and 99 being the highest token assurance level. It can be appreciated that any other indication scheme can be used for the token assurance level code.
  • The use of a token assurance level code to communicate risk within the payment network can have many advantages. First, the use of the token assurance level code can increase security within the payment network, particularly for payment transactions including the use of a token. Since the issuer 170 (and potentially other entities within the payment network) may be able to reference the token assurance level code in order to obtain a certain level of confidence that the token was legitimately generated and that it is being used by the genuine cardholder, the chances of approving a fraudulent transaction can be greatly reduced. Second, the use of a token assurance level code may, in some cases, increase efficiency of the payment network. If an authorization request message is received by the issuer 170 that includes token assurance level code that indicates a relatively high token assurance level, the issuer 170 may simple authorize the transaction without the need for carrying out further authentication of the user and/or token. It can be appreciated that the use of the token assurance level code to communicate risk can provide many other advantageous described throughout this description.
  • Further advantages of using the token assurance level code to communicate risk within the payment network can be further illustrated in the examples described below.
  • FIG. 5 illustrates an exemplary transaction flow for near-field communication (NFC) at the point-of-sale (POS) according to some embodiments of the invention.
  • An authorization process 1102 for a transaction conducted at the POS using NFC may include steps 502A-502G.
  • The authorization process 502 may begin when a user wises to conduct a transaction with a merchant. In step 502A, the NFC terminal at the merchant computer 140 may capture data from the user's consumer device 120 when the consumer device 120 is tapped or waved at the NFC terminal. For example, referring back to FIG. 1, the NFC terminal may be part of the access device 130 that may be communicatively coupled to the merchant computer 140. In one embodiment of the invention, in an off-line process, an issuer may have registered as a token requestor with the token vault and may have provisioned a token in a wallet application of the consumer device 120 (e.g., an NFC enabled cell phone). The consumer 110 may use the consumer device 120 to make a payment. The merchant computer 140 may capture a token, a token expiration date, a chip cryptogram and a POS entry mode from the consumer device 120. In one embodiment, a token requestor identifier may be hidden in the chip cryptogram data. The captured token may have been generated prior to the current transaction using any of the methods described in the description above.
  • In step 502B, the merchant computer 502B may generate an authorization request message with the captured data and provide it to the acquirer computer 150. The authorization request message may include additional fields such as transaction data, merchant identifier and any other relevant data. This data may include the token, token expiration date, chip cryptogram, and POS entry mode.
  • In step 502C, the authorization request message may be conveyed to the payment processing network computer 160 by the acquirer computer 150. The authorization request message may include the token, token expiration date, chip cryptogram, and POS entry mode.
  • In step 502D, the payment processing network computer 160 may decrypt the portions of the CHIP data containing the token requestor identifier and send the chip data, the token, the token expiration date, the token requestor identifier, a token assurance level, a PAN and a PAN expiration date to the issuer computer 170. For example, the payment processing network computer 160 may exchange the token for the PAN from the token vault and modify the authorization request message to include the PAN in place of the token before providing to the issuer computer 170. The modified authorization request message may also include the token requestor identifier and the token assurance level. Before sending the modified authorization request message to the issuer computer 170, the payment processing network computer 160 may validate that the token is being properly used in the correct domain. In some embodiments, the validation may be bypassed if the token assurance level is above a threshold assurance level.
  • In 502E, the issuer computer 170 may make an approval decision after receiving the modified authorization request message and send an authorization response message to the payment processing network 160. The approval decision may at least be based on the token assurance level code in the authorization request message. The token assurance level may indicate to the issuer computer 570 how the cardholder, card credential, and token have been authenticated by the token requestor. The token assurance level may be based on a number of factors.
  • One factor may include the assurance indicator which indicates which entity in the payment network authorized the user for the token generation. For example, the user may have been authorized for the token generation by the token requestor, payment processing network computer 560, issuer 570, an ACS, or other entity. It can be appreciated that authorization by certain entities may affect the token assurance level more or less than authorization by other entities. For example, if the authorization was performed by the issuer computer 570, the token assurance level code may indicate a higher token assurance level than if the authorization was performed by the token requestor itself.
  • Another factor may include the date the date that the token was generated. Tokens generated closer to the date of the current transaction may have higher token assurance levels than those generated farther apart from the date of the current transaction. It can be appreciated that the token vault and/or token processor may keep a real-time record of the token assurance level associated with the token. The token assurance level may be updated at any time for a number of reasons pertaining to a number of variables, one of which may include how long ago the token was generated.
  • Another factor may include the wallet/device identification. The wallet/device identification may indicate which digital wallet and/or which device the token was generated for. Tokens generated for digital wallets and/or devices known to be more secure may have higher token assurance levels.
  • Another factor may include the number of successful (e.g., non-fraudulent) transactions that have been completed using the particular token. A greater number of successful transactions completed using the token may result in a higher token assurance level for the token. In some embodiments, the token vault and/or token processor may increase the token assurance level for the token upon each successful transaction, or vice versa.
  • The token assurance level as indicated by the token assurance level code may be determined based on a combination of any of the factors described above. The combination of factors may result in a determination of the overall token assurance level. The token assurance level may be updated at any time.
  • The approval decision may be made by the issuer based on the token assurance level. If the token assurance level is relatively low and below a threshold the issuer has set for approving a transaction, the transaction may be denied. If the token assurance level is relatively high and above a threshold the issuer has set for approving a transaction, the transaction may be approved. In some embodiments, the issuer may base its approval/denial decision on the token assurance level combined with various other factors. For example, even if a token assurance level is low, if the token was received by the issuer computer 570 via a secure domain, the issuer computer 570 may still approve the transaction. In some embodiments, if the token assurance level is low, the issuer computer 570 may carry out further authentication procedures in order to attempt to authenticate the user and the token for the transaction, instead of simply denying the transaction.
  • In some embodiments, the newly added fields (e.g., token assurance level) may be required to be “retained and returned” in the transaction.
  • In 502F, the payment processing network 160, upon receiving the response, may swap the PAN for the token, optionally populate the last four digits of the PAN in the authorization response message, and return the token assurance level in the modified authorization response message to the acquirer computer 150. The modified authorization response message may also include a PAN product identifier.
  • In 502G, the acquirer computer 150 may forward the authorization response message to the merchant computer 540.
  • A clearing and exception process 504 may include steps 504A-504D as described below. For example, the clearing and exception process may be performed by a clearing module to reconcile the transaction order.
  • In step 504A, the acquirer computer 150 may submit a clearing draft message with the token in the PAN field, along with CHIP data to the payment processing network 160. The clearing draft message may also include a token assurance level.
  • In step 504B, the clearing process at the payment processing network 160 may recognize the token and replace the token with the real PAN (e.g., from the token vault) in the clearing draft to the issuer computer 170. The clearing process may place the token in a new field in the clearing draft message to the issuer computer 170, also populating the token assurance level.
  • In step 504C, should a chargeback occur, the issuer computer 170 may retain and return the token as well as the PAN to the payment processing network 160. In some embodiments, liability for the chargeback may fall on various entities in the payment network based upon the token assurance level. For example, if an entity proceeded with the transaction despite a low token assurance level, the liability for the chargeback may fall on that entity.
  • In step 504D, the clearing process may move the token to the PAN field and drop the real PAN from the clearing draft message to the acquirer computer 150.
  • FIG. 6 illustrates shows an exemplary flow diagram for card-on-file/e-commerce transaction according to one embodiment of the invention.
  • In step 602A, the consumer 110 may make a purchase using the consumer device 120. As an off-line process, prior to the transaction, the merchant (e.g., online merchant) may have registered for a token requestor identifier. Also as an off line process, the merchant may batch request all of their PANs, getting a corresponding token. In this implementation, the token may be related to a specific merchant.
  • In step 602B, the merchant computer 140 may initiate an authorization request message to the acquirer computer 150. When the authorization is initiated, the merchant/acquirer may provide a token in place of the PAN and a token expiration date.
  • In step 602C, the acquirer computer 150 may forward the authorization request message to the payment processing network computer 160.
  • In step 602D, the payment processing network computer 160 may recognize that the token is from a token enabled merchant and replace the token with the real PAN (e.g., from the token vault) and send the token in a new field, the token requestor identifier, and token assurance level and the PAN to the issuer computer 170 in a modified authorization request message. The token requestor identifier and token assurance level may be optional for issuers.
  • In 602E, the issuer computer 170 may make an approval decision and send an authorization response message to the payment processing network 160. The newly added fields (e.g., token assurance level) may be required to be “retained and returned” in the transaction.
  • In 602F, the payment processing network 160, upon receiving the response, may swap the PAN for the token, optionally populate the last four digits of the PAN in the authorization response message, and return the token assurance level in the modified authorization response message to the acquirer computer 150. The modified authorization response message may also include a PAN product identifier.
  • In 602G, the acquirer computer 150 may forward the authorization response message to the merchant computer 602G.
  • A clearing and exception process 604 may include steps 604A-604D as described below. For example, as discussed with reference to FIG. 5, the clearing and exception process may be performed by the clearing module 518 to reconcile the transaction order.
  • In step 604A, the acquirer computer 150 may submit a clearing draft message with the token in the PAN field, along with CHIP data to the payment processing network 160. he clearing draft message may also include a token assurance level.
  • In step 604B, the clearing process at the payment processing network 160 may recognize the token and replace the token with the real PAN (e.g., from the token vault) in the clearing draft message to the issuer computer 170. The clearing process may place the token in a new field in the clearing draft message to the issuer computer 170, also populating the token assurance level.
  • In step 604C, should a chargeback occur, the issuer computer 170 may retain and return the token as well as the PAN to the payment processing network 160.
  • In step 604D, the clearing process may move the token to the PAN field and drop the real PAN from the clearing draft message to the acquirer computer 150.
  • It can be appreciated that FIG. 6 is similar to FIG. 5 except that FIG. 6 illustrates a card-on-file transaction instead of an NFC-based transaction. The processes and methods described with respect to token assurance levels apply in their entirety to FIG. 6. It can be appreciated that some of the data passed in authorization request messages differs to what is shown in FIG. 5 because a card-on-file transaction may be associated with different data than an NFC-based transaction.
  • FIG. 7 is a flowchart of an exemplary method 700 for transmitting a token assurance level code to an issuer or other entity, in accordance with some embodiments of the invention. In block 702, an authorization request message including a payment token is received. The payment token may be associated with a real account identifier. In some embodiments, the authorization request message is received by a server computer from a merchant computer. In some embodiments, before receiving the authorization request message, the payment token may be generated and provided to the server computer by an issuer.
  • In block 704, after receiving the authorization request message, the real account identifier associated with the payment token is determined.
  • In block 706, after determining the real account identifier associated with the payment token, a modified authorization request message including the real account identifier is generated. The modified authorization request message may include the real account identifier and a token assurance level code indicative of a level of risk associated with the payment token. The level of risk may indicate whether the payment token was requested by a genuine account holder of the underlying payment account associated with the real account identifier. The token assurance level code may also indicate an authentication method associated with generation of the payment token. The authentication method can include, but is not limited to, no authentication, network authentication, or issuer authentication. Additionally, the token assurance level code may be based at least in part on a transaction history associated with the real account identifier. In some embodiments, the token assurance level code is generated at the time the payment token is generated.
  • In block 708, after generating the modified authorization request message, the modified authorization request message is transmitted to an issuer for approval. The issuer approval may be based at least in part on the token assurance level code.
  • The network token system as discussed with different embodiments provides a platform that can be leveraged by external entities (e.g., third party wallets, e-commerce merchants, payment enablers/payment service providers, etc.) or internal payment processing network systems that have the need to use the token to facilitate payment transactions. In embodiments of the invention, a token can support interoperability and can be accepted, processed and routed by the entities within the payment system. Embodiments of the invention can help card issuers and merchants improve card security or enable new payment experiences through tokenization.
  • The various participants and elements described herein with reference to FIGS. 1 and 2 may operate one or more computer apparatuses to facilitate the functions described herein. Any of the elements in FIGS. 1 and 2, including any servers or databases, may use any suitable number of subsystems to facilitate the functions described herein.
  • Examples of such subsystems or components are shown in FIG. 8. The subsystems shown in FIG. 8 are interconnected via a system bus 810. Additional subsystems such as a printer 830, keyboard 818, fixed disk 820 (or other memory comprising computer readable media), monitor 812, which is coupled to display adapter 814, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller 824 (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as serial port 816. For example, serial port 816 or external interface 822 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 via system bus allows the central processor 828 to communicate with each subsystem and to control the execution of instructions from system memory 826 or the fixed disk 820, as well as the exchange of information between subsystems. The system memory 826 and/or the fixed disk 820 may embody a computer readable medium.
  • 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.
  • The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
  • One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.
  • A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
  • All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.

Claims (20)

What is claimed is:
1. A method, comprising:
receiving, by a server computer, an authorization request message comprising a payment token, wherein the payment token is associated with a real account identifier;
determining, by the server computer, the real account identifier associated with the payment token;
generating, by the server computer, a modified authorization request message comprising the real account identifier, wherein the modified authorization request comprises a token assurance level code indicative of a level of confidence associated with the payment token; and
transmitting, by the server computer, the modified authorization request message to an issuer for approval.
2. The method of claim 1, wherein the issuer approval is based at least in part on the token assurance level code.
3. The method of claim 1, wherein the level of confidence associated with the payment token comprises a level of confidence that the payment token was requested by an account holder of an underlying payment account associated with the real account identifier.
4. The method of claim 1, wherein the token assurance level code indicates an authentication method associated with the payment token.
5. The method of claim 4, wherein the authentication method comprises at least one of: no authentication, network authentication, or issuer authentication.
6. The method of claim 1, wherein the token assurance level code is based at least in part on a transaction history associated with the real account identifier.
7. The method of claim 1, wherein the authorization request message is received by the server computer from a merchant computer.
8. The method of claim 1, further comprising:
receiving an authorization response message from the issuer;
generating a modified authorization response message comprising the payment token and the token assurance level code; and
transmitting the modified authorization response message to a merchant computer.
9. The method of claim 1, wherein before receiving the authorization request message, the payment token is generated and provided to the server computer by an account issuer.
10. The method of claim 9, wherein the token assurance level code is generated at the time the payment token is generated.
11. A server computer comprising a processor and a computer readable medium comprising code, executable by the processor, for implementing a method comprising:
determining, by the server computer, the real account identifier associated with the payment token;
generating, by the server computer, a modified authorization request message comprising the real account identifier, wherein the modified authorization request comprises a token assurance level code indicative of a level of confidence associated with the payment token; and
transmitting, by the server computer, the modified authorization request message to an issuer for approval.
12. The server computer of claim 11, wherein the issuer approval is based at least in part on the token assurance level code.
13. The server computer of claim 11, wherein the level of confidence associated with the payment token comprises a level of confidence that the payment token was requested by an account holder of an underlying payment account associated with the real account identifier.
14. The server computer of claim 11, wherein the token assurance level code indicates an authentication method associated with the payment token.
15. The server computer of claim 14, wherein the authentication method comprises at least one of: no authentication, network authentication, or issuer authentication.
16. The server computer of claim 11, wherein the token assurance level code is based at least in part on a transaction history associated with the real account identifier.
17. The server computer of claim 11, wherein the authorization request message is received by the server computer from a merchant computer.
18. The server computer of claim 11, wherein the method further comprises:
receiving an authorization response message from the issuer;
generating a modified authorization response message comprising the payment token and the token assurance level code; and
transmitting the modified authorization response message to a merchant computer.
19. The server computer of claim 11, wherein before receiving the authorization request message, the payment token is generated and provided to the server computer by an account issuer.
20. The server computer of claim 11, wherein the token assurance level code is generated at the time the payment token is generated.
US14/340,344 2013-07-24 2014-07-24 Systems and methods for communicating risk using token assurance data Pending US20150032625A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US201361858087P true 2013-07-24 2013-07-24
US201361863863P true 2013-08-08 2013-08-08
US201461935036P true 2014-02-03 2014-02-03
US14/340,344 US20150032625A1 (en) 2013-07-24 2014-07-24 Systems and methods for communicating risk using token assurance data

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US14/340,344 US20150032625A1 (en) 2013-07-24 2014-07-24 Systems and methods for communicating risk using token assurance data

Publications (1)

Publication Number Publication Date
US20150032625A1 true US20150032625A1 (en) 2015-01-29

Family

ID=52391319

Family Applications (4)

Application Number Title Priority Date Filing Date
US14/340,464 Active US9996835B2 (en) 2013-07-24 2014-07-24 Systems and methods for communicating token attributes associated with a token vault
US14/340,444 Pending US20150032626A1 (en) 2013-07-24 2014-07-24 Systems and methods for interoperable network token processing
US14/340,344 Pending US20150032625A1 (en) 2013-07-24 2014-07-24 Systems and methods for communicating risk using token assurance data
US15/974,599 Pending US20180285864A1 (en) 2013-07-24 2018-05-08 Systems and methods for communicating token attributes associated with a token vault

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US14/340,464 Active US9996835B2 (en) 2013-07-24 2014-07-24 Systems and methods for communicating token attributes associated with a token vault
US14/340,444 Pending US20150032626A1 (en) 2013-07-24 2014-07-24 Systems and methods for interoperable network token processing

Family Applications After (1)

Application Number Title Priority Date Filing Date
US15/974,599 Pending US20180285864A1 (en) 2013-07-24 2018-05-08 Systems and methods for communicating token attributes associated with a token vault

Country Status (10)

Country Link
US (4) US9996835B2 (en)
EP (2) EP3025293A4 (en)
JP (2) JP2016535517A (en)
KR (1) KR20160035028A (en)
CN (2) CN105874495A (en)
AU (4) AU2014292980A1 (en)
CA (2) CA2918788A1 (en)
RU (2) RU2681366C2 (en)
SG (4) SG10201800629WA (en)
WO (2) WO2015013522A1 (en)

Cited By (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150254650A1 (en) * 2014-03-04 2015-09-10 Bank Of America Corporation Controlling token issuance based on exposure
US20160098548A1 (en) * 2014-10-03 2016-04-07 Wells Fargo Bank, N.A. Setting an authorization level at enrollment
US9317848B2 (en) 2009-05-15 2016-04-19 Visa International Service Association Integration of verification tokens with mobile communication devices
US20160217459A1 (en) * 2015-01-28 2016-07-28 American Express Travel Related Services Company, Inc. Systems and methods for smart token allocation scheme
US20160283942A1 (en) * 2015-03-27 2016-09-29 Ca. Inc. Payment de-tokenization with risk evaluation for secure transactions
WO2016172432A1 (en) * 2015-04-24 2016-10-27 Capital One Services, Llc One use wearable
US20160335639A1 (en) * 2015-05-13 2016-11-17 Mastercard International Incorporated System and methods for enhanced approval of a payment transaction
US9516487B2 (en) 2013-11-19 2016-12-06 Visa International Service Association Automated account provisioning
US9524501B2 (en) 2012-06-06 2016-12-20 Visa International Service Association Method and system for correlating diverse transaction data
US9530131B2 (en) 2008-07-29 2016-12-27 Visa U.S.A. Inc. Transaction processing using a global unique identifier
US20170006008A1 (en) * 2015-06-30 2017-01-05 United States Postal Service System and method of providing identity verification services
US9547769B2 (en) 2012-07-03 2017-01-17 Visa International Service Association Data protection hub
US9582801B2 (en) 2009-05-15 2017-02-28 Visa International Service Association Secure communication of payment information to merchants using a verification token
US9589268B2 (en) 2010-02-24 2017-03-07 Visa International Service Association Integration of payment capability into secure elements of computers
US9600817B2 (en) 2014-03-04 2017-03-21 Bank Of America Corporation Foreign exchange token
US9600844B2 (en) 2014-03-04 2017-03-21 Bank Of America Corporation Foreign cross-issued token
FR3043232A1 (en) * 2015-11-03 2017-05-05 Orange Method of identity verification at a virtualization
US9665722B2 (en) 2012-08-10 2017-05-30 Visa International Service Association Privacy firewall
EP3176741A1 (en) * 2015-12-02 2017-06-07 Eckoh UK Limited Tokenisation in cardholder - not - present transactions
US9680942B2 (en) 2014-05-01 2017-06-13 Visa International Service Association Data verification using access device
US9704155B2 (en) 2011-07-29 2017-07-11 Visa International Service Association Passing payment tokens through an hop/sop
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US9721248B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation ATM token cash withdrawal
US9727858B2 (en) 2012-07-26 2017-08-08 Visa U.S.A. Inc. Configurable payment tokens
US9741051B2 (en) 2013-01-02 2017-08-22 Visa International Service Association Tokenization and third-party interaction
US9780953B2 (en) 2014-07-23 2017-10-03 Visa International Service Association Systems and methods for secure detokenization
US20170286945A1 (en) * 2014-12-10 2017-10-05 American Express Travel Related Services Company, Inc. Form factor with an alias code and a secure chip id
US9792611B2 (en) 2009-05-15 2017-10-17 Visa International Service Association Secure authentication system and method
US9830595B2 (en) 2012-01-26 2017-11-28 Visa International Service Association System and method of providing tokenization as a service
US9830597B2 (en) 2014-03-04 2017-11-28 Bank Of America Corporation Formation and funding of a shared token
US9846878B2 (en) 2014-01-14 2017-12-19 Visa International Service Association Payment account identifier system
US9846861B2 (en) 2012-07-25 2017-12-19 Visa International Service Association Upstream and downstream data conversion
US9848052B2 (en) 2014-05-05 2017-12-19 Visa International Service Association System and method for token domain control
WO2017218479A1 (en) * 2016-06-15 2017-12-21 Mastercard International Incorporated System and method of tokenizing deposit account numbers for use at payment card acceptance point
WO2018029564A1 (en) * 2016-08-09 2018-02-15 Auvercloud System and method for authentication of a user of an application system by a central server, without using a password
US9904919B2 (en) 2009-05-15 2018-02-27 Visa International Service Association Verification of portable consumer devices
US9911118B2 (en) 2012-11-21 2018-03-06 Visa International Service Association Device pairing via trusted intermediary
EP3281164A4 (en) * 2015-04-10 2018-03-07 Visa International Service Association Browser integration with cryptogram
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
WO2018052855A1 (en) * 2016-09-14 2018-03-22 Visa International Service Association Self-cleaning token vault
US9942043B2 (en) 2014-04-23 2018-04-10 Visa International Service Association Token security on a communication device
US9959531B2 (en) 2011-08-18 2018-05-01 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US9972005B2 (en) 2013-12-19 2018-05-15 Visa International Service Association Cloud-based transactions methods and systems
US9978062B2 (en) 2013-05-15 2018-05-22 Visa International Service Association Mobile tokenization hub
US9978094B2 (en) 2013-10-11 2018-05-22 Visa International Service Association Tokenization revocation list
US9996835B2 (en) 2013-07-24 2018-06-12 Visa International Service Association Systems and methods for communicating token attributes associated with a token vault
US9998978B2 (en) 2015-04-16 2018-06-12 Visa International Service Association Systems and methods for processing dormant virtual access devices
US10015147B2 (en) 2014-10-22 2018-07-03 Visa International Service Association Token enrollment system and method
US10026087B2 (en) 2014-04-08 2018-07-17 Visa International Service Association Data passed in an interaction
EP3259876A4 (en) * 2015-02-17 2018-07-25 Visa International Service Association Token and cryptogram using transaction specific information
US10043178B2 (en) 2007-06-25 2018-08-07 Visa International Service Association Secure mobile payment system
US10049353B2 (en) 2014-08-22 2018-08-14 Visa International Service Association Embedding cloud-based functionalities in a communication device
US10078832B2 (en) 2011-08-24 2018-09-18 Visa International Service Association Method for using barcodes and mobile devices to conduct payment transactions
US10096009B2 (en) 2015-01-20 2018-10-09 Visa International Service Association Secure payment processing using authorization request
US10116447B2 (en) 2015-02-17 2018-10-30 Visa International Service Association Secure authentication of user and mobile device
US10121129B2 (en) 2011-07-05 2018-11-06 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
EP3295400A4 (en) * 2015-05-11 2018-11-07 Mastercard Asia/Pacific Pte. Ltd. Method and system for rewarding customers in a tokenized payment transaction
US10140615B2 (en) 2014-09-22 2018-11-27 Visa International Service Association Secure mobile device credential provisioning using risk decision non-overrides
US10147089B2 (en) 2012-01-05 2018-12-04 Visa International Service Association Data protection with translation
US10154084B2 (en) 2011-07-05 2018-12-11 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
EP3414869A4 (en) * 2016-02-12 2018-12-19 Visa International Service Association Authentication systems and methods using location matching
US10164996B2 (en) 2015-03-12 2018-12-25 Visa International Service Association Methods and systems for providing a low value token buffer
US10176478B2 (en) 2012-10-23 2019-01-08 Visa International Service Association Transaction initiation determination system utilizing transaction data elements
WO2019009990A1 (en) * 2017-07-05 2019-01-10 Mastercard International Incorporated System and methods for accepting dual function payment credential
US10192216B2 (en) 2012-09-11 2019-01-29 Visa International Service Association Cloud-based virtual wallet NFC apparatuses, methods and systems
WO2019040807A1 (en) * 2017-08-25 2019-02-28 Mastercard International Incorporated Systems and methods for minimizing user interactions for cardholder authentication
US10223730B2 (en) 2011-09-23 2019-03-05 Visa International Service Association E-wallet store injection search apparatuses, methods and systems
US10223710B2 (en) 2013-01-04 2019-03-05 Visa International Service Association Wearable intelligent vision device apparatuses, methods and systems
WO2019051360A1 (en) * 2017-09-11 2019-03-14 Jpmorgan Chase Bank, N.A. Systems and methods for token vault synchronization
US10243958B2 (en) 2016-01-07 2019-03-26 Visa International Service Association Systems and methods for device push provisoning
US10242358B2 (en) 2011-08-18 2019-03-26 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US10257185B2 (en) 2014-12-12 2019-04-09 Visa International Service Association Automated access data provisioning
US10255591B2 (en) 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
US10255456B2 (en) 2014-09-26 2019-04-09 Visa International Service Association Remote server encrypted data provisioning system and methods
US10262001B2 (en) 2012-02-02 2019-04-16 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia merchant analytics database platform apparatuses, methods and systems
US10268635B2 (en) 2016-06-17 2019-04-23 Bank Of America Corporation System for data rotation through tokenization
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
US10289999B2 (en) 2005-09-06 2019-05-14 Visa U.S.A. Inc. System and method for secured account numbers in proximity devices
US10304047B2 (en) 2012-12-07 2019-05-28 Visa International Service Association Token generating component
US10313321B2 (en) 2016-04-07 2019-06-04 Visa International Service Association Tokenization of co-network accounts
US10325261B2 (en) 2014-11-25 2019-06-18 Visa International Service Association Systems communications with non-sensitive identifiers
US10341111B2 (en) 2018-08-21 2019-07-02 Visa International Service Association Secure authentication of user and mobile device

Families Citing this family (71)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160294879A1 (en) * 2009-05-06 2016-10-06 Cointrust, Inc. Resource protection using tokenized information
SG193510A1 (en) 2011-02-22 2013-10-30 Visa Int Service Ass Universal electronic payment apparatuses, methods and systems
US9264237B2 (en) * 2011-06-15 2016-02-16 Microsoft Technology Licensing, Llc Verifying requests for access to a service provider using an authentication component
US20140164243A1 (en) * 2012-12-07 2014-06-12 Christian Aabye Dynamic Account Identifier With Return Real Account Identifier
US9715689B1 (en) 2012-12-17 2017-07-25 Wells Fargo Bank, N.A. Interoperable mobile wallet refund
US20150006384A1 (en) * 2013-06-28 2015-01-01 Zahid Nasiruddin Shaikh Device fingerprinting
GB201315314D0 (en) * 2013-08-28 2013-10-09 Mastercard International Inc Value add service for mobile point of sale
US9953311B2 (en) 2013-09-25 2018-04-24 Visa International Service Association Systems and methods for incorporating QR codes
US20150100477A1 (en) * 2013-10-09 2015-04-09 The Toronto-Dominion Bank Systems and methods for providing tokenized transaction accounts
CA2927052A1 (en) 2013-10-11 2015-04-16 Visa International Service Association Network token system
US9647999B2 (en) 2014-02-07 2017-05-09 Bank Of America Corporation Authentication level of function bucket based on circumstances
US9208301B2 (en) 2014-02-07 2015-12-08 Bank Of America Corporation Determining user authentication requirements based on the current location of the user in comparison to the users's normal boundary of location
US9223951B2 (en) 2014-02-07 2015-12-29 Bank Of America Corporation User authentication based on other applications
US9965606B2 (en) 2014-02-07 2018-05-08 Bank Of America Corporation Determining user authentication based on user/device interaction
US9213974B2 (en) 2014-02-07 2015-12-15 Bank Of America Corporation Remote revocation of application access based on non-co-location of a transaction vehicle and a mobile device
US9390242B2 (en) 2014-02-07 2016-07-12 Bank Of America Corporation Determining user authentication requirements based on the current location of the user being within a predetermined area requiring altered authentication requirements
US9286450B2 (en) 2014-02-07 2016-03-15 Bank Of America Corporation Self-selected user access based on specific authentication types
US9305149B2 (en) 2014-02-07 2016-04-05 Bank Of America Corporation Sorting mobile banking functions into authentication buckets
US9406065B2 (en) 2014-03-04 2016-08-02 Bank Of America Corporation Customer token preferences interface
US20150254646A1 (en) * 2014-03-04 2015-09-10 Bank Of America Corporation Restoring or reissuing of a token based on user authentication
US10002352B2 (en) 2014-03-04 2018-06-19 Bank Of America Corporation Digital wallet exposure reduction
US20150254648A1 (en) * 2014-03-04 2015-09-10 Bank Of America Corporation Managed digital wallets
US9424572B2 (en) 2014-03-04 2016-08-23 Bank Of America Corporation Online banking digital wallet management
US9721268B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation Providing offers associated with payment credentials authenticated in a specific digital wallet
US20150286997A1 (en) * 2014-04-02 2015-10-08 Facebook, Inc. Routing payments to payment aggregators
US20150310425A1 (en) * 2014-04-29 2015-10-29 Mastercard International Incorporated Systems and Methods of Processing Payment Transactions Using One-Time Tokens
US20150317613A1 (en) * 2014-04-30 2015-11-05 Mastercard International Incorporated Systems and methods for providing anonymized transaction data to third-parties
US10070310B2 (en) * 2014-05-08 2018-09-04 Visa International Service Association Method and system for provisioning access data to mobile device
US20160094991A1 (en) * 2014-05-08 2016-03-31 Glenn Powell Method and system for provisioning access data to mobile device
US20150339663A1 (en) * 2014-05-21 2015-11-26 Mastercard International Incorporated Methods of payment token lifecycle management on a mobile device
US9292875B1 (en) 2014-09-23 2016-03-22 Sony Corporation Using CE device record of E-card transactions to reconcile bank record
US9646307B2 (en) 2014-09-23 2017-05-09 Sony Corporation Receiving fingerprints through touch screen of CE device
US9378502B2 (en) 2014-09-23 2016-06-28 Sony Corporation Using biometrics to recover password in customer mobile device
US10262316B2 (en) 2014-09-23 2019-04-16 Sony Corporation Automatic notification of transaction by bank card to customer device
US9558488B2 (en) 2014-09-23 2017-01-31 Sony Corporation Customer's CE device interrogating customer's e-card for transaction information
US9317847B2 (en) 2014-09-23 2016-04-19 Sony Corporation E-card transaction authorization based on geographic location
US9953323B2 (en) 2014-09-23 2018-04-24 Sony Corporation Limiting e-card transactions based on lack of proximity to associated CE device
US9367845B2 (en) 2014-09-23 2016-06-14 Sony Corporation Messaging customer mobile device when electronic bank card used
US9355424B2 (en) * 2014-09-23 2016-05-31 Sony Corporation Analyzing hack attempts of E-cards
US20160189123A1 (en) * 2014-12-31 2016-06-30 Fiserv, Inc. Card account identifiers associated with conditions for temporary use
US20160217456A1 (en) * 2015-01-26 2016-07-28 International Business Machines Corporation Resource account application management
US10296885B2 (en) * 2015-03-06 2019-05-21 Mastercard International Incorporated Extended-length payment account issuer identification numbers
US9600819B2 (en) 2015-03-06 2017-03-21 Mastercard International Incorporated Systems and methods for risk based decisioning
US20160267459A1 (en) * 2015-03-11 2016-09-15 Paypal, Inc. NFC Application Registry for Enhanced Mobile Transactions and Payments
US20160267480A1 (en) * 2015-03-12 2016-09-15 Paypal Inc. Replaying Tokenized Payment Transactions
US20160321652A1 (en) * 2015-04-30 2016-11-03 James Dimmick Tokenization Capable Authentication Framework
EP3308289A4 (en) * 2015-06-15 2019-02-20 Cointrust Inc Resource protection using tokenized information
WO2016205645A1 (en) * 2015-06-19 2016-12-22 Moreton Paul Y Systems and methods for managing electronic tokens for device interactions
EP3136329A1 (en) * 2015-08-28 2017-03-01 Mastercard International Incorporated Securing mo/to processing
US10068213B2 (en) * 2015-09-09 2018-09-04 Mastercard International Incorporated Systems and methods for facilitating cross-platform purchase redirection
CA2997379A1 (en) * 2015-10-15 2017-04-20 Visa International Service Association Instant token issuance system
US9729536B2 (en) 2015-10-30 2017-08-08 Bank Of America Corporation Tiered identification federated authentication network system
JP2017107343A (en) 2015-12-08 2017-06-15 キヤノン株式会社 Authentication cooperation system, authentication cooperation method, authorization server, and program
JP2017107342A (en) * 2015-12-08 2017-06-15 キヤノン株式会社 Authentication cooperation system, authentication cooperation method, authorization server, application server, and program
CN108604989A (en) * 2016-02-01 2018-09-28 维萨国际服务协会 Systems and methods for code display and use
US10282726B2 (en) 2016-03-03 2019-05-07 Visa International Service Association Systems and methods for domain restriction with remote authentication
US10148729B2 (en) 2016-03-22 2018-12-04 Go Daddy Operating Company, LLC Hosting provider hosting routes from a media repository
US10291612B2 (en) * 2016-03-22 2019-05-14 Go Daddy Operating Company, LLC Bi-directional authentication between a media repository and a hosting provider
CN105894380A (en) * 2016-04-05 2016-08-24 邓迪 Digital currency credit investigation system and method
US20170293912A1 (en) * 2016-04-12 2017-10-12 Digicash Pty Ltd. Secure transaction controller for value token exchange systems
WO2018010009A1 (en) * 2016-07-13 2018-01-18 Royal Bank Of Canada Processing of electronic transactions
KR20180032223A (en) * 2016-07-20 2018-03-30 코나아이 (주) A server, method and system for managing card transaction service
CN109564662A (en) * 2016-08-12 2019-04-02 维萨国际服务协会 Mirror image token safe-deposit vault
US20180053182A1 (en) * 2016-08-18 2018-02-22 Gaurav Srikant Mokhasi Dynamic cryptocurrency aliasing
EP3297242B1 (en) * 2016-09-20 2018-09-05 Deutsche Telekom AG A system and a method for providing a user with an access to different services of service providers
JP6144815B1 (en) * 2016-11-29 2017-06-07 Line株式会社 An information processing method, information processing apparatus and an information processing program
US20180324184A1 (en) * 2017-05-02 2018-11-08 Venkata Naga Pradeep Kumar Kaja System and method using interaction token
US10313480B2 (en) 2017-06-22 2019-06-04 Bank Of America Corporation Data transmission between networked resources
US20190020478A1 (en) * 2017-07-14 2019-01-17 Aparna Girish Token provisioning utilizing a secure authentication system
WO2019055523A1 (en) * 2017-09-13 2019-03-21 Onvocal, Inc. System and method for improved point of sale and crm network interface
WO2019074326A1 (en) * 2017-10-12 2019-04-18 Samsung Electronics Co., Ltd. Method and apparatus for secure offline payment

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US20020120584A1 (en) * 2000-04-11 2002-08-29 Hogan Edward J. Method and system for conducting secure payments over a computer network without a pseudo or proxy account number
US20030028481A1 (en) * 1998-03-25 2003-02-06 Orbis Patents, Ltd. Credit card system and method
US20030101348A1 (en) * 2001-07-12 2003-05-29 Russo Anthony P. Method and system for determining confidence in a digital transaction
US20030120554A1 (en) * 2001-03-09 2003-06-26 Edward Hogan System and method for conducting secure payment transactions
US20060235795A1 (en) * 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions
US8613055B1 (en) * 2013-02-22 2013-12-17 Ping Identity Corporation Methods and apparatus for selecting an authentication mode at time of issuance of an access token
US8682802B1 (en) * 2011-11-09 2014-03-25 Amazon Technologies, Inc. Mobile payments using payment tokens

Family Cites Families (444)

* Cited by examiner, † Cited by third party
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
US7177835B1 (en) 1997-08-28 2007-02-13 Walker Digital, Llc Method and device for generating a single-use financial account number
US6163771A (en) 1997-08-28 2000-12-19 Walker Digital, Llc Method and device for generating a single-use financial account number
US5883810A (en) 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
US6000832A (en) 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy 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
US6453306B1 (en) 1998-01-26 2002-09-17 Ict Software S.A. Internet commerce method and apparatus
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
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
BR0008315A (en) * 1999-02-18 2002-06-18 Orbis Patents Ltd System and credit card validation method
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
AU6229000A (en) 1999-07-26 2001-02-13 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
EP1245009A1 (en) 1999-12-17 2002-10-02 Chantilley Corporation Limited Secure transaction systems
US7426750B2 (en) 2000-02-18 2008-09-16 Verimatrix, Inc. Network-based content distribution system
AU3994501A (en) 2000-02-29 2001-09-12 Scoring Inc E Systems and methods enabling anonymous credit transactions
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
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
AU4347301A (en) 2000-03-07 2001-09-17 American Express Travel Relate System for facilitating a transaction
US6999943B1 (en) 2000-03-10 2006-02-14 Doublecredit.Com, Inc. Routing methods and systems for increasing payment transaction volume and profitability
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
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
EP1269429A2 (en) 2000-03-15 2003-01-02 Mastercard International, Inc. Method and system for secure payments over a computer network
JP2010165374A (en) * 2000-03-29 2010-07-29 Risk Monster Kk System for anonymity electronic commerce having crediting function and method
JP2001344545A (en) * 2000-03-29 2001-12-14 Ibm Japan Ltd Processing system, server, processing terminal, communication terminal, processing method, data managing method, processing performing method and program
US7379919B2 (en) 2000-04-11 2008-05-27 Mastercard International Incorporated Method and system for conducting secure payments over a computer network
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
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
US7778934B2 (en) * 2000-04-17 2010-08-17 Verisign, Inc. Authenticated payment
US6592044B1 (en) 2000-05-15 2003-07-15 Jacob Y. Wong Anonymous electronic card for generating personal coupons useful in commercial and security transactions
US7650314B1 (en) 2001-05-25 2010-01-19 American Express Travel Related Services Company, Inc. System and method for securing a recurrent billing transaction
AU6510701A (en) 2000-05-26 2001-12-11 Interchecks Llc Methods and systems for network based electronic purchasing system
WO2001093129A1 (en) * 2000-05-29 2001-12-06 Enet Ltd. Credit information inquiry system and credit information inquiry method
JP2002007921A (en) * 2000-06-23 2002-01-11 Hitachi Ltd Credit card payment method using internet
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
AU8698501A (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
US7890393B2 (en) 2002-02-07 2011-02-15 Ebay, Inc. Method and system for completing a transaction between a customer and a merchant
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
WO2002077745A2 (en) 2001-03-26 2002-10-03 Wolfram Johannes Bernd Reiners Transaction authorisation system
US20020147913A1 (en) 2001-04-09 2002-10-10 Lun Yip William Wai Tamper-proof mobile commerce system
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
US7543739B2 (en) 2003-12-17 2009-06-09 Qsecure, Inc. Automated payment card fraud detection and location
US8060448B2 (en) 2001-05-30 2011-11-15 Jones Thomas C Late binding tokens
JP4363800B2 (en) 2001-06-11 2009-11-11 ソニー株式会社 E-commerce support device, e-commerce support method, and computer program
JP2002366869A (en) * 2001-06-11 2002-12-20 Sony Corp Electronic commerce assisting method and electronic commerce method using the same
US20060237528A1 (en) 2001-07-10 2006-10-26 Fred Bishop Systems and methods for non-traditional payment
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
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
US7195154B2 (en) * 2001-09-21 2007-03-27 Privasys, Inc. Method for generating customer secure card numbers
US7103576B2 (en) 2001-09-21 2006-09-05 First Usa Bank, Na System for providing cardless payment
US7805376B2 (en) 2002-06-14 2010-09-28 American Express Travel Related Services Company, Inc. Methods and apparatus for facilitating a transaction
US6901387B2 (en) 2001-12-07 2005-05-31 General Electric Capital Financial Electronic purchasing method and apparatus for performing the same
US7904360B2 (en) 2002-02-04 2011-03-08 Alexander William EVANS System and method for verification, authentication, and notification of a transaction
AUPS087602A0 (en) 2002-03-04 2002-03-28 Ong, Yong Kin (Michael) Electronic fund transfer system
WO2003083619A2 (en) 2002-03-29 2003-10-09 Bank One, Delaware, N.A. System and process for performing purchase transaction using tokens
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
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
EP1504393A4 (en) 2002-04-23 2008-03-19 Clearing House Service Company Payment identification code and payment system using the same
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
US7801826B2 (en) 2002-08-08 2010-09-21 Fujitsu Limited Framework and system for purchasing of goods and services
US7353382B2 (en) 2002-08-08 2008-04-01 Fujitsu Limited Security framework and protocol for universal pervasive transactions
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
EP1579298A4 (en) 2002-11-05 2006-08-09 Aaron Whiteman 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
WO2005001618A2 (en) * 2003-06-04 2005-01-06 Mastercard International Incorporated Customer authentication in e-commerce transactions
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
RU2263347C2 (en) * 2003-11-04 2005-10-27 Общество с ограниченной ответственностью "Мобилити" Method for performing transactions of users of mobile communication devices and computerized cashless transaction system for realization of said method
US20050108178A1 (en) 2003-11-17 2005-05-19 Richard York Order risk determination
US20050149440A1 (en) * 2003-12-23 2005-07-07 Leslie Michelassi Systems and methods for routing requests for reconcilement information
CN1914895B (en) 2004-01-20 2018-03-09 黄金富 Use telephone banking security money interlocking computer accounting systems and payment methods
US20110029504A1 (en) * 2004-12-03 2011-02-03 King Martin T Searching and accessing documents on private networks for use with captures from rendered documents
US20090006262A1 (en) 2006-12-30 2009-01-01 Brown Kerry D Financial transaction payment processor
GB0407369D0 (en) 2004-03-31 2004-05-05 British Telecomm Trust tokens
WO2005119607A2 (en) 2004-06-03 2005-12-15 Tyfone, Inc. System and method for securing financial transactions
WO2005119608A1 (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
US8996423B2 (en) 2005-04-19 2015-03-31 Microsoft Corporation Authentication for a commercial transaction using a mobile module
US7849020B2 (en) 2005-04-19 2010-12-07 Microsoft Corporation Method and apparatus for network transactions
CN102368325A (en) 2005-04-19 2012-03-07 微软公司 Network commercial transactions
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
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
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
US9065643B2 (en) 2006-04-05 2015-06-23 Visa U.S.A. Inc. System and method for account identifier obfuscation
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
US8478898B2 (en) 2005-11-09 2013-07-02 Ca, Inc. System and method for routing directory service operations in a directory service network
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
US20070170247A1 (en) 2006-01-20 2007-07-26 Maury Samuel Friedman Payment card authentication system and method
CA2640620A1 (en) 2006-01-30 2007-08-02 Cpni Inc. A system and method for authorizing a funds transfer or payment using a phone number
WO2007145687A1 (en) 2006-02-21 2007-12-21 Weiss Kenneth P Method and apparatus for secure access payment and identification
US8234220B2 (en) 2007-02-21 2012-07-31 Weiss Kenneth P Universal secure registry
EP1999715A4 (en) 2006-03-02 2014-07-09 Visa Int Service Ass 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
US20070245414A1 (en) 2006-04-14 2007-10-18 Microsoft Corporation Proxy Authentication and Indirect Certificate Chaining
US20080201264A1 (en) 2007-02-17 2008-08-21 Brown Kerry D Payment card financial transaction authenticator
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
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US20080015988A1 (en) 2006-06-28 2008-01-17 Gary Brown Proxy card authorization system
US20090117883A1 (en) * 2006-07-20 2009-05-07 Dan Coffing Transaction system for business and social networking
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
US9123042B2 (en) 2006-10-17 2015-09-01 Verifone, Inc. Pin block replacement
WO2008059465A2 (en) 2006-11-16 2008-05-22 Net 1 Ueps Technologies, Inc. Secure financial transactions
US7848980B2 (en) 2006-12-26 2010-12-07 Visa U.S.A. Inc. Mobile payment system and method using alias
US7841539B2 (en) 2007-02-15 2010-11-30 Alfred Hewton Smart card with random temporary account number generation
US20080223918A1 (en) 2007-03-15 2008-09-18 Microsoft Corporation Payment tokens
US20080243702A1 (en) 2007-03-30 2008-10-02 Ricoh Company, Ltd. Tokens Usable in Value-Based Transactions
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
US7896238B2 (en) 2007-04-03 2011-03-01 Intellectual Ventures Holding 32 Llc Secured transaction using color coded account identifiers
US8156543B2 (en) 2007-04-17 2012-04-10 Visa U.S.A. 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
US7841523B2 (en) 2007-05-17 2010-11-30 Shift4 Corporation Secure payment card transactions
US7891563B2 (en) 2007-05-17 2011-02-22 Shift4 Corporation Secure payment card transactions
US7770789B2 (en) 2007-05-17 2010-08-10 Shift4 Corporation Secure payment card transactions
EP2156397B1 (en) 2007-05-17 2019-06-26 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
US8355982B2 (en) 2007-08-16 2013-01-15 Verifone, Inc. Metrics systems and methods for token transactions
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
US8352323B2 (en) 2007-11-30 2013-01-08 Blaze Mobile, Inc. Conducting an online payment transaction using an NFC enabled mobile communication device
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
US20090160617A1 (en) 2007-12-24 2009-06-25 Dynamics Inc. Credit, security, debit cards and the like with buttons
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 for authentication and signature of a user to an application service using a mobile phone as a second factor supplement and independently of a first factor
US8255971B1 (en) 2008-03-03 2012-08-28 Jpmorgan Chase Bank, N.A. Authentication system and method
GB0804803D0 (en) * 2008-03-14 2008-04-16 British Telecomm Mobile payments
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
JP2009301211A (en) * 2008-06-11 2009-12-24 Ntt Docomo Inc Sales promotion cost dynamic management system, token management server, mobile terminal, and sales promotion cost dynamic management method
US8321670B2 (en) 2008-07-11 2012-11-27 Bridgewater Systems Corp. Securing dynamic authorization messages
US20100010930A1 (en) * 2008-07-11 2010-01-14 American Express Travel Related Services Company, Inc. Providing a real time credit score as part of a transaction request
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
US20120317035A1 (en) 2009-01-22 2012-12-13 First Data Corporation Processing transactions with an extended application id and dynamic cryptograms
US10037524B2 (en) 2009-01-22 2018-07-31 First Data Corporation Dynamic primary account number (PAN) and unique key per card
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
CA2697921A1 (en) 2009-03-27 2010-09-27 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
US20100274653A1 (en) 2009-04-28 2010-10-28 Ayman Hammad Notification social networking
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
US9105027B2 (en) 2009-05-15 2015-08-11 Visa International Service Association Verification of portable consumer device for secure services
US10140598B2 (en) 2009-05-20 2018-11-27 Visa International Service Association Device including encrypted data for expiration date and verification value creation
CN101562621B (en) * 2009-05-25 2013-05-22 阿里巴巴集团控股有限公司 User authorization method and system and device thereof
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
US20110046969A1 (en) 2009-08-24 2011-02-24 Mark Carlson Alias hierarchy and data structure
US20110083018A1 (en) 2009-10-06 2011-04-07 Validity Sensors, Inc. Secure User Authentication
US8447699B2 (en) 2009-10-13 2013-05-21 Qualcomm Incorporated Global secure service provider directory
WO2011047042A2 (en) 2009-10-13 2011-04-21 Square, Inc. Systems and methods for dynamic receipt generation with environmental information
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
US20110237224A1 (en) 2009-10-23 2011-09-29 Apriva, Llc System and device for facilitating remote invocation of personal token capabilities
US8661258B2 (en) 2009-10-23 2014-02-25 Vasco Data Security, Inc. Compact security device with transaction risk level approval capability
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
US10255591B2 (en) * 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
US8739262B2 (en) 2009-12-18 2014-05-27 Sabre Glbl 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
US20130054470A1 (en) 2010-01-08 2013-02-28 Blackhawk Network, Inc. System for Payment via Electronic Wallet
BR112012017881A2 (en) 2010-01-19 2016-05-03 Visa Int Service Ass method readable media for non-transitory computer and system
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
US8458487B1 (en) 2010-03-03 2013-06-04 Liaison Technologies, Inc. System and methods for format preserving tokenization of sensitive information
US9245267B2 (en) 2010-03-03 2016-01-26 Visa International Service Association Portable account number for consumer payment account
WO2011112502A1 (en) 2010-03-07 2011-09-15 Gilbarco Inc. Fuel dispenser payment system and method
US8776204B2 (en) 2010-03-12 2014-07-08 Alcatel Lucent Secure dynamic authority delegation
US8402555B2 (en) 2010-03-21 2013-03-19 William Grecia Personalized digital media access system (PDMAS)
US8887308B2 (en) 2010-03-21 2014-11-11 William Grecia Digital cloud access (PDMAS part III)
US8533860B1 (en) 2010-03-21 2013-09-10 William Grecia Personalized digital media access system—PDMAS part II
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
US8332322B2 (en) * 2010-05-07 2012-12-11 Miicard Limited Method of establishing identity validation based on an individual's ability to access multiple secure accounts
AU2011261259B2 (en) * 2010-06-04 2015-05-14 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
WO2012027385A1 (en) * 2010-08-23 2012-03-01 Princeton Payment Solutions Tokenized payment processing schemes
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
GB2483515B (en) * 2010-09-13 2018-01-24 Barclays Bank Plc Online user authentication
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
US20120095865A1 (en) 2010-10-15 2012-04-19 Ezpayy, Inc. System And Method For Mobile Electronic Purchasing
US20120095852A1 (en) 2010-10-15 2012-04-19 John Bauer Method and system for electronic wallet access
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
US20130275308A1 (en) 2010-11-29 2013-10-17 Mobay Technologies Limited System for verifying electronic transactions
US9141945B2 (en) 2010-12-02 2015-09-22 Appmobi Iplc, Inc. Secure distributed single action payment system
US9292870B2 (en) 2010-12-13 2016-03-22 Qualcomm Incorporated System and method for point of service payment acceptance via wireless communication
US8762284B2 (en) 2010-12-16 2014-06-24 Democracyontheweb, Llc Systems and methods for facilitating secure transactions
US8646059B1 (en) 2010-12-17 2014-02-04 Google Inc. Wallet application for interacting with a secure element application without a trusted server for authentication
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
US20140019352A1 (en) 2011-02-22 2014-01-16 Visa International Service Association Multi-purpose virtual card transaction apparatuses, methods and systems
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
US9485258B2 (en) 2011-02-13 2016-11-01 Openwave Mobility, Inc. Mediation system and method for restricted access item distribution
WO2012116221A1 (en) * 2011-02-23 2012-08-30 Mastercard International, Inc. Demand deposit account payment system
US9773212B2 (en) 2011-02-28 2017-09-26 Visa International Service Association Secure anonymous transaction apparatuses, methods and systems
CN103503010B (en) 2011-03-04 2017-12-29 维萨国际服务协会 Ability to pay combined elements of a computer security
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
AU2012201745B2 (en) 2011-03-24 2014-11-13 Visa International Service Association Authentication using application authentication element
US9280765B2 (en) 2011-04-11 2016-03-08 Visa International Service Association Multiple tokenization for authentication
US8688589B2 (en) 2011-04-15 2014-04-01 Shift4 Corporation Method and system for utilizing authorization factor pools
EP2697756A4 (en) 2011-04-15 2014-09-10 Shift4 Corp 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
US20120271770A1 (en) * 2011-04-20 2012-10-25 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
US20120310831A1 (en) 2011-06-02 2012-12-06 Visa International Service Association Reputation management in a transaction processing system
US8538845B2 (en) 2011-06-03 2013-09-17 Mozido, Llc Monetary transaction system
BR112013031147A2 (en) 2011-06-03 2017-02-07 Visa Int Service Ass devices, methods and virtual wallet card selection system
US10318932B2 (en) 2011-06-07 2019-06-11 Entit Software Llc Payment card processing system with structure preserving encryption
CN103765454B (en) * 2011-06-07 2018-02-27 维萨国际服务协会 Privacy token payment apparatus, a method and system
EP2751754A4 (en) 2011-08-30 2015-06-03 C Douglas Yeager Systems and methods for authorizing a transaction with an unexpected cryptogram
WO2012167941A1 (en) 2011-06-09 2012-12-13 Gemalto Sa Method to validate a transaction between a user and a service provider
US20130003604A1 (en) * 2011-06-30 2013-01-03 Research In Motion Limited Method and Apparatus for Enhancing Downlink Control Information Transmission
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
US9704155B2 (en) 2011-07-29 2017-07-11 Visa International Service Association Passing payment tokens through an hop/sop
US8572690B2 (en) 2011-08-15 2013-10-29 Bank Of America Corporation Apparatus and method for performing session validation to access confidential resources
US9355393B2 (en) 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
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
US20130226799A1 (en) 2011-08-23 2013-08-29 Thanigaivel Ashwin Raj Authentication process for value transfer machine
WO2013028910A2 (en) 2011-08-23 2013-02-28 Visa International Service Association Mobile funding method and system
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
EP2761551A4 (en) 2011-10-01 2015-09-02 Intel Corp Cloud based credit card emulation
CA2852059A1 (en) 2011-10-12 2013-04-18 C-Sam, Inc. A multi-tiered secure mobile transactions enabling platform
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 谷歌公司 A plurality of service provider systems for the Trusted Service Manager, and the security element interface, methods and computer program products
US20130124364A1 (en) 2011-11-13 2013-05-16 Millind Mittal System and method of electronic payment using payee provided transaction identification codes
US8606720B1 (en) 2011-11-13 2013-12-10 Google Inc. Secure storage of payment information on client devices
US9348896B2 (en) 2011-12-05 2016-05-24 Visa International Service Association Dynamic network analytics system
US8972719B2 (en) 2011-12-06 2015-03-03 Wwpass Corporation Passcode restoration
US8656180B2 (en) 2011-12-06 2014-02-18 Wwpass Corporation Token activation
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
EP2801061A4 (en) 2012-01-05 2015-06-03 Visa Int Service Ass 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
WO2013113004A1 (en) 2012-01-26 2013-08-01 Visa International Service Association System and method of providing tokenization as a service
US20130198071A1 (en) 2012-01-27 2013-08-01 Penny Diane Jurss 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
US9218624B2 (en) 2012-02-03 2015-12-22 Paypal, Inc. Adding card to mobile/cloud wallet using NFC
US20130212007A1 (en) 2012-02-10 2013-08-15 Protegrity Corporation Tokenization in payment 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
US20130246199A1 (en) 2012-03-14 2013-09-19 Mark Carlson Point-of-transaction account feature redirection apparatuses, methods and systems
US20130246259A1 (en) 2012-03-15 2013-09-19 Firethorn Mobile, Inc. System and method for managing payment in transactions with a pcd
US9092776B2 (en) 2012-03-15 2015-07-28 Qualcomm Incorporated 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
US20130262317A1 (en) 2012-04-02 2013-10-03 Mastercard International Incorporated Systems and methods for processing mobile payments by provisoning credentials to mobile devices without secure elements
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
EP2836971B1 (en) 2012-04-13 2017-12-13 Mastercard International, Inc. Systems, methods, and computer readable media for conducting a transaction using cloud based credentials
KR20140140079A (en) 2012-04-18 2014-12-08 구글 인코포레이티드 Processing payment transactions without a secure element
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
WO2013166501A1 (en) 2012-05-04 2013-11-07 Visa International Service Association System and method for local data conversion
US9521548B2 (en) 2012-05-21 2016-12-13 Nexiden, Inc. Secure registration of a mobile device for use with a session
US20130311382A1 (en) 2012-05-21 2013-11-21 Klaus S. Fosmark Obtaining information for a payment transaction
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
WO2014008403A1 (en) 2012-07-03 2014-01-09 Visa International Service Association Data protection hub
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
US9043609B2 (en) 2012-07-19 2015-05-26 Bank Of America Corporation Implementing security measures for authorized tokens used in mobile transactions
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
US20140040145A1 (en) 2012-07-31 2014-02-06 Matthew D. Ozvat 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
ES2680152T3 (en) 2012-08-03 2018-09-04 OneSpan International GmbH Convenient method and apparatus for user authentication using a mobile authentication application
US9665722B2 (en) 2012-08-10 2017-05-30 Visa International Service Association Privacy firewall
EP2885753A4 (en) 2012-08-17 2016-01-06 Google Inc Wireless reader and payment transaction terminal functionality
WO2014036074A1 (en) 2012-08-28 2014-03-06 Visa International Service Association Protecting assets on a device
AU2013315510A1 (en) 2012-09-11 2015-04-02 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
WO2014066559A1 (en) 2012-10-23 2014-05-01 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
US9249241B2 (en) 2013-03-27 2016-02-02 Ut-Battelle, Llc Surface-functionalized mesoporous carbon materials
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
US20140330721A1 (en) 2013-05-02 2014-11-06 Quan Wang 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
US9760886B2 (en) 2013-05-10 2017-09-12 Visa International Service Association Device provisioning using partial personalization scripts
US9978062B2 (en) 2013-05-15 2018-05-22 Visa International Service Association Mobile tokenization hub
US20140372308A1 (en) 2013-06-17 2014-12-18 John Sheets System and method using merchant token
CN105556553A (en) 2013-07-15 2016-05-04 维萨国际服务协会 Secure remote payment transaction processing
WO2015013522A1 (en) 2013-07-24 2015-01-29 Visa International Service Association Systems and methods for communicating risk using token assurance data
CN105612543A (en) 2013-08-08 2016-05-25 维萨国际服务协会 Methods and systems for provisioning mobile devices with payment credentials
US20150046338A1 (en) 2013-08-08 2015-02-12 Prasanna Laxminarayanan Multi-network tokenization processing
KR20160043075A (en) 2013-08-15 2016-04-20 비자 인터네셔널 서비스 어소시에이션 Secure remote payment transaction processing using a secure element
CA2924683A1 (en) 2013-09-20 2015-03-26 Visa International Service Association Secure remote payment transaction processing including consumer authentication
CA2927052A1 (en) 2013-10-11 2015-04-16 Visa International Service Association Network token system
US9978094B2 (en) 2013-10-11 2018-05-22 Visa International Service Association Tokenization revocation list
US20150112870A1 (en) 2013-10-18 2015-04-23 Sekhar Nagasundaram Contextual transaction token methods and systems
US20150112871A1 (en) 2013-10-21 2015-04-23 Phillip Kumnick Multi-network token bin routing with defined verification parameters
US20150120472A1 (en) 2013-10-29 2015-04-30 Christian Aabye 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
SG10201900029SA (en) 2013-11-19 2019-02-27 Visa Int Service Ass Automated account provisioning
US20150161597A1 (en) 2013-12-09 2015-06-11 Kaushik Subramanian Transactions using temporary credential data
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
KR20160101117A (en) 2013-12-19 2016-08-24 비자 인터네셔널 서비스 어소시에이션 Cloud-based transactions methods and systems
US20150186864A1 (en) 2013-12-27 2015-07-02 Christopher Jones 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
US20150195133A1 (en) 2014-01-07 2015-07-09 John Sheets Methods and systems for provisioning multiple devices
US20150199679A1 (en) 2014-01-13 2015-07-16 Karthikeyan Palanisamy Multiple token provisioning
US9846878B2 (en) 2014-01-14 2017-12-19 Visa International Service Association Payment account identifier system
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
US9942043B2 (en) 2014-04-23 2018-04-10 Visa International Service Association Token security on a communication device
US9848052B2 (en) 2014-05-05 2017-12-19 Visa International Service Association System and method for token domain control
WO2015175696A1 (en) 2014-05-13 2015-11-19 Visa International Service Association Master applet for secure remote payment processing
US20150356560A1 (en) 2014-06-05 2015-12-10 Vishwanath Shastry 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
US9779345B2 (en) 2014-08-11 2017-10-03 Visa International Service Association Mobile device with scannable image including dynamic data
EP3195521A4 (en) 2014-08-29 2018-03-14 Visa International Service Association Methods for secure cryptogram generation
AU2015319804B2 (en) 2014-09-26 2019-03-14 Visa International Service Association Remote server encrypted data provisioning system and methods
US20160092872A1 (en) 2014-09-29 2016-03-31 Gyan Prakash 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
CA2964791A1 (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
RU2017124442A3 (en) 2014-12-12 2019-06-19
US10096009B2 (en) 2015-01-20 2018-10-09 Visa International Service Association Secure payment processing using authorization request
CN107210914A (en) 2015-01-27 2017-09-26 维萨国际服务协会 Methods for secure credential provisioning
US20160224977A1 (en) 2015-01-30 2016-08-04 Yaasha Sabba Token check offline
US20160232527A1 (en) 2015-02-09 2016-08-11 Barbara Patterson Token processing utilizing multiple authorizations
US20160239842A1 (en) 2015-02-13 2016-08-18 Duane Cash Peer forward authorization of digital requests
US20170228723A1 (en) 2016-02-09 2017-08-10 Mary Taylor Resource provider account token provisioning and processing

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030028481A1 (en) * 1998-03-25 2003-02-06 Orbis Patents, Ltd. Credit card system and method
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US20020120584A1 (en) * 2000-04-11 2002-08-29 Hogan Edward J. Method and system for conducting secure payments over a computer network without a pseudo or proxy account number
US20030120554A1 (en) * 2001-03-09 2003-06-26 Edward Hogan System and method for conducting secure payment transactions
US20030101348A1 (en) * 2001-07-12 2003-05-29 Russo Anthony P. Method and system for determining confidence in a digital transaction
US20060235795A1 (en) * 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions
US8682802B1 (en) * 2011-11-09 2014-03-25 Amazon Technologies, Inc. Mobile payments using payment tokens
US8613055B1 (en) * 2013-02-22 2013-12-17 Ping Identity Corporation Methods and apparatus for selecting an authentication mode at time of issuance of an access token

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Ron White How Computers Work October 15, 2003 Paul Boger Illustrated by Timothy Edward Downs 7th Edition *

Cited By (101)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10289999B2 (en) 2005-09-06 2019-05-14 Visa U.S.A. Inc. System and method for secured account numbers in proximity devices
US10043178B2 (en) 2007-06-25 2018-08-07 Visa International Service Association Secure mobile payment system
US9530131B2 (en) 2008-07-29 2016-12-27 Visa U.S.A. Inc. Transaction processing using a global unique identifier
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US10043186B2 (en) 2009-05-15 2018-08-07 Visa International Service Association Secure authentication system and method
US9317848B2 (en) 2009-05-15 2016-04-19 Visa International Service Association Integration of verification tokens with mobile communication devices
US10009177B2 (en) 2009-05-15 2018-06-26 Visa International Service Association Integration of verification tokens with mobile communication devices
US9582801B2 (en) 2009-05-15 2017-02-28 Visa International Service Association Secure communication of payment information to merchants using a verification token
US10049360B2 (en) 2009-05-15 2018-08-14 Visa International Service Association Secure communication of payment information to merchants using a verification token
US9792611B2 (en) 2009-05-15 2017-10-17 Visa International Service Association Secure authentication system and method
US9904919B2 (en) 2009-05-15 2018-02-27 Visa International Service Association Verification of portable consumer devices
US10255591B2 (en) 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
US9589268B2 (en) 2010-02-24 2017-03-07 Visa International Service Association Integration of payment capability into secure elements of computers
US10154084B2 (en) 2011-07-05 2018-12-11 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
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
US9959531B2 (en) 2011-08-18 2018-05-01 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US10078832B2 (en) 2011-08-24 2018-09-18 Visa International Service Association Method for using barcodes and mobile devices to conduct payment transactions
US10223730B2 (en) 2011-09-23 2019-03-05 Visa International Service Association E-wallet store injection search apparatuses, methods and systems
US10147089B2 (en) 2012-01-05 2018-12-04 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
US10262001B2 (en) 2012-02-02 2019-04-16 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia merchant analytics database platform apparatuses, methods and systems
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
US9524501B2 (en) 2012-06-06 2016-12-20 Visa International Service Association Method and system for correlating diverse transaction data
US10296904B2 (en) 2012-06-06 2019-05-21 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
US9846861B2 (en) 2012-07-25 2017-12-19 Visa International Service Association Upstream and downstream data conversion
US9727858B2 (en) 2012-07-26 2017-08-08 Visa U.S.A. Inc. Configurable payment tokens
US10204227B2 (en) 2012-08-10 2019-02-12 Visa International Service Association Privacy firewall
US9665722B2 (en) 2012-08-10 2017-05-30 Visa International Service Association Privacy firewall
US10192216B2 (en) 2012-09-11 2019-01-29 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
US10223710B2 (en) 2013-01-04 2019-03-05 Visa International Service Association Wearable intelligent vision device apparatuses, methods and systems
US9978062B2 (en) 2013-05-15 2018-05-22 Visa International Service Association Mobile tokenization hub
US9996835B2 (en) 2013-07-24 2018-06-12 Visa International Service Association Systems and methods for communicating token attributes associated with a token vault
US9978094B2 (en) 2013-10-11 2018-05-22 Visa International Service Association Tokenization revocation list
US9516487B2 (en) 2013-11-19 2016-12-06 Visa International Service Association Automated account provisioning
US10248952B2 (en) 2013-11-19 2019-04-02 Visa International Service Association Automated account provisioning
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
US9972005B2 (en) 2013-12-19 2018-05-15 Visa International Service Association Cloud-based transactions methods and systems
US10269018B2 (en) 2014-01-14 2019-04-23 Visa International Service Association Payment account identifier system
US10062079B2 (en) 2014-01-14 2018-08-28 Visa International Service Association Payment account identifier system
US9846878B2 (en) 2014-01-14 2017-12-19 Visa International Service Association Payment account identifier system
US9721248B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation ATM token cash withdrawal
US9600817B2 (en) 2014-03-04 2017-03-21 Bank Of America Corporation Foreign exchange token
US9600844B2 (en) 2014-03-04 2017-03-21 Bank Of America Corporation Foreign cross-issued token
US9830597B2 (en) 2014-03-04 2017-11-28 Bank Of America Corporation Formation and funding of a shared token
US20150254650A1 (en) * 2014-03-04 2015-09-10 Bank Of America Corporation Controlling token issuance based on exposure
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
US9680942B2 (en) 2014-05-01 2017-06-13 Visa International Service Association Data verification using access device
US9848052B2 (en) 2014-05-05 2017-12-19 Visa International Service Association System and method for token domain control
US10038563B2 (en) 2014-07-23 2018-07-31 Visa International Service Association Systems and methods for secure detokenization
US9780953B2 (en) 2014-07-23 2017-10-03 Visa International Service Association Systems and methods for secure detokenization
US10049353B2 (en) 2014-08-22 2018-08-14 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
US10255456B2 (en) 2014-09-26 2019-04-09 Visa International Service Association Remote server encrypted data provisioning system and methods
US10255429B2 (en) * 2014-10-03 2019-04-09 Wells Fargo Bank, N.A. Setting an authorization level at enrollment
US20160098548A1 (en) * 2014-10-03 2016-04-07 Wells Fargo Bank, N.A. Setting an authorization level at enrollment
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
US10055728B2 (en) * 2014-12-10 2018-08-21 American Express Travel Related Services Company, Inc. Form factor with an alias code and a secure chip ID
US20170286945A1 (en) * 2014-12-10 2017-10-05 American Express Travel Related Services Company, Inc. Form factor with an alias code and a secure chip id
US10223689B2 (en) 2014-12-10 2019-03-05 American Express Travel Related Services Company, Inc. System and method for over the air provisioned wearable contactless payments
US10257185B2 (en) 2014-12-12 2019-04-09 Visa International Service Association Automated access data provisioning
US10096009B2 (en) 2015-01-20 2018-10-09 Visa International Service Association Secure payment processing using authorization request
US20160217459A1 (en) * 2015-01-28 2016-07-28 American Express Travel Related Services Company, Inc. Systems and methods for smart token allocation scheme
EP3259876A4 (en) * 2015-02-17 2018-07-25 Visa International Service Association Token and cryptogram using transaction specific information
US10116447B2 (en) 2015-02-17 2018-10-30 Visa International Service Association Secure authentication of user and mobile device
US10164996B2 (en) 2015-03-12 2018-12-25 Visa International Service Association Methods and systems for providing a low value token buffer
US9984371B2 (en) * 2015-03-27 2018-05-29 Ca, Inc. Payment de-tokenization with risk evaluation for secure transactions
US20160283942A1 (en) * 2015-03-27 2016-09-29 Ca. Inc. Payment de-tokenization with risk evaluation for secure transactions
EP3281164A4 (en) * 2015-04-10 2018-03-07 Visa International Service Association Browser integration with cryptogram
US10333921B2 (en) 2015-04-10 2019-06-25 Visa International Service Association Browser integration with Cryptogram
US9998978B2 (en) 2015-04-16 2018-06-12 Visa International Service Association Systems and methods for processing dormant virtual access devices
WO2016172432A1 (en) * 2015-04-24 2016-10-27 Capital One Services, Llc One use wearable
EP3295400A4 (en) * 2015-05-11 2018-11-07 Mastercard Asia/Pacific Pte. Ltd. Method and system for rewarding customers in a tokenized payment transaction
US20160335639A1 (en) * 2015-05-13 2016-11-17 Mastercard International Incorporated System and methods for enhanced approval of a payment transaction
US10277575B2 (en) * 2015-06-30 2019-04-30 United States Postal Service System and method of providing identity verification services
US20170006008A1 (en) * 2015-06-30 2017-01-05 United States Postal Service System and method of providing identity verification services
US9948630B2 (en) * 2015-06-30 2018-04-17 United States Postal Service System and method of providing identity verification services
WO2017004090A1 (en) * 2015-06-30 2017-01-05 United States Postal Service System and method of providing identity verificaiton services
WO2017077210A1 (en) * 2015-11-03 2017-05-11 Orange Method for verifying identity during virtualization
FR3043232A1 (en) * 2015-11-03 2017-05-05 Orange Method of identity verification at a virtualization
EP3176741A1 (en) * 2015-12-02 2017-06-07 Eckoh UK Limited Tokenisation in cardholder - not - present transactions
US10243958B2 (en) 2016-01-07 2019-03-26 Visa International Service Association Systems and methods for device push provisoning
EP3414869A4 (en) * 2016-02-12 2018-12-19 Visa International Service Association Authentication systems and methods using location matching
US10313321B2 (en) 2016-04-07 2019-06-04 Visa International Service Association Tokenization of co-network accounts
WO2017218479A1 (en) * 2016-06-15 2017-12-21 Mastercard International Incorporated System and method of tokenizing deposit account numbers for use at payment card acceptance point
WO2017218482A1 (en) * 2016-06-15 2017-12-21 Mastercard International Incorporated System and method to push payment to beneficiary account using an alias
US10268635B2 (en) 2016-06-17 2019-04-23 Bank Of America Corporation System for data rotation through tokenization
WO2018029564A1 (en) * 2016-08-09 2018-02-15 Auvercloud System and method for authentication of a user of an application system by a central server, without using a password
WO2018052855A1 (en) * 2016-09-14 2018-03-22 Visa International Service Association Self-cleaning token vault
WO2019009990A1 (en) * 2017-07-05 2019-01-10 Mastercard International Incorporated System and methods for accepting dual function payment credential
WO2019040807A1 (en) * 2017-08-25 2019-02-28 Mastercard International Incorporated Systems and methods for minimizing user interactions for cardholder authentication
WO2019051360A1 (en) * 2017-09-11 2019-03-14 Jpmorgan Chase Bank, N.A. Systems and methods for token vault synchronization
US10341111B2 (en) 2018-08-21 2019-07-02 Visa International Service Association Secure authentication of user and mobile device

Also Published As

Publication number Publication date
CN105874495A (en) 2016-08-17
AU2014292980A1 (en) 2016-02-04
EP3025293A1 (en) 2016-06-01
CA2918788A1 (en) 2015-01-29
AU2019201056A1 (en) 2019-03-07
AU2014293042A1 (en) 2016-02-11
EP3025293A4 (en) 2017-03-29
RU2016105772A (en) 2017-08-29
SG10201800626RA (en) 2018-02-27
RU2669081C2 (en) 2018-10-08
EP3025292A1 (en) 2016-06-01
WO2015013548A1 (en) 2015-01-29
RU2016105768A (en) 2017-08-28
SG10201800629WA (en) 2018-02-27
CN105580038A (en) 2016-05-11
US20150032626A1 (en) 2015-01-29
JP6518244B2 (en) 2019-05-22
WO2015013522A1 (en) 2015-01-29
AU2018260860A1 (en) 2018-11-22
CA2919199A1 (en) 2015-01-29
EP3025292A4 (en) 2017-03-29
US9996835B2 (en) 2018-06-12
RU2681366C2 (en) 2019-03-06
RU2016105768A3 (en) 2018-03-21
SG11201600520QA (en) 2016-02-26
US20150032627A1 (en) 2015-01-29
RU2016105772A3 (en) 2018-05-16
SG11201600427RA (en) 2016-02-26
JP2016532951A (en) 2016-10-20
KR20160035028A (en) 2016-03-30
US20180285864A1 (en) 2018-10-04
JP2016535517A (en) 2016-11-10

Similar Documents

Publication Publication Date Title
US9245267B2 (en) Portable account number for consumer payment account
AU2015319804B2 (en) Remote server encrypted data provisioning system and methods
US8099368B2 (en) Intermediary service and method for processing financial transaction data with mobile device confirmation
US20100211507A1 (en) Over the air update of payment transaction data stored in secure memory
US9646303B2 (en) Secure remote payment transaction processing using a secure element
US8341086B2 (en) End-to-end secure payment processes
US10210514B2 (en) Demand deposit account payment system
US20150088756A1 (en) Secure Remote Payment Transaction Processing Including Consumer Authentication
CA2920661C (en) Methods and systems for provisioning mobile devices with payment credentials
US9159061B2 (en) Method and system for securing payment transactions
AU2014353151B2 (en) Automated account provisioning
US20150142673A1 (en) Methods and systems for token request management
US9342832B2 (en) Securing external systems with account token substitution
US10296904B2 (en) Method and system for correlating diverse transaction data
US8793192B2 (en) Device enrollment system and method
AU2010256666B2 (en) System and method for providing authentication for card not present transactions using mobile device
US20150332262A1 (en) Master applet for secure remote payment processing
AU2014265291B2 (en) Mobile tokenization hub
US9280765B2 (en) Multiple tokenization for authentication
US20150106239A1 (en) Tokenization revocation list
US20150120472A1 (en) Digital wallet system and method
US20130110658A1 (en) Systems and methods for enabling mobile payments
US10015147B2 (en) Token enrollment system and method
JP6386567B2 (en) Network token system
US20150269566A1 (en) Systems and methods for locally derived tokens

Legal Events

Date Code Title Description
AS Assignment

Owner name: VISA INTERNATIONAL SERVICE ASSOCIATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DILL, MATTHEW;LAXMINARAYANAN, PRASANNA;POWELL, GLENN;AND OTHERS;SIGNING DATES FROM 20140729 TO 20140908;REEL/FRAME:034815/0064

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

STCB Information on status: application discontinuation

Free format text: FINAL REJECTION MAILED