This application is an international patent application for U.S. patent application No. 15/171,982 filed on 2.6.2016 and claiming the benefit of the filing date hereof, which claims priority to U.S. provisional application No. 62/317,450 filed on 1.4.2016, the entire contents of which are incorporated herein by reference for all purposes.
Detailed Description
Embodiments of the present invention relate to systems and methods for reducing the processing time of smart user device (e.g., contact chip card) based transactions in order to optimize the user experience. For many years, consumers have swiped magnetic stripe cards at the access device and then returned the pocket without waiting for the transaction to complete. The embodiments described in the present invention allow equally fast and easy transaction processing during smart user device transactions. Faster transaction processing may be achieved by one or more of the following changes to conventional transaction processing.
In embodiments of the invention, the user device may be removed from the access device before the transaction is completed. For example, the access device may notify the user device that the transaction is complete or cancelled (e.g., by requesting a second password), even though the transaction is actually pending. The user device may then complete its processing of the current transaction, returning to the default setting, and thus ready for removal from the access device. As a result, the user device may be removed from the access device before receiving the authorization request message from the authorization entity.
In some embodiments, the access device may store user device information, allowing the user device to be removed at an even earlier time (e.g., before sending the authorization request message). Instead of collecting user equipment information directly from the user equipment when generating the authorization request message, the stored information may be used for the authorization request message. Thus, once the user device information is received at the user device, the information may be stored at the access device and the user device may be removed. For example, upon receiving and storing user device information, the access device may complete communication with the user device (e.g., by notifying the user device that online processing is not feasible and requesting a password).
In some embodiments, the access device may provide an estimated or preset transaction amount to the user device. The user device can use the estimated transaction amount when generating a password for the transaction. As a result, the user device may not need to wait to determine the final transaction amount before generating the password. In practice, the user device may provide the credential to the access device in parallel with the purchase item being scanned and the transaction amount being calculated. Thus, the user device may immediately provide credentials to the access device so that communication between the user device and the access device may be completed without any delay, and then the user device may be removed. An authorization request message may then be sent that includes the estimated amount and the final amount so that the authorizing entity can verify the password and authorize the actual amount.
Embodiments of the present invention allow user equipment insertion times to be reduced to two seconds or less. Thus, embodiments allow an average reduction of six to seven seconds (75% -83%) compared to the current average of eight to twelve seconds of insertion time, and an eighteen second or more (90% or more) reduction of possible time compared to the current possible insertion time of twenty seconds or more. For transactions that insert the user device before the final transaction amount is known (e.g., for grocery store transactions), the user device insertion time may further reduce the time required for a clerk to scan all items (e.g., perhaps several minutes, depending on the number of items).
Furthermore, the embodiments described in the present invention do not require any changes to existing access device systems. Current systems may only receive software downloads to accommodate the embodiments described in the present invention. No changes are required to standard transaction processing (e.g. EMV or Europay, MasterCard and Visa processing) or the user equipment itself, and no additional testing or authentication may be required. Furthermore, there may be no impact on routing, merchant banks, payment networks, or card issuers.
Embodiments of the present invention may be applied to any form of user device transaction. For example, any transaction involving contacting a card and accessing a device may use these methods to reduce device insertion time. For example, embodiments may be used for payment transactions (e.g., paying at a merchant's POS terminal with a smart credit card, debit card, or prepaid card), access transactions (e.g., gaining access to a restricted area with a smart access token), or any other suitable type of transaction.
Before discussing specific embodiments of the invention, some terms may be described in detail.
"user equipment" may include any suitable device associated with a user. The user device may include a substrate, such as a paper or plastic card, and information printed, embossed, encoded, or otherwise contained on or near the surface of the object. The user equipment may comprise circuitry with e.g. permanent voltage values to store information. Suitable user devices may be hand-held and compact so that they may fit into a user's wallet and/or pocket (e.g., pocket size). The user equipment may operate at least in a contact mode. As one example, the user device may include a smart card. In some embodiments, the smart card may be used as a payment card, a security card, an access card, or any other suitable type of card. The user device may also optionally have features such as a magnetic stripe if the user device is in the form of a debit card, credit card, or smart card. In some embodiments, a financial transaction may be performed using a user device. Such user devices may be referred to as "payment devices". For example, the user device may be associated with a value such as a monetary value, discount, or store credit, and the user device may be associated with an entity such as a bank, merchant, payment processing network, or individual.
A "credential" may include any suitable information that serves as a reliable evidence of value, ownership, identity, or rights. A credential may be a string of numbers, letters, or any other suitable character that may be presented or incorporated into any object or document capable of serving as a confirmation. Examples of credentials include payment credentials, passwords, access credentials, and any other suitable type of credential.
The "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 payment credentials may include a PAN (primary account number or "account number"), a user name, an expiration date, and a verification value, such as a CVV (card verification value), a dCVV (dynamic card verification value), a CVV2 (card verification value 2), a CVC3 card verification value, and so forth. An example of a PAN is a 16 digit number, such as "4147090000001234". In some embodiments, the payment credentials may include additional information that may be used to authorize the transaction. For example, the payment credentials may include a password associated with the transaction.
An "encryption key" may comprise any data value or other information suitable for cryptographically encrypting data. The "decryption key" may comprise any data value or other information suitable for decrypting encrypted data. In some cases, the encryption key and the decryption key may be the same (i.e., a "symmetric key").
The "password" may include encrypted information. For example, the password may be a set of text encrypted with an encryption key.
An "access device" may be any suitable device that provides access to a remote system. The access device may also be used to communicate with a merchant computer, a transaction processing computer, an authentication computer, or any other suitable system. The access device may generally be located at any suitable location, for example, at a merchant location. The access device may have any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, PDAs, Personal Computers (PCs), tablet PCs, hand-held dedicated readers, set-top boxes, Electronic Cash Registers (ECRs), Automated Teller Machines (ATMs), Virtual Cash Registers (VCRs), kiosks, security systems, access systems, and the like. The access device may use any suitable contact or contactless mode of operation to send or receive data to or from the user device or to associate with the user device. In some embodiments where the access device may comprise a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer readable medium. The reader may include any suitable contact or contactless mode of operation. For example, an exemplary card reader may include a Radio Frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader to interact with a user device. In some embodiments, a cellular phone, tablet or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or "mPOS" terminal.
An "authorization request message" may be an electronic message requesting authorization for a transaction. In some embodiments, an authorization request message is sent to the transaction processing computer and/or the issuer of the payment card to request transaction authorization. The authorization request message according to some embodiments may conform to ISO8583, ISO8583 being a standard of a system for exchanging electronic transaction information associated with payments made by users using payment devices or payment accounts. The authorization request message may include an issuer account identifier that may be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): a service code, CVV (card verification value), dCVV (dynamic card verification value), PAN (primary account number or "account number"), payment token, user name, expiration date, and the like. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, acquiring Bank Identification Number (BIN), card acceptor ID, information identifying the item being purchased, etc., and any other information that may be used to determine whether to identify and/or authorize the transaction.
The "authorization response message" may be a message that replies to the authorization request. In some cases, the authorization response message may be an electronic message reply to the authorization request message generated by the issuing financial institution or the transaction processing computer. The authorization response message may include (by way of example only) one or more of the following status indicators: approval-the transaction is approved; decline-transaction not approved; or call center-in response to more information pending, the merchant must call the toll free authorization phone number. The authorization response message may also include an authorization code, which may be a code indicating that the transaction is approved that the credit card issuing bank returned to the merchant's access device (e.g., POS device) in response to the authorization request message in the electronic message (either directly or through the transaction processing computer). The code may be used as proof of authorization. As noted above, in some embodiments, the transaction processing computer may generate or forward an authorization response message to the merchant.
A "server computer" may include a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a minicomputer cluster, or a group of servers that function as a unit. In one example, the server computer may be a database server coupled to a network server. The server computer may be coupled to the database and may include any hardware, software, other logic, or combination of the preceding for servicing requests from one or more client computers.
FIG. 1 shows a system 100 that includes several components. The system 100 includes a user device 115 operated by a user 110. The system 100 further includes a resource provider computer 130, a transmission computer 140, a transaction processing computer 150, and an authorized entity computer embodying computer 160, each of which may be embodied by one or more computers. The user device 115 may connect and/or communicate with the access device 125, which in turn may communicate with the resource provider computer 130. Further, the resource provider computer 130, the transport computer 140, the transaction processing computer 150, and the authorizing entity computer 160 may all be in operable communication with one another over any suitable communication channel or communication network. Suitable communication networks may be any one and/or combination of the following: direct interconnects, the internet, Local Area Networks (LANs), Metropolitan Area Networks (MANs), an executive task as an internet node (OMNI), a secure custom connection, a Wide Area Network (WAN), a wireless network (e.g., using a protocol such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.), and so forth.
Messages between computers, networks, and devices may be transmitted using secure communication protocols such as, but not limited to, File Transfer Protocol (FTP); hypertext transfer protocol (HTTP); secure hypertext transfer protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), and the like.
An example of a user device 115 according to some embodiments of the present invention is shown in fig. 2. As shown, in some embodiments, the user device 115 may take the form of a card that includes a plastic substrate 115(s). In some embodiments, the user device 115 may include a contact element 115(c), the contact element 115(c) being present on the plastic substrate 115(s) or embedded within the plastic substrate 115(s). The contact element 115(c) may include a microprocessor and/or memory (e.g., a memory chip in which user data is stored). The contact element 115(c) may interface and communicate the user device 115 with the access device 125. In some embodiments, the contactless element 115(o) for interfacing with the access device may also be on the plastic substrate 115(s) or embedded in the plastic substrate 115(s). The magnetic strip 115(n) may also be on a plastic substrate 115(s). The identification information 115(p) may be printed or embossed on the card. The identification information may include, for example, a card number, an expiration date, and/or a user name.
User 110 may use user device 115 to conduct transactions with a resource provider associated with resource provider computer 130. The user device 115 may store information associated with the user 110 and/or the account (e.g., at the contact element 115 (c)). For example, the user device 115 may be a smart payment card, and the contact element 115(c) may store payment credentials as well as personal information, such as a name, address, email address, phone number, or any other suitable identifying information 115 (p). Contact element 115(c) may provide this information to access device 125 during a transaction. User device 115 may be assigned to user 110 by an authorized entity, such as an issuer bank.
Referring again to FIG. 1, resource provider computer 130 may be associated with a resource provider, which may be an entity capable of providing resources such as goods, services, information, and/or access. Examples of resource providers include merchants, access devices, secure data access points, and the like. A merchant may generally be an entity that participates in a transaction and is able to sell or provide access to goods or services.
The resource provider may accept multiple forms of payment (e.g., user device 115) and may use multiple instruments to perform different types of transactions. For example, a resource provider may operate a brick and mortar store and use the access device 125 for an on-the-fly transaction. The resource provider may also sell goods and/or services via a website and may accept payments over the internet.
An example of an access device 125 according to some embodiments of the present invention is shown in fig. 3. The access device 125 may include: a processor 125(c) operatively coupled to a computer-readable medium 125(d) (e.g., one or more memory chips, etc.); input elements 125(b) such as buttons and the like; one or more card readers 125(a) (e.g., contact chip readers, contactless readers, magnetic stripe readers, etc.); output devices 125(e) (e.g., a display, speakers, etc.); and a network interface 125 (f). The housing may house one or more of these components.
The computer-readable medium 125(d) may include instructions or code that are executable by a processor. The instructions may include instructions for sending commands to the user device 115 upon contact with the device, as well as instructions for communicating with the user device 115 to obtain credentials and otherwise process the transaction. The computer-readable medium 125(d) may also include instructions for requesting authorization of a transaction with the authorizing entity computer 160, as well as instructions for any other suitable function as described herein.
Referring again to fig. 1, the transmission computer 140 may be associated with an acquirer, which may generally be a business entity (e.g., a business bank) that has a business relationship with a particular merchant or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may include such a single entity issuer-acquirer. The transmitting computer 140 may be more specifically referred to as an acquirer computer.
A transaction processing computer 150 may be disposed between the transfer computer 140 and the authorizing entity computer 160. The transaction processing computer 150 may include data processing subsystems, networks, and operations to support and deliver authorization services, exception file services, and clearing and settlement services. For example, the transaction processing computer 150 may include a server coupled to a network interface (e.g., through an external communication interface) and an information database. Transaction processing computer 150 may represent a transaction processing network. An exemplary transaction processing network may include VisaNetTM. Such as VisaNetTMCan process credit card transactions, debit card transactions, and other types of commercial transactions. VisanetTMSpecifically including a VIP system (Visa integrated payment system) that processes authorization requests and a Base II system that performs clearing and settlement services. The transaction processing computer 150 may use any suitable wired or wireless network, including the internet.
Authorization entity computer 160 may be associated with an authorization entity, which may be an entity that authorizes a request. An example of an authorized entity may be an issuer, which may generally refer to a business entity (e.g., a bank) that maintains a user account. The issuer may also issue and manage payment accounts associated with the user device 115.
The transaction processing computer 150, the transfer computer 140 and the authorizing entity computer 160 may run appropriate routing tables to route the authorization request message and/or the authorization response message using the payment credentials, the merchant identifier or other account identifier.
A method 400 according to an embodiment of the invention may be described with reference to fig. 4. Some elements in other figures will also be referenced.
In embodiments of the present invention, the steps shown in method 400 and the steps shown in fig. 5-7 may be performed sequentially or in any suitable order. In some embodiments, one or more of the steps may be optional.
The various messages described below and with respect to fig. 5-7 may use any suitable form of communication. In some embodiments, the request or response may be in an electronic message format, such as an email, a Short Message Service (SMS) message, a Multimedia Message Service (MMS) message, a hypertext transfer protocol (HTTP) request message, a Transmission Control Protocol (TCP) packet, a web page form submission. The request or response may be directed to any suitable location, such as an email address, a telephone number, an Internet Protocol (IP) address, or a Uniform Resource Locator (URL). In some embodiments, the request or response may include a mix of different message types, such as both an email message and an SMS message.
The method 400 provides for a faster communication exchange between the user device 115 and the access device 125 during a transaction. As mentioned above, this method may be used for any suitable type of transaction, such as a payment transaction, an access transaction, an authentication transaction, etc., which may involve any suitable type of value, such as a monetary amount, an identity credential, a password, a data value, etc. However, for explanatory reasons, a payment transaction for authorizing an amount of funds is described below.
At step S410, a transaction may begin. For example, the user 110 may approach the access device 125 at a resource provider location to purchase one or more goods and/or services. Access device 125 may begin receiving information about the items purchased and summing the amount of each item (e.g., during an "ECR or electronic cash register reimbursement" process).
At step S415, the access device 125 may request the user 110 to provide the user device 115. The user 110 may then provide the user device 115 to the access device 125. For example, the user device 115 may be plugged into the access device 125 or otherwise physically connected to the access device 125. A contact interface (e.g., a chip board) on the user device 115 may come into direct contact with a second contact interface at the access device 125. As a result, the access device 125 is able to communicate with the user device 115 for transaction processing.
In some embodiments, the total transaction amount may not have been fully calculated when the user device 115 was initially inserted. For example, the transaction may occur at a grocery store, and the user 110 may plug into the user device 115 before all items are entered into the access device 125 by a store clerk.
Further, in some embodiments, the user device 115 may generate and provide a password for the transaction, and the password may be based on the transaction amount. Thus, the user device 115 may wait until a transaction amount is received from the access device 125 before generating the password.
At step S420, the access device 125 may generate or identify a preset or estimated amount that may be used before determining the actual transaction amount. The access device 125 can provide this estimated amount to the user device 115 so that the user device 115 can generate a password with the estimated amount. As a result, transaction processing may continue immediately without waiting for all items to be scanned. This may allow the communication between the access device 125 and the user device 115 to be completed more quickly, allowing the user 110 to remove the user device 115 from the access device 125 earlier.
The estimated amount may be determined based on the resource provider, the Merchant Category Classification (MCC), the type of transaction, the median transaction amount for the resource provider, or any other suitable consideration. For example, if the transaction at the resource provider is typically in the range of $ 30 to $ 35, the estimated amount may be set to $ 31.11 (e.g., the average amount). In some embodiments, using an estimated amount within a normal range (e.g., an amount within $ 30 to $ 35 for the example above) may be used to authenticate the authorization request at the issuer (e.g., because the issuer may know the resource provider's normal transaction amount range).
In some embodiments, the estimated amount may be preset as a random number or any other suitable number. Additionally, in some embodiments, the estimated amount may be the same for each transaction, or may vary periodically (e.g., for each transaction or once per day).
At step S425, the access device 125 may perform transaction processing communications with the user device 115. For example, the access device 125 may provide the estimated amount to the user device 115 and may request credentials (e.g., payment credentials, passwords, etc.) for the transaction from the user device 115. The user device 115 may provide credentials to the access device 125, and the credentials may include a password such as an authorization request password (ARQC), a Transaction Certificate (TC), or an application authentication password (AAC). A detailed example of the interaction between the access device 125 and the user device 115 at step S425 is further described below with respect to fig. 6.
At step S430, the access device 125 may determine whether the user device 115 provides a password (e.g., ARQC) for online transaction processing. For example, the user device 115 may have provided a password, but the password may be ARQC, TC, or AAC. If the user device 115 provides the ARQC, the access device 125 is able to perform online authorization and may proceed to step S440. The password may be based at least on the estimated transaction amount, the access device ID, and any other suitable information.
At step S435, if the access device 125 does not receive the ARQC from the user device 115, the access device 125 may end (e.g., cancel) the transaction. For example, access device 125 may have received AAC, which may indicate that user device 115 declined the transaction. In some embodiments, the access device 125 may not continue to step S440, but may continue with an alternative process. For example, the access device 125 may continue to process online transactions, but may not release the user device 115 until authorization by the issuer is received. Alternatively, access device 125 may perform a downlink authorization.
At step S440, the access device 125 may store the information received from the user device 115 (e.g., if ARQC is received at step S430). For example, the access device 125 may temporarily retain payment credentials, transaction passwords, and any other suitable information received from the user device 115. The information may be stored such that the access device 125 may still use the information in the authorization request message after the user device 115 is removed. This may allow the user device 115 to be removed before the authorization request message is generated or sent.
At steps S445-S455, the access device 125 may allow the user device 115 to be removed. The access device 125 may have received the information needed to process the transaction, so the user device 115 may no longer be needed.
In some embodiments, the access device 125 may allow the user device 115 to be removed by completing a transactional communication between the access device 125 and the user device 115. Completing a transaction communication with the user device 115 may cause the user device 115 to reset to a default setting such that the user device 115 has a clean status and is ready for another later transaction.
In some embodiments, to complete the transaction with the user device 115, the access device 125 may request a second password from the user device 115. Upon requesting the second password, the access device 125 may notify the user device 115 to: the online authorization is not feasible (e.g., due to a bad connection), the online authorization is successful, or the authorization is denied.
As an example, at step S445, the access device 125 may notify the user device 115 that an online connection is not available, meaning that authorization may not be completed online, that the transaction should be denied or that authorization is deferred. For example, the authorization response code may be set to indicate that an online connection is not available. Next, at step S450, the user device 115 may return a second password (e.g., AAC), indicating that the transaction is denied or that authorization may be deferred. Receipt of the second password may indicate that the transaction communication is complete between the access device 125 and the user device 115. Thus, the user device 115 may be safely removed at this time.
At step S455, the user 110 may remove the user device 115 from the access device 125. For example, the access device 125 may prompt the user 110 to remove the user device 115. A visual display may be presented, an audible sound may be played, a store clerk may notify user 110, or any other method may be used to notify user 110 that user device 115 may be removed.
Thus, after a short time in the access device 125, the user device 115 may be removed. The user 110 may not have to wait for the entire transaction amount to be calculated or for an authorization response message to be received. Indeed, the user device 115 data may be stored and the user device 115 may be released even before the authorization request message is sent. As a result, the user device 115 may be removed within two seconds after contacting the access device 125. This can reduce contact time by more than eighteen seconds (90%) compared to the existing possible insertion time of twenty seconds or longer.
Furthermore, the user device 115 may be removed in a clean state even if removed earlier than normal by requesting the second password earlier than normal (e.g., before receiving the authorization response message). In fact, the access device 125 may actually have an online connection and the access device 125 may not have received the authorization response message. However, the access device 125 may substantially provide false information to the user device 115 so that the user device 115 may complete its transaction process and be removed earlier than normal.
As mentioned above, the information received from the user device 115 at step S425 may be retained and transaction processing may continue even if the user device 115 is removed. Even though access device 125 may receive AAC, the access device may not deny the transaction and may actually continue to process the transaction as normal. For example, the access device 125 may continue to update the total transaction amount as new items are entered, and eventually the access device 125 may submit an authorization request message for the transaction.
At step S460, the access device 125 may have received information about all purchased items. For example, a store clerk may complete scanning each item. As a result, a final transaction amount may be determined and the ECR reimbursement process may be completed.
At step S465, once the total transaction amount has been determined, the user 110 may confirm the actual transaction amount. For example, the access device 125 may display the total amount and the user 110 may indicate acceptance (e.g., by pressing a key on a password keypad or providing a signature). The actual transaction amount may be different from the preset or estimated amount.
At step S470, the access device 125 (or resource provider computer 130) may generate and send an authorization request message for the transaction. The authorization request message may include the actual transaction amount, an estimated or preset amount, user device 115 credentials (e.g., payment credentials, ARQC, etc.), and any other suitable information.
In some embodiments, the authorization request message may be generated early in the process, and the authorization request message may be modified to include the actual amount of money after the knowledge. In some embodiments, the actual amount may be included as data in a supplemental or actual data field in the authorization request message.
The authorization request message may be sent to the transfer computer 140, which the transfer computer 140 may forward to the transaction processing computer 150, which in turn may forward to the authorizing entity computer 160 by the transaction processing computer 150. Authorization entity computer 160 may determine whether to authorize the transaction. For example, the authorizing entity computer 160 may verify the password (e.g., ARQC), check that the user's account has sufficient funds, perform a risk analysis, and perform any other steps to determine whether to authorize the transaction. The authorizing entity computer 160 may then send an authorization response message back to the access device 125 (e.g., via the transaction processor computer 150, the transmission computer 140, and/or the resource provider computer 130) indicating successful authorization.
At step S475, access device 125 may receive an authorization response message from authorizing entity computer 160 indicating that the transaction was approved or denied. The access device 125 may display an appropriate message to the user 110 and/or store clerk and the resource provider may release the purchased goods and/or services to the user 110.
At some point in time, clearing and settlement processes may take place between the transfer computer 140, the transaction processing computer 150 and the authorizing entity computer 160.
Since the user device 115 is no longer connected to the access device 125 when the authorization response message is received, the user device 115 may not receive information from the authorizing entity computer 160. For example, the user device 115 may not receive or authenticate an Authorization Response Password (ARPC) from an authorizing entity, the user device 115 may not receive an issuer script, and the user device 115 may not receive an updated count (e.g., an offline transaction count). However, all this data can only be used in an offline transaction scenario, where transactions are performed online may not provide any useful functionality. As a result, the user device 115 is still useful even though this information may be lost.
As described above, by using the estimated amount and starting the transaction with this amount (e.g., the "authorized amount" field when communicating with the user device 115), the amount of time the user device needs to be inserted into the access device is minimized. This is because the communication between the user device and the access device can be completed without waiting for the actual transaction amount to be calculated.
Additionally, the access device 125 may notify the user device 115 that authorization is denied (e.g., due to a wireless connection) so that the user device 115 may return to a clean state and then be removed. The user device 115 data may be stored for final processing in determining the final transaction amount. Thus, the insertion time may be further reduced, since the user equipment 115 may be removed before the authorization request message is sent and before the authorization response message is received.
Additionally, in some embodiments, signature capture may be deferred (e.g., so that the user device 115 may be removed before capturing the signature). In some embodiments, if the final amount is less than the payment limit, signature capture may not be required. On the other hand, if the final amount is greater than the payment limit, the user signature may also be captured after transaction approval.
In some embodiments, implementation of this method does not require changes to standard transaction processing routines, associated hardware, or user equipment. This approach of making the user device insertion time shorter can be achieved with a minor software update to the access device 125 communication program. In addition, the changes made to implement this method do not cause any reduction in security. The password strength and overall transaction security can be maintained and online authorization can still be performed in the same secure manner.
In some embodiments, the total transaction amount may be determined and known before the user 110 provides the user device 115 to the access device 125. For example, at a restaurant, after receiving food and services, payment may be provided and user 110 may provide payment after the transaction amount has been calculated. Thus, in some embodiments, transactions may be processed without an estimated amount. A method 500 for performing such a transaction according to an embodiment of the invention may be described with reference to fig. 5.
At step S510, a transaction may begin. For example, the user 110 may approach the access device 125 at a resource provider location to purchase one or more goods and/or services. In some embodiments, the final transaction amount may be known or determined at this time. For example, the user's items may have been scanned at the access device 125, the user 110 may purchase only one item that was quickly scanned at the access device 125, or the user 110 may provide payment for goods or services (e.g., food at a restaurant) that have been obtained. In some embodiments, the ECR reimbursement process may end when the final transaction amount is known (e.g., the amount is ultimately determined at the access device 125 because all items have been scanned).
At step S515, the access device 125 may request the user 110 to provide the user device 115. For example, the access device 125 may prompt the user 110 to provide the user device 115 as soon as the ECR reimbursement process is complete. The user 110 may then provide the user device 115 to the access device 125. For example, the user device 115 may be plugged into the access device 125 or otherwise physically connected to the access device 125. A contact interface (e.g., a chip board) on the user device 115 may come into direct contact with a second contact interface at the access device 125. As a result, the access device 125 is able to communicate with the user device 115 for transaction processing.
At step S520, the user 110 may confirm the amount of the transaction. For example, the access device 125 may display the total amount and the user 110 may indicate acceptance (e.g., by pressing a key on a password keypad or providing a signature). In some embodiments, the user 110 may confirm the amount before providing the user device 115, while inserting the user device 115, after removing the user device 115, or at any other suitable point in the flow.
At step S525, the access device 125 may perform transaction processing communications with the user device 115. For example, the access device 125 may provide the transaction amount to the user device 115 and may request credentials (e.g., payment credentials, passwords, etc.) for the transaction from the user device 115. The user device 115 may provide credentials to the access device 125, which may include a password (e.g., ARQC, TC, or AAC). A detailed example of the interaction between the access device 125 and the user device 115 at step S525 is further described below with respect to fig. 6.
At step S530, the access device 125 may determine whether the user device 115 provides a password (e.g., ARQC) for online transaction processing. For example, the user device 115 may have provided a password, but the password may be ARQC, TC, or AAC. If the user device 115 provides the ARQC, the access device 125 is able to perform online authorization and may proceed to step S540. The password may be based at least on the final transaction amount, the access device ID, and any other suitable information.
At step S535, if the access device 125 does not receive the ARQC from the user device 115, the access device 125 may end (e.g., cancel) the transaction. For example, access device 125 may have received AAC, which may indicate that user device 115 declined the transaction. In some embodiments, the access device 125 may not continue to step S440, but may continue with an alternative process. For example, the access device 125 may continue to process online transactions, but may not release the user device 115 until authorization by the issuer is received. Alternatively, access device 125 may perform a downlink authorization.
At step S540, the access device 125 may store the information received from the user device 115 (e.g., if ARQC is received at step S430). For example, the access device 125 may temporarily retain payment credentials, passwords, and any other suitable information received from the user device 115. The information may be stored such that the access device 125 may still use the information in the authorization request message after the user device 115 is removed. This may allow the user device 115 to be removed before the authorization request message is generated or sent.
At steps S545-S555, the access device 125 may allow the user device 115 to be removed. The access device 125 may have received the information needed to process the transaction, so the user device 115 may no longer be needed.
In some embodiments, the access device 125 may allow the user device 115 to be removed by completing a transactional communication between the access device 125 and the user device 115. Completing a transaction communication with the user device 115 may cause the user device 115 to reset to a default setting and/or a dormant state such that the user device 115 has a clean state and is ready for another later transaction.
In some embodiments, to complete the transaction with the user device 115, the access device 125 may request a second password from the user device 115. Upon requesting the second password, the access device 125 may notify the user device 115 to: the online authorization is not feasible (e.g., due to a bad connection), the online authorization is successful, or the authorization is denied.
As an example, at step S545, the access device 125 may notify the user device 115 that an online connection is not available, meaning that authorization may not be completed online, that the transaction should be denied or that authorization is deferred. For example, the authorization response code may be set to indicate that an online connection is not available. Next, at step S550, the user device 115 may return a second password (e.g., AAC), indicating that the transaction is denied or that authorization may be deferred. Receipt of the second password may indicate that the transaction communication is complete between the access device 125 and the user device 115. Thus, the user device 115 may be safely removed at this time.
At step S555, the user 110 may remove the user device 115 from the access device 125. For example, the access device 125 may prompt the user 110 to remove the user device 115. A visual display may be presented, an audible sound may be played, a store clerk may notify user 110, or any other method may be used to notify user 110 that user device 115 may be removed.
Thus, after a short time in the access device 125, the user device 115 may be removed. User 110 may not have to wait for an authorization response message to be received. Indeed, the user device 115 data may be stored and the user device 115 may be released even before the authorization request message is sent. As a result, the user device 115 may be removed within two seconds after contacting the access device 125. This can reduce contact time by more than eighteen seconds (90%) compared to the existing possible insertion time of twenty seconds or longer.
Further, the user device 115 may be removed in the clean state and/or the sleep state by requesting the second password earlier than normal (e.g., before receiving the authorization response message), even if removed earlier than normal. In fact, the access device 125 may actually have an online connection and the access device 125 may not have received the authorization response message. However, the access device 125 may substantially provide false information to the user device 115 so that the user device 115 may complete its transaction process and be removed earlier than normal.
As mentioned above, the information received from the user device 115 at step S525 may be retained and transaction processing may continue even if the user device 115 is removed. Even though access device 125 may receive AAC, the access device may not deny the transaction and may actually continue to process the transaction as normal. For example, the access device 125 may submit an authorization request message for the transaction.
At step S560, the access device 125 (or the resource provider computer 130) may generate and send an authorization request message for the transaction. The authorization request message may include the transaction amount, the user device 115 credentials (e.g., payment credentials, ARQC, etc.), and any other suitable information.
In some embodiments, the user device 115 may still be connected to the access device 125 at the time the authorization request message is sent. For example, the authorization request message may be generated and sent quickly, such that the message is sent before the user 110 removes the user device 115.
The authorization request message may be sent to the transfer computer 140, which the transfer computer 140 may forward to the transaction processing computer 150, which in turn may forward to the authorizing entity computer 160 by the transaction processing computer 150. Authorization entity computer 160 may determine whether to authorize the transaction. For example, the authorizing entity computer 160 may verify the password (e.g., ARQC), check that the user's account has sufficient funds, perform a risk analysis, and perform any other steps to determine whether to authorize the transaction. The authorizing entity computer 160 may then send an authorization response message back to the access device 125 (e.g., via the transaction processor computer 150, the transmission computer 140, and/or the resource provider computer 130) indicating successful authorization.
At step S565, access device 125 may receive an authorization response message from authorizing entity computer 160 indicating that the transaction was approved or denied. The access device 125 may display an appropriate message to the user 110 and/or store clerk and the resource provider may release the purchased goods and/or services to the user 110.
At some point in time, clearing and settlement processes may take place between the transfer computer 140, the transaction processing computer 150 and the authorizing entity computer 160.
Since the user device 115 may no longer be connected to the access device 125 upon receipt of the authorization response message, the user device 115 may not receive information from the authorizing entity computer 160. For example, the user device 115 may not receive or authenticate an Authorization Response Password (ARPC) from an authorizing entity, the user device 115 may not receive an issuer script, and the user device 115 may not receive an updated count (e.g., an offline transaction count). However, all this data can only be used in an offline transaction scenario, where transactions are performed online may not provide any useful functionality. As a result, losing this information may not be any loss of functionality to the user device 115.
As described above, in some embodiments, the transaction amount may be known immediately before or after the user device 115 is inserted into the access device 125. Thus, the user device 115 may immediately receive the transaction amount and then generate a password based on the transaction amount. As a result, communication between the user device 115 and the access device 125 may be completed quickly after insertion of the user device 115.
In some embodiments, the user device 115 may be removed immediately after being inserted into the access device 125. Additionally, the access device 125 may notify the user device 115 that authorization is denied (e.g., due to no online connection) so that the user device 115 may return to a clean and/or dormant state and then be removed. The user device 115 data may be stored for authorization processing after the user device 115 is removed. Thus, the insertion time may be reduced since the user device 115 may be removed without waiting for an authorization response and any subsequent processing.
Additionally, signature capture may be deferred (e.g., so that the user device 115 may be removed prior to capturing the signature). In some embodiments, if the final amount is less than the payment limit, signature capture may not be required. On the other hand, if the final amount is greater than the payment limit, the user signature may also be captured after transaction approval.
In some embodiments, implementation of this method does not require changes to standard transaction processing routines, associated hardware, or user equipment. This approach of making the user device insertion time shorter can be achieved with a minor software update to the access device 125 communication program. In addition, the changes made to implement this method do not cause any reduction in security. The password strength and overall transaction security can be maintained and online authorization can still be performed in the same secure manner.
Embodiments of the present invention may involve many communications between the user device 115 and the access device 125. For example, in step S425 in method 400 and step S525 in method 500, several messages may be exchanged in order to process the transaction and obtain information from the user device 115. An example flow 600 of these communications is shown in fig. 6.
When the user device 115 contacts the access device 125, the user device 115 and the access device 125 are able to communicate. Several processing steps may be performed in order to identify and prepare data for transmission to the access device 125 for a transaction. In some embodiments, Application Protocol Data Unit (APDU) messages may be exchanged between the user device 115 and the access device 125. The message may be in the form of an APDU command sent from the access device 125 to the user device 115 and an APDU response sent from the user device 115 to the access device 125. However, it should be appreciated that other messages, messaging protocols, or formats may be used to exchange information relevant to performing a transaction.
At step S610, the access device 125 may perform application selection. For example, the access device 125 may determine which applications are supported by both the user device 115 and the access device 125. In some embodiments, when the access device 125 detects the presence of the user device 115, the access device 125 may send an available application request to the user device 115 requesting information about which payment applications are available (e.g., a list of AIDs) at the user device 115. In some embodiments, the available application request may be in the form of a selection command.
The user device 115 may respond by sending an available application response back to the access device 125. The available application response may include a list of available AIDs. In some embodiments, the available application response may be in the form of a selection response.
The access device 125 may then select an appropriate application from the list of applications received in the available application response (e.g., by selecting an AID from the available AIDs). For example, the access device 125 may select a payment application (e.g., a highest priority application) supported by both the access device 125 and the user device 115. In some embodiments, the access device 125 may display commonly supported applications and allow the user 110 to select the application for transactional use.
The access device 125 may also transmit an application selection message with the selected AID to the user device 115. In some embodiments, the application selection may be in the form of a read record command or a select AID (or ADF) command.
The user device 115 may then send a request to the access device 125 for transaction data that may be needed to perform a transaction using the selected application/AID. In some embodiments, the request may be in the form of a read record response or a select AID (or ADF) response. The request may include a list of transaction data identifiers, and the list may be in the form of a processing option data object list (PDOL). The requested transaction data may include a Terminal Transaction Qualifier (TTQ), an authorization amount, other amounts, a terminal country code, a terminal verification result, a transaction currency code, transaction data, a transaction type, and/or unpredictable numbers.
At step S620, the access device 125 may initiate application processing. For example, the access device 125 may request data (e.g., a list of files containing data) that the user device 115 indicates the selected application and supported function usage. In some embodiments, access device 125 may send a Get Processing Options (GPO) command. The access device 125 may also provide transaction information to the user device 115 (e.g., via GPO commands). For example, the access device 125 may provide transaction data requested by the user device 115 by processing a list of option data objects (PDOLs). The transaction data provided may include a transaction amount, such as a final transaction amount or an estimated transaction amount (e.g., if the final transaction amount is not yet known).
The user device 115 may then generate dynamic transaction processing information using at least some of the received terminal transaction data and send a set of transaction processing information to the access device 125. In some embodiments, the transaction processing information may be sent in the form of a GPO response. In some embodiments, the transaction processing information may include one or more Application File Locators (AFLs) that may be used by the access device 125 as file addresses to read account data stored on the user device 115.
At step S630, the access device 125 may read the application data. For example, the access device 125 may send an account data request to the user device 115 to read account data stored at the user device 115. In some embodiments, the account data request may be in the form of a read record command and may include an Application File Locator (AFL) indicating the location of the account data.
The user device 115 may then transmit the account data to the access device 125. In some embodiments, the account data may be sent in the form of a read record response. The account data may include, for example, 2-track equivalent data (e.g., payment credentials) and cardholder name, and/or other account-related data accessible at the AFL location.
One or more authentication and verification steps may be performed to verify that the transaction may proceed. For example, steps S640-S680 provide various authentication procedures. In some embodiments, one or more of these steps may be skipped, as online authentication and/or authorization may be sufficient alternatives.
At step S640, the access device 125 may determine whether the user device 115 should be authenticated offline. This determination may be made based on whether the user device 115 supports offline authentication. In some implementations, one or more types of offline authentication may be performed, such as Static Data Authentication (SDA) or Dynamic Data Authentication (DDA).
At step S650, the access device 125 may check the processing restriction. For example, the access device 125 may determine whether the transaction should be allowed to proceed based on a user device expiration date, a match of applications between the user device 115 and the access device 125, usage restrictions (e.g., restrictions on international purchase or cashback services), and any other suitable restrictions.
At step S660, access device 125 may perform cardholder verification. For example, user 110 may be authenticated as a legitimate user of user device 115, rather than a spoofer. One or more Card Verification Methods (CVMs) may be used. For example, the user 110 may be prompted to provide a PIN (e.g., an authorized entity checks online or the user device 115 checks offline), a signature, or any other suitable authentication method.
At step S670, the access device 125 may perform terminal risk management. For example, access device 125 may perform a speed check, determine whether the transaction exceeds a merchant reserve limit, check whether the amount of money is flagged as denied, determine whether a limit for consecutive transactions has been exceeded, and/or check any other suitable indication of fraud.
At step S680, the access device 125 may perform terminal action analysis. For example, the access device may determine whether the transaction should be approved offline, sent online for authorization, or denied offline. This determination may be based on one or more of the above authentication and risk analysis steps (e.g., steps S640-S670). As noted above, in some embodiments, all transactions may be authorized online. Thus, the access device 125 may automatically continue the online authorization process.
The access device 125 may then request a password from the user device 115 (e.g., via a generate application password command). The access device 125 may specifically request an authorization request password (ARQC), a Transaction Certificate (TC), or an application authentication password (AAC). In some embodiments, ARQC may be requested for online authorization, TC may be requested for offline authorization (e.g., having offline approval), AAC may be requested for transaction denial or authorization deferral.
The user device 115 may then determine which type of password to provide to the access device. For example, the user device 115 may provide ARQC on-line authorization. Alternatively, the user device 115 may determine that the transaction should be denied and may return AAC.
In some embodiments, the ARQC may be generated based on transaction-specific information. For example, the transaction amount received from access device 125 (e.g., in step S620), the transaction ID, the merchant identifier, and any other suitable transaction-related information may be used as inputs to the ARQC generation algorithm. Any other suitable information may also be used as input, such as random numbers, transaction counts, and the like. The ARQC may be generated using an authorized entity key stored in the user device 115 and known at the authorized entity computer 160. Thus, upon receiving the ARQC with the authorization request message, the authorizing entity computer 160 may authenticate the ARQC.
In some embodiments, once the user device 115 sends the password to the access device 125, the communication between the user device 115 and the access device 125 may have achieved its primary purpose (e.g., providing credentials to the access device 125 for a transaction). Thus, steps S610-S680 may include the processing noted in step S425 in method 400 and step S525 in method 500.
The method 600 continues with additional steps to succinctly complete the communication exchange between the access device 125 and the user device 115, remove the user device 115, and authorize the transaction. These steps overlap with the steps already described in relation to fig. 4-5. (e.g., steps S430-S475 in method 400 and steps S630-S565 in method 500).
At step S710, the access device 125 may receive a password from the user device 115 and determine whether to authorize the transaction online. For example, similar to steps S430 and S530, the access device 125 may determine whether the password is ARQC. In some embodiments, if the ARQC is received, the access device 125 may continue the online authorization process.
The access device 125 may store the user device 115 information (e.g., account credentials, passwords, etc.) for later processing (e.g., as mentioned at steps S440 and S540). For example, the final transaction amount may not be known, and thus, the access device 125 may retain the user device 115 information until authorization may be completed.
Once the necessary user device 115 information (e.g., account credentials, passwords, etc.) is received and stored, the user device 115 may no longer be needed at the access device 125. Thus, the communication between the access device 125 and the user device 115 may be completed, removing the user device 115 at an earlier time (as mentioned at steps S445-S455 and S545-S555). For example, the user device 115 may be removed before the final transaction amount is calculated, before the authorization response message is sent, and before the authorization response message is received.
At step S720, the access device 125 may complete the transaction communication with the user device 115 online (e.g., as mentioned with respect to steps S455 and S550). For example, the access device 125 may request a second password from the user device 115, and after providing the second password, the user device 115 may return to the default setting.
The access device 125 may request the second password using the second generate application password command. In some embodiments, access device 125 may request AAC, indicating that the transaction should be denied or deferred because authorization may not be performed online (e.g., as mentioned with respect to steps S445 and S545). In practice, however, authorization may be done online (and may even not have been attempted), and this command may only be used to complete communication with the user device 115. False information about declining or postponing a transaction may have no effect on the actual transaction or any negative effect on the user device 115.
In some embodiments, the access device 125 may alternatively indicate that the transaction was successfully authorized (even if authorization has not already been made) and request the TC.
The user device 115 may then react with the generated application cryptographic response including AAC. The user device 115 may then complete its internal processing, return to a clean, default, and/or hibernation setting, and be ready for removal from the access device 125.
Once the access device 125 receives the second password from the user device 115, the access device 125 may prompt the user 110 to remove the user device 115 from the access device 125 (e.g., as mentioned with respect to steps S455 and S555).
Thus, after one continuous communication flow with the access device 125, the user device 115 may be removed. There may be no communication delay due to calculating the transaction amount or obtaining an online authorization. Indeed, information may be obtained from the user device 115 in a short time, the user device may be removed 125, and the access device 125 may continue processing transactions without connecting to the user device 115.
At step S730, once the final transaction amount is known, the access device 125 may process the transaction online. For example, access device 125 may generate and send an authorization request message to authorizing entity computer 160 for authorization (e.g., as described in steps S470-S475 and steps S560-S565).
Embodiments of the present invention have many advantages. For example, in embodiments of the present invention, transaction processing communications between a user device (e.g., a smart card or an integrated chip card) and an access device may be conducted quickly and efficiently. All communication between the user device and the access device can be done in one immediate streamlined flow without any delay. For example, the access device may provide a transaction value (e.g., a final or estimated value) immediately upon contact with the user device. As a result, the user device may immediately generate a password based on the value (and other information). Further, once the access device receives credentials (e.g., account information and password) from the user device, the access device may complete the transaction communication and the user device may be removed. The user can remove the user device without waiting for an authorization response message or post-authorization processing.
Embodiments of the present invention may advantageously reduce the contact time between the user device and the access device to two seconds or less. Thus, embodiments allow an average reduction of six to seven seconds (75% -83%) compared to the current average of eight to twelve seconds of insertion time, and an eighteen second or more (90% or more) reduction of possible time compared to the current possible insertion time of twenty seconds or more. In addition to the reduction in actual contact time, the user may perceive an even greater reduction in contact time.
Embodiments of the present invention may also advantageously reduce overall transaction time. For example, embodiments allow for post-authorization processing, such as issuer-cardholder processing and issuer authentication at the user device to be eliminated. Eliminating these steps not only reduces the amount of time the user device is inserted into the access device, but also reduces the amount of time the user waits at the access device (e.g., before the user can leave at the point of merchandise and services release). In an embodiment, the user device may not receive issuer response information (e.g., data received in the authorization response message). However, this data may not be necessary for online transactions. Thus, reducing the contact time as described in the present invention may be without any adverse aspects (e.g., no reduction in security, no loss of useful information).
Embodiments of the present invention advantageously allow the user device to have a clean state at the end of a transaction, even if the user device is removed earlier than conventionally. For example, the access device may request the second password earlier than normal (e.g., by not actually indicating a failed online connection) so that the user device may complete its transaction processing and then be removed.
The embodiments of the present invention may be advantageously implemented without requiring changes to hardware, EMV transaction processing standards, and user equipment. In fact, software updates on the access device may implement the new steps and communications described in the present invention.
A computer system will now be described that may be used to implement any of the entities or components described herein. Subsystems in a computer system are interconnected via a system bus. Additional subsystems include a printer, a keyboard, a fixed disk, and a monitor, which may be coupled to a display adapter. Peripheral devices and input/output (I/O) devices may be coupled to the I/O controller and may be connected to the computer system by any number of means known in the art, such as a serial port. For example, the computer apparatus may be connected to a wide area network such as the internet, a mouse input device, or a scanner using a serial port or an external interface. The interconnection via a system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from the system memory or the fixed disk and the exchange of information between subsystems. The system memory and/or fixed disk may embody a computer readable medium.
As described above, a service of the present invention may involve carrying out one or more functions, procedures, operations, or method steps. In some embodiments, the functions, procedures, operations, or method steps may be implemented as a result of execution of a set of instructions or software code by a suitably programmed computing device, microprocessor, data processor, or the like. The set of instructions or software code may be stored in a memory or other form of data storage element accessed by a computing device, microprocessor, or the like. In other embodiments, the functions, procedures, operations, or method steps may be implemented by firmware, or by a special purpose processor, an integrated circuit, or the like.
Any of the software components or functions described in this application may be implemented as software code 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 or floppy disk, such as a hard drive, or an optical medium, such as a CD-ROM. Any such computer-readable medium may reside on or within a single computing device, and may exist on or within different computing devices within a system or network.
Although a few exemplary embodiments have been described in detail and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific arrangements and instrumentalities shown and described, since various other modifications may occur to those ordinarily skilled in the art.
As used herein, the use of "a", "an", or "the" is intended to mean "at least one" unless explicitly indicated to the contrary.