Failsafe authorization system and method

Abstract

Embodiments include techniques comprising receiving, by a processing network computer from a transport computer, an authorization request message. The authorization request message including a credential and a value for an interaction. The credential is associated with an account that is associated with a first authorization entity computer. The techniques further include transmitting, by the processing network computer, the authorization request message to the first authorization entity computer. The techniques further include receiving, by the processing network computer, an authorization response message from the first authorization entity computer indicating an inability to provide an authorization decision. The techniques further include determining, by the processing network computer, that the credential is associated with a flagged account and generating a subsequent authorization request message comprising a token associated with the credential. The techniques further include transmitting, by the processing network computer, the subsequent authorization request message to a second authorization entity computer.

Description

PATENT Attorney Docket No.079900-1406820-7225WO01 Client Ref. No.7225WO01 FAILSAFE AUTHORIZATION SYSTEM AND METHOD CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] None. BACKGROUND

[0002] In a typical transaction (e.g., a transaction to access a location, access secure data, or a resource such as a good or service), an authorization entity computer may receive an authorization request message from a resource provider computer. The authorization entity computer can analyze the authorization request message and can respond to the resource provider computer with an authorization response message.

[0003] In some cases, the authorization entity computer is unable to provide the authorization response message to the resource provider computer. In one example, the authorization entity computer may be offline for technical reasons (e.g., a software or hardware malfunction). In another example, the authorization entity computer may be turned off due to other issues such as financial issues (e.g., when an authorization entity operating the authorization entity computer becomes insolvent or illiquid).

[0004] Embodiments of the disclosure address these problems and other problems individually and collectively. BRIEF SUMMARY

[0005] One embodiment of the invention includes a method comprising: receiving, by a processing network computer from a resource provider computer, an authorization request message comprising a credential and a value for an interaction, the credential associated with an account associated with a first authorization entity computer; transmitting, by the processing network computer, the authorization request message to the first authorization entity computer; receiving,by the processing network computer, an authorization response message from the first authorization entity computer, the authorization response message indicating that the first authorization entity computer is unable to provide an authorization decision; determining, by the processing network computer, that the credential is associated with a flagged account; responsive to determining that the credential is associated with the flagged account, generating, by the processing network computer a subsequent authorization request message comprising a token associated with the credential, the token being a substitute for the credential; and transmitting, by the processing network computer, the subsequent authorization request message comprising the token and the value to a second authorization entity computer.

[0006] Another embodiment includes a processing computer comprising: a processor; and a computer readable medium comprising instructions, executable by the processor, for performing operations comprising: receiving, by a processing network computer from a resource provider computer, an authorization request message comprising a credential and a value for an interaction, the credential associated with an account associated with a first authorization entity computer; transmitting, by the processing network computer, the authorization request message to the first authorization entity computer; receiving, by the processing network computer, an authorization response message from the first authorization entity computer, the authorization response message indicating that the first authorization entity computer is unable to provide an authorization decision; determining, by the processing network computer, that the credential is associated with a flagged account; responsive to determining that the credential is associated with the flagged account, generating, by the processing network computer a subsequent authorization request message comprising a token associated with the credential, the token being a substitute for the credential; and transmitting, by the processing network computer, the subsequent authorization request message comprising the token and the value to a second authorization entity computer

[0007] Another embodiment includes a method comprising: receiving, by an authorization entity computer from a processing network computer, a token associated with a credential; receiving, by the authorization entity computer from the processing network computer, an authorization request message comprising thetoken and a value for an interaction; determining, by the authorization entity computer, whether the token is valid; and transmitting, by the authorization entity computer, an authorization response message to the processing network computer, the authorization response message comprising an approval for the interaction.

[0008] Another embodiment of the invention includes an authorization entity computer comprising a processor, and a non-transitory computer readable medium. The non-transitory computer readable medium comprises code, executable by the processor for performing a method comprising: receiving, by an authorization entity computer from a processing network computer, a token associated with a credential; receiving, by the authorization entity computer from the processing network computer, an authorization request message comprising the token and a value for an interaction; determining, by the authorization entity computer, whether the token is valid; and transmitting, by the authorization entity computer, an authorization response message to the processing network computer, the authorization response message comprising an approval for the interaction.

[0009] These and other embodiments are described in further detail below. TERMS

[0010] Before discussing specific embodiments of the invention, some descriptions of some terms may be helpful.

[0011] An “authorization entity” may be an entity that authorizes a request. Examples of an authorization entity may be an issuer, a governmental agency, a document repository, an access administrator, etc. An authorization entity may operate an authorization entity computer.

[0012] An “issuer” may refer to a business entity (e.g., a bank) that issues and optionally maintains an account for a user. An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.

[0013] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and / or access to a location (e.g., a parking space, a transit terminal, etc.). Examples of resource providers include merchants,governmental authorities, secure data providers, etc. A resource provider may operate one or more access devices.

[0014] An “access device” may be any suitable device that provides access to a resource. An access device may be in any suitable form. Some examples of access devices include vending machines, kiosks, POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a user mobile communication device. In some embodiments, an access device may include a reader, a processor, and a computer-readable medium. A reader may include any suitable contact or contactless mode of operation. For example, exemplary readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a payment device and / or mobile communication device.

[0015] An "acquirer" may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers. An acquirer may operate an acquirer computer, which can also be generically referred to as a “transport computer.”

[0016] A “processor” may refer to any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising 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).

[0017] A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor toimplement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and / or magnetic mode of operation.

[0018] A “mobile communication device” may comprise any suitable electronic device that may be transported and operated by a user, which may also optionally provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, net books, laptop computers, wearable devices (e.g., watches), vehicles such as automobiles and motorcycles, personal music players, hand-held specialized readers, etc. A mobile communication device may comprise any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., when a device has remote access to a network by tethering to another device - i.e., using the other device as a modem – both devices taken together may be considered a single mobile communication device).

[0019] A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or user devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments.

[0020] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smartphone, a card, a payment card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from avariety of data input types, including, but not limited to, audio data, visual data, or biometric data. The user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network.

[0021] An “access device” may refer to a device used to access something, such as a network or computer system. For example, a point of sale terminal or the phone of a merchant can comprise an access device used to gain access to a payment processing network. An access device may comprise a means by which it can interface with other devices. For example, an access device may include a chip card reader including conductive contacts used to interface with a smartcard user device.

[0022] A “resource” can be something of value to a user. A resource, for example, can include digital items and / or physical items. A resource can be an obtainable item. A resource can be owned by an entity. A resource can be a physical item such as goods. A resource can be a service that is provided by a merchant. A resource can be a digital item such as non-fungible tokens, secure data, etc. Another example of a resource is access to a secure or otherwise access-controlled location.

[0023] A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters that may be present or contained in any object or document that can serve as confirmation.

[0024] A "value credential" may be information associated with worth. Examples of value credentials include payment credentials, coupon identifiers, information needed to obtain a promotional offer, etc.

[0025] “Payment credentials” may include any suitable information associated with an account (e.g., a payment account and / or payment device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of account information may include a PAN (primary account number or “account number”), username, expirationdate, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification values, etc. CVV2 is generally understood to be a static verification value associated with a payment device. CVV2 values are generally visible to a user (e.g., a consumer), whereas CVV and dCVV values are typically embedded in memory or authorization request messages and are not readily known to the user (although they are known to the issuer and payment processors). Payment credentials may be any information that identifies or is associated with a payment account. Payment credentials may be provided in order to make a payment from a payment account. Payment credentials can also include a username, an expiration date, a gift card number or code, and any other suitable information.

[0026] A “token” may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include access tokens such as payment tokens, data that can be used to access secure systems or locations, etc.

[0027] A "payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN) and / or an expiration date. 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 “4900000000000001” may be used in place of a PAN “4147090000001234.” In some embodiments, a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing transaction 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.

[0028] “Tokenization” is a process by which sensitive data is replaced with substitute data. For example, a real credential (e.g., a primary account number (PAN)) may be tokenized by replacing the real account identifier with a substitute number that may be associated with the real credential. Further, tokenization can be applied to any other information to substitute the underlying information with a token. “Token exchange” or “detokenization” can be a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with its associated primary account number (PAN). Further, detokenization or token exchange may be applied to any other information to retrieve the substituted information from a token. In some embodiments, token exchange can 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).

[0029] A “token service computer” can include a system that that services tokens. In some embodiments, a token service computer can facilitate requesting, determining (e.g., generating) and / or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g., token vault). In some embodiments, the token service computer may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service computer may include or be in communication with a token vault where the generated tokens are stored. The token service computer may support token processing of payment transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN.

[0030] A “token domain” may indicate an area and / or circumstance in which a token can be used. Examples of the token domain may include, but are not limited to, payment channels (e.g., e-commerce, physical point of sale, etc.), POS entry modes (e.g., contactless, magnetic stripe, etc.), and merchant identifiers to uniquely identify where the token can be used. A set of parameters (i.e., token domain restriction controls) may be established as part of token issuance by the token service computer that may allow for enforcing appropriate usage of the token in payment transactions. For example, the token domain restriction controls may restrict the use of the token with particular presentment modes, such as contactless or e-commerce presentment modes. In some embodiments, the token domainrestriction controls may restrict the use of the token at a particular merchant that can be uniquely identified. Some exemplary token domain restriction controls may require the verification of the presence of a token cryptogram that is unique to a given transaction. In some embodiments, a token domain can be associated with a token requestor.

[0031] “Token expiry date” may refer to the expiration date / time of the token. The token expiry date may be passed among the entities of the tokenization ecosystem during transaction processing to ensure interoperability. The token expiration date may be a numeric value (e.g., a 4-digit numeric value). In some embodiments, the token expiry date can be expressed as a time duration as measured from the time of issuance.

[0032] An “authorization request message” may be a message that requests permission to conduct an interaction. For example, an authorization request message may include an electronic message that is sent to a payment processing network and / or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with (International Organization of Standardization) ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), 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.

[0033] An “authorization response message” may be an electronic message reply to an authorization request message. In some embodiments, it may be generated by an issuing financial institution or a payment processing network. Theauthorization response message may include, by way of example only, one or more of the following status indicators: Approval -- transaction was approved; Decline -- transaction was not approved; or Call Center -- response pending more information, merchant must call the toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the payment processing network) to the merchant's access device (e.g., POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization. As noted above, in some embodiments, a payment processing network may generate or forward the authorization response message to the merchant.

[0034] An “interface” may include any software module configured to process communications. For example, an interface may be configured to receive, process, and respond to a particular entity in a particular communication format. Further, a computer, device, and / or system may include any number of interfaces depending on the functionality and capabilities of the computer, device, and / or system. In some embodiments, an interface may include an application programming interface (API) or other communication format or protocol that may be provided to third parties or to a particular entity to allow for communication with a device. Additionally, an interface may be designed based on functionality, a designated entity configured to communicate with, or any other variable. For example, an interface may be configured to allow for a system to field a particular request or may be configured to allow a particular entity to communicate with the system.

[0035] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.BRIEF DESCRIPTION OF THE DRAWINGS

[0036] FIG.1 shows a block diagram of a system, according to an embodiment.

[0037] FIGS.2A and 2B show flow diagrams illustrating methods according to embodiments of the invention.

[0038] FIG.3 shows a block diagram of a processing network computer, according to an embodiment.

[0039] FIG.4 shows a block diagram of an authorization entity computer, according to an embodiment. DETAILED DESCRIPTION

[0040] Embodiments of the invention provide for a failsafe authorization process that enables a second authorization entity computer to authorize a transaction conducted by a user in the event that a first authorization entity computer that would normally authorize the transaction has failed. The failure of the first authorization entity computer can occur for a number of reasons. For example, the first authorization entity computer may fail before of a technical or network malfunction. In another example, the first authorization entity computer can fail because the first authorization entity operating the first authorization entity computer has become insolvent or illiquid.

[0041] Embodiments of the invention also provide for improved data security. A sensitive credential such as an account number (e.g., a credit card number, access badge number, etc.) need not be sent to the second authorization entity to allow the second authorization entity to authorize the transaction in lieu of the first authorization entity authorizing the transaction.

[0042] FIG.1 shows a block diagram of a system 100, according to an embodiment. System 100 includes a user 110 that operates a user device 108. The user device can interact with an access device 112. The resource provider computer 114 can be in communication with a processing network computer 118 via a transport computer 116. The processing network computer 118 can be incommunication with various authorization entity computers including a first authorization entity computer 120, and a second authorization entity computer 122.

[0043] The devices and computers in the system 100 can communicate with one another using a communication network or line (not pictured). The communication network or line can take any suitable form, and may include any one and / or the combination of the following: a direct connection or interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an operating Missions as Nodes on the Internet (OMNI); a cellular network, 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. Messages between the computers and devices in system 100 may be transmitted using a communication protocol such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); Secure Socket Layer (SSL), ISO (e.g., ISO 8583) and / or the like.

[0044] The user 110 may operate the user device 108 to obtain a resource from a resource provider of the resource provider computer 114. The user device 108 may include a credential or a token (that is a substitute for the credential). The credential may be associated with an account managed by the first authorization entity computer.

[0045] In certain embodiments, the user device 108 can interact with (e.g., communicate with) the access device 112. During the interaction, the user device 108 and the access device 112 can be in communication with each other and one or many messages may pass between them during the interaction.

[0046] The user device 108 may be in any suitable form. For example, the user device 108 may be, for example, a mobile phone, a personal computer (e.g., a laptop computer), a wearable device, or a card. For example, the user device 108 can be in the form of a card such as a payment card or an access badge.

[0047] In some embodiments, the user device 108 may include a contactless element for interfacing with an access device (e.g., the access device 112). The contactless element may include a chip, and may include the capability to communicate and transfer data using near field communications (NFC) technologyor other short-range communications technology. The user device 108 may also include a memory, which may store user 110 information such as an address such as public key, a private key associated with the public key, one or more account numbers, one or more expiration dates associated with the one or more account numbers, a username, etc. If the user device 108 is in the form of a card, it may have printed or embossed information such as a name and account number. In some cases, it may also have a magnetic stripe.

[0048] In some embodiments that do not involve financial transactions, the system 100 can allow a user 110 of the user device 108 to access a secure location. In such embodiments, the access device 112 can grant or deny access to the user 110, based on interactions with the user device 108.

[0049] The resource provider computer 114 can be a computer system operated by a resource provider that also operates the access device 112. In some embodiments, the resource provider computer 114 could comprise a merchant backend computer connected to the point of sale terminal (which can be an example of an access device 112).

[0050] In some embodiments, the transport computer 116 can be an acquirer computer associated with an acquiring bank that manages an account on behalf of the merchant.

[0051] The processing network computer 118 could comprise a computer that is part of a payment processing network (e.g., the Visa payment processing network). In some embodiments, the processing network computer 118 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, transaction scoring services, and clearing and settlement services. An exemplary transaction processing system may include VisaNet™. Transaction processing systems such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, may include a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services.

[0052] The first authorization entity computer 120 can be a computer that is programmed to receive, evaluate, and process authorization request messages, andalso perform clearing and settlement processing. The first authorization entity computer 120 can be a first issuer computer operated by an issuer. The first authorization entity computer 120 can analyze the authorization request message and determine whether or not to authorize the transaction. The analysis performed by the first authorization entity computer 120 can include a risk evaluation. The risk evaluation can include evaluating an indicator, a transaction amount, the time of the transaction, the recent frequency of transactions, etc., to determine if one or more of these elements are indicative of potentially fraudulent activity. The first authorization entity computer 120 can generate an authorization response message, indicating whether the transaction has been approved or denied.

[0053] The first authorization entity computer 120 may also communicate with the second authorization entity computer 122. In some embodiments, the first authorization entity computer 120 may share account data with the second authorization entity computer 122.

[0054] The second authorization entity computer 122 may also be a can be a computer that is programmed to receive, evaluate, and process authorization request messages, and also perform clearing and settlement processing. The second authorization entity computer 122 can be operated by another issuer or an insuring entity such as the FDIC (Federal Deposit Insurance Corporation).

[0055] FIGS.2A and 2B can illustrate methods according to embodiments of the invention. Steps S220 to S228 describe steps associated with information sharing between the processing network computer 210, the first authorization entity computer 212, and the second authorization entity computer 214. Steps S230 to S264 describe steps associated with authorization of a transaction in the event that the first authorization entity computer 212 is unable to authorize the transaction. Steps S266 to S276 can be associated with clearing and settlement processing. If the first authorization entity computer 212 is capable of authorizing the transaction, then steps S244 to S256 can be skipped.

[0056] FIGS.2A and 2B include a user device 202 (corresponding to user device 108 in FIG.1), an access device 204 (corresponding to access device 112 in FIG.1), a resource provider computer 206 (corresponding to resource provider computer 114 in FIG.1), a transport computer 208 (corresponding to transportcomputer 116 in FIG.1), a processing network computer 210 (corresponding to processing network computer 118 in FIG.1), a first authorization entity computer 212 (corresponding to first authorization entity computer 120 in FIG.1), and a second authorization entity computer 214 (corresponding to second authorization entity computer 122 in FIG.1).

[0057] At step S220 first status information may be shared by the first authorization entity computer 212 with the second authorization entity computer 214. The first status information may be shared periodically (e.g., in real time, hourly, daily, weekly, monthly, etc.). Further, the first status information may be shared upon an event occurring. For example, the first status information may be shared after the second authorization entity computer 214 requests the first status information from the first authorization entity computer 212, when an account balance changes (e.g., a balance of a flagged account), after a certain number of transactions have been authorized for an account (e.g., the flagged account), etc.

[0058] The first status information may include details regarding an account for a user of the user device 202. Such details can include an account type (e.g., checking account, savings account, etc.), an account credential (e.g., an account number for a checking account or token associated with the account number), a balance of the account, a status date for the account, historical data associated with the account (e.g., a transaction velocity or historical balance), etc.

[0059] At step S222, the second authorization entity computer 214 may transmit second status information to the processing network computer 210. The second status information may be shared periodically (e.g., hourly, daily, weekly, monthly, etc.). Further, the second status information may be shared upon an event occurring. For example, the second status information may be shared after the processing network computer 210 requests the second status information, when an account balance changes (e.g., a balance of a flagged account), after a certain number of transactions have been authorized for an account (e.g., the flagged account), after the second authorization entity computer 214 indicates that it will act as a failsafe mechanism for the first authorization entity computer 212, etc. The second status information may include one or more of the details regarding the account (as described above with respect to step S220). The second statusinformation may also include information regarding a balance that will be backed by the second authorization entity computer 214 (e.g., an insured amount for the account), etc.

[0060] In some embodiments, the second status information is not transmitted by the second authorization entity computer 214 until after an authorization response message is received by the processing network computer 210 from the first authorization entity computer 212 (e.g., indicating that the authorization entity computer is offline).

[0061] At step S224, the processing network computer 210 may determine whether the account associated with the second status information is flagged as one that can have transactions processed by the second authorization entity computer 214 if the first authorization entity computer 212 cannot perform authorizations on the account. The determination may be made using information included in the second status information (e.g., the second status information can include a flag indicating that the second authorization entity computer 214 will process authorization request messages if the first authorization entity computer 212 cannot do so).

[0062] In certain embodiments, responsive to receiving the second status information from the second authorization entity computer 214, the processing network computer 210 may store the account information associated with the account, and can flag it with a flag indicating that the second authorization entity computer 214 will process authorization request messages if the first authorization entity computer 212 cannot do so.

[0063] At step S226, in response to determining that the account is a flagged account, the processing network computer 210 can generate a token that is associated with the credential. The processing network computer 210 may store the relationship between the token and the credential in a token vault.

[0064] At step S228, the processing network computer 210 can transmit the token to the second authorization entity computer 214 and the token may be received by the second authorization entity computer 214. In certain embodiments, the token can be regenerated as a different second token periodically or upon theoccurrence of an event and then re-transmitted to the second authorization entity computer 214.

[0065] At some point, the user of the user device 202 may want to obtain a resource from a resource provider operating the access device 204 and the resource provider computer 206. The resource may be a good or service, or access to secure location or secure data.

[0066] At step S230, the user device 202 may interact with the access device 204. The user device 202 may transmit or provide a credential (e.g., debit card number) to the access device 204. The access device 204 may receive the credential from the user device 202. In some embodiments, the credential may have been tokenized and the user device 202 can transmit or provide a token to the access device 204.

[0067] At step S232, the access device 204 may transmit an authorization request message to the resource provider computer 206. The authorization request message may include a value (e.g., transaction amount, area identifier of building access requested) and a credential (or token).

[0068] At step S234, after receiving the authorization request message, the resource provider computer 206 may transmit the authorization request message to the transport computer 208.

[0069] At step S236, after receiving the authorization request message, the transport computer 208 determine the processing network computer 210 using the credential (or token). In some cases, one digit (e.g., the first digit) of a credential can indicate which processing network computer 210 to route the authorization request message. The transport computer 208 may transmit the authorization request message to the processing network computer 210.

[0070] At step S238, after receiving the authorization request message, the processing network computer 210 may determine the first authorization entity computer 212 by analyzing the credential. In some cases, the credential can have an identifier for the first authorization entity computer 212. The processing network computer 210 may then transmit the authorization request message to the first authorization entity computer 212. The authorization request message may includethe credential and the value (e.g., a transaction amount). The credential may be associated with an account associated with the first authorization entity computer 212 and / or the user device 202.

[0071] In some embodiments, if the authorization request message comprises a token instead of a credential, the processing network computer 210 can detokenize the token to obtain the credential associated with the token. The processing network computer 210 can include PAN / token mappings.

[0072] In some embodiments, he first authorization entity computer 212 may receive the authorization request message from the processing network computer 210. In certain embodiments, the authorization entity computer does not receive the authorization request message (e.g., a server is offline, a server is without power).

[0073] At step S240, after the authorization request message is sent to the first authorization entity computer 212, the first authorization entity computer 212 may be unable to provide an authorization decision. For example, the first authorization entity computer 212 may be unable to provide the authorization decision because at least one of (i) an error code is received from the first authorization entity computer 212 (e.g., indicating insolvency, closure, network issues) or (ii) an authorization response message is not received from the first authorization entity computer 212 (e.g., a server is offline, a server is without power).

[0074] At step S242, if the first authorization entity computer 212 is able to respond, the first authorization entity computer 212 may send an authorization response message to the processing network computer 210 indicating the inability to provide the authorization decision. In some cases, the authorization response message may include a code which indicates the reason why it is not able to respond (e.g., an insolvency code, a network error code, etc.). In certain embodiments, no response message is received from the first authorization entity computer 212.

[0075] At step S244, the processing network computer 210 analyzes the authorization response message if it was sent. Alternatively, the processing network computer 210 can determine that no authorization request message was sent if one was not received within a predetermined time (e.g., the message timed out). Then,the processing network computer 210 determines whether the authorization request message should be transmitted to the second authorization entity computer 214.

[0076] At step S246, the processing network computer 210 may also determine if the authorization request message should be transmitted to the second authorization entity computer 214. The determination may be based on whether an account associated with the authorization request message is a flagged account. The determination may be based on whether the credential (or token) associated with the authorization request message is associated with a flagged account (e.g., flagging that the account is insured or backed by the second authorization entity computer 214).

[0077] At step S248, if the processing network computer 220 determines that the account associated with the credential is a flagged account, and it may then transmit a subsequent authorization request message to the second authorization entity computer 214. The subsequent authorization request message may be generated so that the token generated in step S226 and the value are in the subsequent authorization request message. The token may be a substitute for the credential. The second authorization entity computer 214 may receive from the processing network computer 210, the subsequent authorization request message comprising the token and the value.

[0078] At step S250, after the second authorization entity computer 214 receives the subsequent authorization request message, the second authorization entity computer 214 may determine whether the token in the subsequent authorization request is valid. In certain embodiments, a time to live of the token may be checked to determine whether the token is valid. In certain embodiments, a determination is made to check whether the token received from the processing network computer 210 at step S248 is the same token as the token received at step S228.

[0079] At step S252, the second authorization entity computer 214 may determine whether it can authorize a transaction associated with the value in the subsequent authorization request message. The determination may be made using an account balance associated with the token at the second authorization entity computer 214 and a most recent account balance of the account managed by thefirst authorization entity computer 212. In some embodiments, the account balance associated with the token and / or the most recent account balance of the account managed by the first authorization entity computer 212 may be determined at step S220 or step S276. In certain embodiments, the account balance at the second authorization entity computer 214 is equal to the account balance at the first authorization entity computer 212. In certain embodiments, the account balance at the second authorization entity computer 214 is greater than the account balance at the first authorization entity computer 212. For example, the account balance at the second authorization entity computer 214 may be an insured amount of $250,000 per account, while the account balance at the first authorization entity computer 212 can be $10,000.

[0080] In some embodiments, the determination of whether the subsequent authorization request message is approved involves a determination that the value in the subsequent authorization request message is less than the account balance at the second authorization entity computer 214 and at the first authorization entity computer 212. For example, in the above example, if the subsequent authorization request message includes a value of $1000, and the second authorization entity computer 214 has a recent record of $10,000 for the account balance for the account at first authorization entity computer 212, and the account balance for the account at the second authorization entity computer is $250,000, then the second authorization entity computer 214 can authorize transactions up to $10,000. In this example, the second authorization entity computer 214 would approve of the subsequent authorization request message. If the subsequent authorization request message comprises a value over $10,000, then the second authorization entity computer would not approve it. In some cases, since the second authorization entity computer 214 may not have the current balance for the account at the first authorization entity computer 212, the second authorization entity computer 214 may have a rule that only a certain percentage (e.g., 70%) of the most recent balance of the account at the first authorization entity computer 212 would be approved. In some embodiments, the most recent balance of the account at the first authorization entity computer may be determined at step S220 or step S276.

[0081] At step S254, the second authorization entity computer 214 can generate and transmit a subsequent authorization response message comprising the token and an approve or decline indicator to the processing network computer 210.

[0082] At step S256, the balance maintained by the second authorization entity computer 214 may be adjusted based on the value associated with the subsequent authorization response that included an approval for the interaction. For example, in the above example, the second authorization entity computer 214 can adjust a balance associated with the account at the first authorization entity computer 212 to be $9000 and the balance associated with the account at the second authorization entity computer 214 can be adjusted to $249,000.

[0083] At steps S260, S262, and S264, the processing network computer 210 may substitute the credential for the token in the subsequent authorization response message, and can transmit it the access device 204 via the transport computer 208 and the resource provider computer 206. The access device 204 may then display a message indicating the status of the subsequent authorization response message (e.g., approved, denied, etc.).

[0084] At step S266, after the authorization processing has been completed, the resource provider computer 206 may generate a transaction submission with the transaction data (including the credential) for the above-described transaction and other transactions and transmit it to the transport computer 208.

[0085] At step S268, the transport computer 208 may generate a clearing file. The clearing file may be sent by the transport computer 208 to the processing network computer 210. The processing network computer 210 may use the clearing file to generate settlement files, the settlement files may be sent to one or more authorization entity computers (e.g., the first authorization entity computer 212, the second authorization entity computer 214).

[0086] At step S270, the second authorization entity computer 214 receives a settlement file from the processing network computer 210. The second authorization entity computer 214 may perform reconciliation where a match process is initiated to validate (e.g., match) the transactions approved by an authorization engine of the second authorization entity computer 214 with the transaction information appearing in the settlement file. The transactions that are validated (e.g., a transaction that hassuccessfully cleared all the validations) may be saved. The validated transactions may appear on a statement for the user or the first authorization entity computer 212. The statement may reflect value requested or owed by the first authorization entity computer 212 to the second authorization entity computer 214.

[0087] At step S272, the second authorization entity computer 214 may determine that a value for funds that are to be transmitted to the processing network computer 210. The value may be determined based on the transactions that were validated by the second authorization entity computer 214. The funds may be transmitted from the second authorization entity computer 214 to the network processing computer 210.

[0088] At step S273, the processing network computer 210 may validate / reconcile and transmit the funds received from the second authorization entity computer 214 to transport computer 208.

[0089] At step S274, the processing network computer 210 may transmit a transaction notification to the first authorization entity computer 212. The transaction notification may be transmitted after a subsequent authentication response message is received by the processing network computer 210 from the second authorization entity computer 214. The transaction notification may be sent upon an event occurring (e.g., after a subsequent authentication response message is received by the processing network computer 210) or at a predetermined time (e.g., end of day).

[0090] The transaction notification may include transaction details. The transaction details may include a value, an account identifier (e.g., for the flagged account), a timestamp, an identifier for a computer or entity (e.g., second authorization entity computer 214) which authorized the transaction, or any other information included in an authorization response message or authorization request message. The transaction notification may be received by the first authorization entity computer 212.

[0091] The transaction details may be stored by the first authorization entity computer 212. In certain embodiments, the transaction details may be used by the first authorization entity computer 212 to deduct values associated with accounts maintained by the first authorization entity computer 212.

[0092] At step S276, according to certain embodiments, the transaction details may be exchanged between the first authorization entity computer 212 and the second authorization entity computer 214. The transaction details may be transmitted from the second authorization entity computer 214 to the first authorization entity computer 212 after step S272. If the first authorization entity computer 212 is unable to authorize the transaction, the second authorization entity computer 214 may store the transaction details (e.g., to retransmit at again at a subsequent point in time). The transaction details may be retransmitted to the first authorization entity computer 212 for a number of times, after a certain amount of time, and / or in accordance with other preconfigured conditions. Such information can be used to perform reconciliation and settle obligations between the second authorization entity operating the second authorization entity computer 214 and the first authorization entity operating the first authorization entity computer 212. For example, if the first authorization entity computer 212 failed to respond to authorization request messages because it was insolvent, and if it later became solvent, then the transaction details may be used by the first authorization entity to reimburse the second authorization entity for the payment of the prior transaction. In certain embodiments, the processing network computer stores the transaction details responsive to the first authorization entity computer 212 being unable to authorize the transaction (e.g., to retransmit at again at a subsequent point in time).

[0093] FIG.3 shows a block diagram of a processing network computer 300, according to an embodiment (e.g., processing network computer 210 from FIG.2). The processing network computer 300 comprises a processor 304. A network interface 306, a database 302, and a computer readable medium 308 are coupled to the processor 304.

[0094] The computer readable medium 308 may be formed from any suitable combination of hardware and / or software. It may store computer code to accomplish the functions of the payment processing network computer 300. For example, it may comprise a number of software modules comprising an authorization module 310, a clearing and settlement module 314, and a token generation module 312

[0095] The computer readable medium 308 can comprise code, executable by the processor 304 for performing a method comprising: receiving, by the processingnetwork computer from a resource provider computer, an authorization request message comprising a credential and a value for an interaction, the credential associated with an account associated with a first authorization entity computer; transmitting, by the processing network computer, the authorization request message to the first authorization entity computer; receiving, by the processing network computer, an authorization response message from the first authorization entity computer, the authorization response message indicating that the first authorization entity computer is unable to provide an authorization decision; determining, by the processing network computer, that the credential is associated with a flagged account; responsive to determining that the credential is associated with the flagged account, generating, by the processing network computer a subsequent authorization request message comprising a token associated with the credential, the token being a substitute for the credential; and transmitting, by the processing network computer, the subsequent authorization request message comprising the token and the value to a second authorization entity computer.

[0096] The authorization module 310 may comprise code for performing authorization processing. Authorization processing may include the routing, generation, or modification of authorization request messages.

[0097] The clearing and settlement module 314 may comprise code for performing settlement processing. Settlement processing may include the generating, routing, or modification of clearing messages and the settlement of funds.

[0098] The token generation module 312 may comprise code for performing token generation. Token generation may include using a credential. The token generation module may cause a generated token to be related to a credential, the relationship may be stored in the database 302.

[0099] The network interface 306 may be configured to allow the processing network computer 300 to communicate with other entities such as the transport computer 208, the first authorization entity computer 212, and the second authorization entity computer 214. 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.

[0100] The database 302 can store data. Such data may include data can include tokens, credentials, transaction data and the like. The database may be a conventional, fault tolerant, relational, scalable, secure database such as Oracle or Sybase.

[0101] FIG.4 shows a block diagram of an authorization entity computer 400, according to an embodiment.

[0102] The authorization entity computer 400 comprises a processor 404. A network interface 406, a database 402, and a computer readable medium 408 are coupled to the processor.

[0103] The computer readable medium 408 may be formed from any suitable combination of hardware and / or software. It may store computer code to accomplish the functions of the authorization entity computer 400. For example, it may comprise a number of software modules comprising an authorization module 410 and a settlement module 412.

[0104] The authorization module 410 may comprise code for performing authorization processing. Authorization processing may include generating authorization response messages, and evaluating whether or not authorization request message are authorized or declined.

[0105] The settlement module 412 may comprise code for performing settlement processing. Settlement processing may include receiving clearing files, processing the clearing files, and transferring funds to the transport computer.

[0106] The network interface 406 may be configured to allow the authorization entity computer 400 to communicate with other entities such as the transportcomputer 208, the first authorization entity computer 212, and the processing network computer 210.

[0107] The database 402 can store data. Such data may include data that relates to the token authentication processes being performed. For example, encrypted or unencrypted tokens received from the processing network computer may be stored in the database. The database may be a conventional, fault tolerant, relational, scalable, secure database such as Oracle or Sybase.

[0108] Embodiments of the invention have a number of technical advantages. For example, embodiments of the invention allow transactions to proceed even when a first authorization entity computer is unable to respond. Further, communications with an alternative second authorization entity is made via tokens and not real credentials. This protects the real credentials in transit so that the real credentials are not unnecessarily exposed to man-in-the-middle attacks and hacking attacks. This provides a data security advantage.

[0109] 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, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python 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 for storage and / or transmission, suitable media include 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 compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0110] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any suchcomputer readable medium may reside on or within a single computer product (e.g. a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0111] The figures and above description are illustrative and is not restrictive. In the above description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of certain embodiments. However, it will be apparent that various embodiments may be practiced without these specific details. Many variations of the techniques described herein may become apparent to those skilled in the art upon review of the disclosure. The scope of the techniques can, therefore, be determined not with reference to the above description, but instead can be determined with reference to the pending claims along with their full scope or equivalents.

[0112] 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 techniques.

[0113] The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that additions, subtractions, deletions, and other modifications and changes may be made thereunto without departing from the broader spirit and scope as set forth in the claims. Thus, although specific disclosure embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

[0114] The use of the terms “a” and “an” and “the” and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “having,” “including,” and “containing” are to be construed as open- ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. The term “connected” is to be construed as partly or wholly contained within, attached to, or joined together, even if there is something intervening. Recitation ofranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate embodiments and does not pose a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non- claimed element as essential to the practice of the disclosure.

[0115] Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is intended to be understood within the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

[0116] Preferred embodiments of this disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. Those of ordinary skill should be able to employ such variations as appropriate and the disclosure may be practiced otherwise than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above- described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein.

Claims

WHAT IS CLAIMED IS:

1. A method comprising: receiving, by a processing network computer from a resource provider computer, an authorization request message comprising a credential and a value for an interaction, the credential associated with an account associated with a first authorization entity computer; transmitting, by the processing network computer, the authorization request message to the first authorization entity computer; receiving, by the processing network computer, an authorization response message from the first authorization entity computer, the authorization response message indicating that the first authorization entity computer is unable to provide an authorization decision; determining, by the processing network computer, that the credential is associated with a flagged account; responsive to determining that the credential is associated with the flagged account, generating, by the processing network computer a subsequent authorization request message comprising a token associated with the credential, the token being a substitute for the credential; and transmitting, by the processing network computer, the subsequent authorization request message comprising the token and the value to a second authorization entity computer.

2. The method of claim 1, wherein the method further comprises: receiving, by the processing network computer, a subsequent authorization response message from the second authorization entity computer, the subsequent authorization response message comprising an approval for the interaction; and transmitting, by the processing network computer, the subsequent authorization response message comprising the credential to the resource provider computer.

3. The method of claim 2, wherein the first authorization entity computer and the second authorization entity computer perform accountreconciliation between accounts associated with the credential after the subsequent authorization response message is transmitted.

4. The method of claim 3, further comprising: transmitting, by the processing network computer, transaction details for the interaction to the first authorization entity computer.

5. The method of claim 2, wherein the subsequent authorization response message to the resource provider computer does not include the token.

6. The method of claim 1, wherein the method further comprises: receiving, by the processing network computer from the second authorization entity computer, account status information.

7. The method of claim 6, wherein the credential is an account number.

8. The method of claim 6, wherein the method further comprises: responsive to receiving the account status information by the processing network computer: generating the token associated with the credential.

9. The method of claim 6, wherein the method further comprises: responsive to receiving the account status information by the processing network computer: flagging the account associated with the first authorization entity computer to cause the account to be the flagged account.

10. The method of claim 1, wherein the authorization response message comprises an error code indicating that the first authorization entity computer has technical problems.

11. The method of claim 1, wherein the token is a substitute for the credential.

12. The method of claim 1, wherein the token has a same format as the credential.

13. A processing network computer comprising: a processor; and a computer readable medium comprising instructions, executable by the processor, for performing operations comprising: receiving, from a resource provider computer, an authorization request message comprising a credential and a value for an interaction, the credential associated with an account associated with a first authorization entity computer; transmitting the authorization request message to the first authorization entity computer; receiving an authorization response message from the first authorization entity computer, the authorization response message indicating that the first authorization entity computer is unable to provide an authorization decision; determining that the credential is associated with a flagged account; responsive to determining that the credential is associated with the flagged account, generating a subsequent authorization request message comprising a token associated with the credential, the token being a substitute for the credential; and transmitting the subsequent authorization request message comprising the token and the value to a second authorization entity computer.

14. The processing network computer of claim 13, operations further comprise: receiving a subsequent authorization response message from the second authorization entity computer, the subsequent authorization response message comprising an approval for the interaction; and transmitting the subsequent authorization response message comprising the credential to the resource provider computer.

15. The network processing computer of claim 14, wherein the first authorization entity computer and the second authorization entity computer perform account reconciliation between accounts associated with the credential after the subsequent authorization response message is transmitted.

16. The network processing computer of claim 13, wherein the operations further comprise:transmitting, by the processing network computer, a first status information of the flagged account to the second authorization entity computer.

17. A method comprising: receiving, by an authorization entity computer from a processing network computer, a token associated with a credential; receiving, by the authorization entity computer from the processing network computer, an authorization request message comprising the token and a value for an interaction; determining, by the authorization entity computer, whether the token is valid; and transmitting, by the authorization entity computer, an authorization response message to the processing network computer, the authorization response message comprising an approval for the interaction.

18. The method of claim 17, wherein the authorization entity computer is a second authorization entity computer, and wherein the method further comprises: receiving, by the second authorization entity computer, first status information of a flagged account from a first authorization entity computer; and transmitting, by the second authorization entity computer, second status information to the processing network computer.

19. The method of claim 18, wherein the first authorization entity computer and the second authorization entity computer perform account reconciliation between accounts associated with the credential after the authorization response message is transmitted.

20. The method of claim 17, wherein the token is associated with the credential.

Images