Cross-border Quick Response (QR) payment flows for encrypted primary account number (PAN) payment flows

Abstract

A computer-implemented system for simplifying the encrypted payload of a card transaction in a transaction code transaction conducted via a merchant within a restricted computer network firewall. A wallet application stores payment device data and retrieves merchant and transaction information via the transaction code. In response to the retrieved information, the wallet application generates an encrypted payload. The wallet application sends the encrypted payload to a payment facilitator within the restricted computer network firewall. After decrypting the encrypted payload, the payment facilitator sends the decrypted payload in a payment data packet to a payment processing server outside the restricted computer network firewall. After the payment processing server verifies the payment transaction, the payment processing server sends a payment notification from outside the restricted computer network firewall to the merchant within the restricted computer network firewall.

Description

Technical Field

[0001]

[0014] Embodiments discussed herein generally relate to converting Quick Response (QR) payment flows to encrypted Primary Account Number (PAN) payment flows both inside and outside of restricted computer network firewalls. Background Art

[0002] The use of cashless payment devices such as credit cards is no longer restricted to regional or limited geographic areas. From card issuers' promotional campaigns that waive international transaction fees to merchants' wider acceptance of these devices even if they are charged transaction fees, consumers are able to use these devices conveniently without having to worry too much about their acceptance.

[0003] However, due to national policies, some countries enforce restrictive computer network firewalls to limit the flow of network data in and out of the country. For example, the People's Republic of China has established a restrictive computer network firewall that restricts the general flow of network packets. Unless an exception or exemption is obtained from the national government, this restriction may cause data access problems for travelers.

[0004] Unfortunately, this restriction can leave card acceptance points in China extremely limited, making it nearly impossible for cashless cardholders to pay with plastic cards while traveling.

[0005] Thus, embodiments attempt to solve or address one or more of the identified problems. Summary of the Invention

[0006] Various aspects of the present invention overcome the deficiencies of existing arrangements by creating a cross-border digital wallet application and a combination of converting transaction code-based transactions (e.g., Quick Response (QR) code-based transactions) to encrypted primary account number (PAN)-based payment flows. In one embodiment, the cross-border wallet application enables a consumer or cardholder traveling to a country with a restrictive computer network firewall, such as the People's Republic of China, to use his or her credit card (e.g., a VISA credit card) in a form factor commonly accepted in that country.

[0007] In another embodiment, merchants that accept QR code payments from mobile devices, either through a QR code presented by a consumer or a QR code presented by a merchant, can receive payments from a cross-border digital wallet application ("wallet app"). In one embodiment, according to aspects of the present invention, merchants can display multiple QR codes and / or a consolidated single QR code for existing consumers. This consolidated single QR code can be displayed and scanned by any participating wallet app. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Those skilled in the art will appreciate that the elements in the figures are illustrated for simplicity and clarity, and therefore not all connections and options are shown. For example, common but well-understood elements that are useful or necessary in commercially viable embodiments may generally not be depicted to facilitate unimpeded viewing of the various embodiments of the present disclosure. It will be further appreciated that specific actions and / or steps may be described or depicted in a particular order of occurrence, and those skilled in the art will appreciate that such specificity regarding order is not actually required. It will also be appreciated that the terms and expressions used herein may be defined relative to their corresponding queries and research areas, unless a specific meaning is otherwise set forth herein.

[0009] Figure 1 is a diagram illustrating a system for facilitating cross-border transactions between wallet app consumers and merchants within a restricted computer network firewall, according to one embodiment.

[0010] Figure 2 is a flow chart illustrating a wallet service of a wallet app according to one embodiment.

[0011] Figure 3 is a diagram illustrating processing of a merchant-presented code transaction within a restricted computer network firewall via a wallet app installed on a mobile device, according to one embodiment.

[0012] Figure 4 is a diagram illustrating processing of a consumer-presented code transaction within a restricted computer network firewall via a wallet app installed on a mobile device, according to one embodiment.

[0013] Figure 5 is a diagram illustrating a portable computing device according to one embodiment.

[0014] Figure 6 is a diagram illustrating a remote computing device according to one embodiment. DETAILED DESCRIPTION

[0015] The embodiments may now be described more fully with reference to the accompanying drawings, which form a part of the embodiments and show, by way of illustration, specific exemplary embodiments that may be practiced. These diagrams and exemplary embodiments may be presented with the understanding that the present disclosure is an example of the principles of one or more embodiments and may not be intended to limit any of the illustrated embodiments. The embodiments may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided to make this disclosure thorough and complete and to fully convey the scope of the embodiments to those skilled in the art. Furthermore, the present invention may be embodied as a method, system, computer-readable medium, device, or apparatus. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Accordingly, the following detailed description may be considered non-limiting.

[0016] Reference Figure 1 , a diagram illustrates a system 100 for facilitating cross-border transactions between wallet app consumers and merchants within a restricted computer network firewall, according to one embodiment. In one embodiment, the system 100 may include a payment processor server 102 configured to execute computer executable instructions for processing cashless payment transactions. For example, cashless payment devices such as credit cards, debit cards, gift cards, prepaid cards, etc. may be cashless payment devices. In another embodiment, the server 102 may interface with a user portal via a web page or other user interface. In another instance, the server 102 may provide a mobile application such as a wallet application ("wallet app") 104 to be installed on a mobile device 106 to interact with the services provided by the server 102. For example, the wallet app 104 enables a consumer 108 to set up an account to store data or link data to one or more cashless payment devices therein. This wallet app 104 may enable the consumer 108 to use one or more hardware elements or components of the mobile device 106 (for more examples and discussion, see Figure 5 ) to contact merchants for transactions.

[0017] In one example, consumer 108 may be traveling abroad and may wish to use one of the cashless payment devices to make a purchase. In a similar scenario, assume that consumer 108 is traveling to a location where a restricted computer network firewall 110 is enforced based on national policy, law, or regulation. For example, restricted computer network firewall 110 restricts computer network traffic or data packets to servers located outside firewall 110. Thus, traffic originating from within firewall 110 will not or will not be delayed in sending data to servers outside firewall 110.

[0018] In another embodiment, aspects of the present invention do not attempt to violate national regulations or laws. Instead, aspects of the present invention aim to comply with national regulations or laws by converting payment streams to be sent at a faster rate than existing methods.

[0019] Returning to the example of consumer 108 traveling abroad, consumer 108 may wish to make a purchase or transaction with merchant 112, which may operate a portal or webpage 114 and include a point of sale (POS) 116 that uses wallet app 104, as wallet app 104 includes one or more accounts for cashless payment devices. In one example, merchant 112's POS 116 may have one or more options for completing the transaction: paying in cash in the local currency, swiping a physical cashless payment device, or scanning a transaction code 118.

[0020] In one embodiment, the consumer 108 may choose to scan the transaction code 118 using a camera associated with the mobile device 106 so that the scanned information from the transaction code 118 may be accepted by the wallet app 104. In one embodiment, the transaction code 118 may be a Quick Response (QR) code, a barcode, or other code (whether two-dimensional or three-dimensional) that embeds transaction information.

[0021] In another embodiment, the wallet app 104 may include an interface (e.g., a graphical user interface) for the consumer 108 to operate a camera to capture the code. It should be understood that other methods may be used by the consumer 108 to obtain the embedded information in the transaction code 118 using the mobile device 106 or the wallet app 104.

[0022] In one example, instead of using a closed-loop payment flow in the embedded information of the transaction code 118, the transaction code 118 of aspects of the present invention may embed information in the form of a universal resource location (URL) and redirect to an HTML page to complete the payment. In another embodiment, the transaction code 118 may not be an EMVCo standard QR code.

[0023] In one embodiment, the wallet app 104 can be initiated by the consumer wallet service (CWS) 120 and the wallet payment service (WPS) 122, and then receive embedded information from the merchant 112 via the transaction code 118 to communicate with the payment facilitator 124. In another embodiment, the CWS 120 can be considered the backend server of the wallet app 104, and the CWS 120 can then call or place a request packet to the WPS 122. In one embodiment, one or more payment facilitators can register and register with the server or payment processor 102 and can call or place requests to the WPS 122 (as described below). In another embodiment, the payment facilitator 124 can also be considered the server of a third-party wallet app in place of the wallet app 104, if permitted, so that the consumer 102 can conduct transactions with the merchant 112. The server or payment processor 102 can issue an outbound encryption key linked to the identification (ID) of the payment facilitator 124 to the payment facilitator 124.

[0024] Reference Figure 2 , a flowchart illustrates a wallet service of a wallet app according to one embodiment. In one embodiment, the flowchart may illustrate a process for a consumer 108 to operate a wallet app 104. For example, when a consumer 108 may first log in to the wallet app 104. For example, a login request may be sent to an authentication and resource manager (ARM) 202, and the entry of the consumer 108 may be forwarded to an identity service 204. For example, the ARM 202 may be configured to execute computer executable instructions for passing a username and password to the identity service 204, which may verify the username and password. In one instance, the identity service 204 may include a server (e.g., Figure 6 ) or a server cluster that can receive entries or inputs such as a username and password from the user. If these two items are valid, the identity service 204 can pass two items back to the ARM 202: an indication that the login was successful, and the user's global user ID (GUID). In one example, the ARM 202 can save the GUID and store it locally, and generate a token and pass it to the wallet app 104. This token can be used for all subsequent requests.

[0025] In another embodiment, upon subsequent requests, the wallet app 104 may send the token to the ARM 202. The ARM 202 may verify the token and then place the GUID into the header of the data packet to the consumer wallet service (CWS) 120 so that the CWS 120 can identify which user is requesting a specific action.

[0026] In another embodiment, the CWS 120 may receive instructions from the consumer 108, or may infer instructions from the consumer 108 due to a default setting, to retrieve or obtain the consumer 108's profile. For example, a "get profile" function may be called to the mobile device 106's device identification (ID), such as may be pushed to the mobile device 106. For example, information such as the address, name, and basic information of one or more cashless payment devices of the consumer 108 may be transferred. In one example, non-sensitive information about each registered card may be forwarded. In another example, transaction history data may be returned if the profile includes such information. For example, a request to the digital commerce platform (DCP) 208 may retrieve the transaction history for each card or payment device. For example, the CWS 120 may receive such data and the DCP 208 storing the information. In another embodiment, the DCP 208 may be supported by a hardware security manager (HSM) (not shown) to store information that meets necessary guidelines, such as geographic information system (GIS) guidelines, for protecting such information. Thus, non-sensitive information about the consumer's 108 card may be retrieved (e.g., last four, card art, etc.). In another embodiment, information about the consumer's 108 default card may also be retrieved.

[0027] As discussed above, the consumer 108 may wish to conduct a transaction with the merchant 112. Thus, the consumer 108 may perform an action such as scanning the code 118 to indicate such intent. Figure 2 , CWS 120 may send the information in the embedded code 118 to WPS 122 .

[0028] As discussed below, due to challenges with restricted computer network firewalls 110, rather than forwarding the code 118 or other purchase information unchanged or unmodified directly to the acquirer, aspects of the present invention modify the data packet to be simplified so that the consumer 108 may not be aware of the difference in how the transaction is processed by the server 102. Utilizing this embodiment, a "set intent" call sends the information from the code 118 and the intent ID to the digital commerce platform (DCP) 208.

[0029] In one example, CWS 120 can retrieve the full primary account number (PAN) and expiration date of the payment device (e.g., default card) from DCP 208. Along with the token, embedded information from code 118, and intent ID, DCP 208 can retrieve the client ID of payment facilitator 124 from WPS 122.

[0030] In another embodiment, WPS 122 can create a data packet with the intent after storing the payment information. In one aspect, WPS 122 can create a code (see below) Figure 4), such as a QR code or barcode pointing to the intent data packet. In another embodiment, WPS 122 can use the client ID to look up the encryption key of each payment facilitator 124.

[0031] In another embodiment, WPS 122 can encrypt the intent packet payload once for each client. WPS 122 can then pass the code 118, intent ID, and token back to CWS 120. CWS 120 can store the intent ID, user GUID, and device ID in a table. In this embodiment, when WPS 122 later passes back a transaction for a specific intent, CWS 120 can know which device to notify, such as mobile device 106.

[0032] In one embodiment, the CWS 120 may store a transaction history (a subset of the information stored in the WPS 122 ), and this transaction history may be retrieved by the wallet app 104 immediately after login so that the history may be displayed on the GUI (e.g., the first page) of the wallet app 104 .

[0033] It should also be understood that the wallet app 104 or CWS 120 may interact with the operating system of the mobile device 106 to issue additional notifications to the mobile device 106 as permitted by the operating system of the mobile device 106 .

[0034] refer to Figure 3 , while referring to Figure 1 , when the merchant 112 presents the code 118 , the flow chart further illustrates an embodiment of the present invention with the payment facilitator 124 .

[0035] For example, as discussed, as a method of facilitating transactions for consumers 108 traveling abroad to locations within a restricted computer network firewall 110, aspects of the present invention create a wallet app 104 to work with a payment service provider 124. For example, the wallet app 104 can collaborate with the payment service provider 124, which can be a local payment aggregator, to leverage its universal acceptance points. Thus, the consumer 18 can scan the transaction code 118, such as a merchant QR code (e.g., mQR), a consumer-side QR code (e.g., cQR), or a barcode on the mobile device 106 (e.g., cBR), to pay for the underlying transaction using one or more payment devices already associated with the wallet app 104, rather than paying in cash in the local currency.

[0036] In further embodiments, aspects of the present invention can enable wallet app 104 to be universally available across national borders. For example, restricted computer network firewall 110 may not be a national computer network firewall, but rather an institutional or corporate computer network firewall. For example, online merchants or marketplaces in a given country may require cashless payment devices to be issued by an issuer in a specific country. When consumer 108 travels to this country, the cards in the consumer's profile may not be issued by an issuer in the destination country. Consequently, a payment processor can be triggered to implement aspects of the present invention to identify a payment facilitator to facilitate transactions between consumer 108 and the online merchant.

[0037] Continue to refer Figure 3 , the flow chart illustrates a use case in which a merchant 112 presents a code 118 for a consumer 108 to capture the contents of the code 118 using a mobile device 106. As discussed, the wallet app 104 can receive embedded information from the code 118, which in one example can be a URL to a link portal or merchant page 114.

[0038] In one embodiment, the URL may be used to retrieve a page from the payment facilitator 124, and the wallet app 104 may display the page in the wallet app 104 via the mobile device 106. This page may include a merchant icon and may allow the consumer 108 to enter the transaction amount.

[0039] In another embodiment, the payment facilitator 124 page may be the portal 114. The consumer 108 may enter the transaction amount and select "Submit" on the wallet app 104. The amount and the page may be submitted to the payment facilitator 124. In another embodiment, the payment facilitator 124 may process the page and content (e.g., the amount and other information such as the merchant ID). Since the payment facilitator 124 is registered with the server or payment processor 102, the payment facilitator 124 may be configured to execute computer-executable instructions or function calls to the payment processor 102 using data packets.

[0040] In another embodiment, the payment processor 124 may tokenize or encrypt the URL, amount, merchant information, etc. according to the specifications specified by the server 102. For example, assuming that the server 102 specifies a specific ISO specification for data packets and tokenization, the payment facilitator 124 may generate a data packet that complies with the specifications.

[0041] In another embodiment and with reference to Figure 2 , DCP 208 can process requests to server 102. For example, because DCP 208 can provide an ID to payment facilitator 124, DCP 208 can process requests to server 102, such as the data packets described above.

[0042] In another embodiment, the payment facilitator 124 may further include the merchant's merchant ID in the data packet along with the transaction amount and PAN. In one embodiment, the PAN may be retrieved in response to the consumer 108 logging into the wallet app 104. For example, in response to logging in, the wallet app 104 may return a list of cards, tokens, PANs for default cards, and cQRs or cBRs.

[0043] In another embodiment, the token may be time-sensitive. For example, the token may expire after a certain period of time, or a "session" may be defined by the period of time, such that the token is useless after expiration, thereby protecting the consumer 108 from unauthorized use.

[0044] The token is appended to the URL as a fragment of the URL once the portal 114 is loaded by the payment facilitator 124. In one embodiment, when the consumer 108 enters the amount into the portal 114 and clicks submit via the wallet app 104, the portal 114 can extract or retrieve the token from the URL and then send it to the payment facilitator 124 along with the merchant ID and the amount.

[0045] In one embodiment, the payment facilitator 124 can decrypt the token and the decrypted packet may include the PAN that it needs to send to the server or payment processor 102. As described above, tokenization can be done via Figure 2 occurs in the ARM202.

[0046] Return Reference Figure 1 , the payment facilitator 124 sends a data packet with the decrypted PAN to the server or payment processor 102 through the restricted computer network firewall 110. Unlike conventional methods, aspects of the present invention simplify the data packet to reduce the frequency of transmission between the merchant and the server 102. This data packet transmission according to aspects of the present invention reduces the time and frequency required for approval by the server 102. It is understood that when traveling abroad, it can be relatively time-consuming to conduct and complete transactions using a payment device issued in another country because people are accustomed to the fast turnaround time (e.g., within seconds) enjoyed in their home country. Thus, by simplifying the method, aspects of the present invention provide a technical solution to the technical problems encountered when traveling with restricted computer network firewalls 110.

[0047] In one embodiment, server 102 can process the simplified data packet and send it to issuer 126 for final processing. Once approved, server 102 can return a response to payment facilitator 124 with a transaction ID and confirmation of whether the transaction was successful. Payment facilitator 124 can call merchant 112 using its existing channel between payment facilitator 124 and merchant 112, as well as any additional APIs provided to payment facilitator 124. In one embodiment, payment facilitator 124 can send the transaction ID and approval to WPS 122.

[0048] In one embodiment, the DCP 208 may provide key management to manage the keys of the payment service provider 124. For example, the DCP 208 may provide a GUI that may provide configuration of the keys, such as naming conventions, key rotation, time limits, etc. (e.g., the time for overlapping keys). Thus, when processing a data packet from the payment service provider 124, the server 102 (or delegated to the WPS 122 or the DCP 208) may check the timestamp in the header portion of the data packet to determine whether the time specified in the header is less than a specific time, such as 60 minutes.

[0049] In another embodiment, referring to Figure 1 , the server 102 may be further coupled to a database that stores data for the server 102. In further embodiments, the database 128 may further include a data storage area for storing (via the WPS 122) data codes, developer code, computer executable instruction kits, API specifications, etc. for the payment facilitator 124. In yet another embodiment, the server 102 may include a configuration portal 132 for administrator access or other configuration or setup controls.

[0050] Reference Figure 4 , another flow chart illustrates a scenario associated with a user-presented code 118 via the wallet app 104. For example, as discussed above, a transaction may also be initiated via the wallet app 104 of the consumer 108 by presenting a code (e.g., cQR or cBR) to the merchant 112.

[0051] For example, Figure 2 As described and Figure 4 As shown, the consumer 108 may need to first log in to the wallet app 104 via the ARM 202. The wallet app 104 may receive the cQR or cBR as the code 118, and the code 118 may be tokenized. In one embodiment, the cQR or cBR may be configured with a time to live (TTL) so that the wallet app 104 should only display the code 118 when the TTL has not expired.

[0052] In another embodiment, the consumer 108 may be directed to a code page to present the code 118. If the TTL timer has expired, the wallet app 104 may retrieve a new code. If the TTL timer has not expired, the wallet app 104 may simply display the code 118 and any other information discussed above.

[0053] In another embodiment and as discussed above, the WPS 122 may generate an intent ID for the consumer 108 to use to conduct the transaction. For example, the CWS 120 may send or pass payment information to the WPS 122. The WPS 122 may then generate an intent ID and a barcode, and then send the intent ID and barcode to the WPS 122. The CWS 120 may further forward or send the barcode to the wallet app 104.

[0054] Once the code 118 is presented on the wallet app 104, the merchant 112 can scan the code 118 using its POS 116 at 402. In one embodiment, the wallet app 104 can send a reference number to the merchant 112 at 404. The merchant 112 can then send the reference number to the payment facilitator 124 at 406. The payment facilitator 124 can forward the reference number to the identity service 204 at 408. In one example, as discussed above, the ARM 202 can handle authentication and resource management for the server 102 and can handle login for the consumer 108. The ARM 102 can further communicate with the identity service 204, which has access to the consumer profile, which can include a list of cards that the user may own.

[0055] In one embodiment, WPS 122 may receive a request for a PAN from payment service provider 124. For example, payment service provider 124 may exchange a barcode for an encrypted payment instrument, such as an encrypted PAN. Thus, WPS 122 may transmit the encrypted PAN back to payment service provider 124 at 410.

[0056] In one embodiment and as discussed above, the payment facilitator 124 may decrypt the encrypted PAN at 412 and may send the data packet, as discussed above and through the restricted computer network firewall 110, to the server 102 outside the restricted computer network firewall 110. Also as discussed and according to one embodiment, the server 102 may forward the data packet to the issuer 126 at 414. Once the issuer 126 approves or authenticates the transaction, the issuer 126 may transmit the authentication back to the server 102 at 416. The server 102 may then send a response to the payment facilitator 124 at 418 so that the payment facilitator 124 can send a response to the merchant 112 that the consumer 108's payment is approved and the transaction is complete.

[0057] In another embodiment, when processing payments between the payment service provider 124 and the server 102, the WPS 122 may expose the following application programming interfaces (APIs), or receive calls to one of the following application programming interfaces (APIs) from the payment service provider 124 or the CWS 120:

[0058] (1) Set payment information. Accepts payment information and, when called by CWS 120, also accepts one or more client ids. Returns a barcode and intent id, and in the case of a client id, a token encrypted with a shared secret for each client. This API can be made available to CWS 120 via x-api-key. In another embodiment, Figure 2 The DCP 208 in the WPS 122 can store any configuration of API calls used by other wallet providers. On the other hand, the actual call process can be through a separate portal in a path similar to the path that the payment service provider 124 calls the WPS 122.

[0059] (2) Retrieve payment information. Return the payment instrument encrypted with the caller's shared secret. WPS 122 should identify the caller via the client ID that DCP 208 can pass in the header, look up the client's profile in DCP 208, obtain the shared encryption key from the Merchant Card Service (MCS), encrypt the payload, and send it.

[0060] (3) Update Payment Information. Called by the same entity that retrieved the payment entry to pass back the transaction result (success or failure) and other useful information that can be used for internal reporting or for things that can be sent back to the wallet.

[0061] (4) Get the new barcode. This is called by the wallet using the intent id.

[0062] Figure 5 This is a high-level diagram of a portable computing device 801 communicating with a remote computing device 841, but the application can be stored and accessed in a variety of ways. Additionally, the application can be obtained in a variety of ways, such as from an app store, from a website, from a store Wi-Fi system, etc. Various versions of the application can exist to take advantage of different computing devices, different languages, and different API platforms.

[0063] In one embodiment, the portable computing device 801 may be a mobile device 112 that operates using a portable power source 855, such as a battery. The portable computing device 801 may also have a display 802, which may or may not be a touch-sensitive display. More specifically, the display 802 may have a capacitive sensor, such as a capacitive sensor that can be used to provide input data to the portable computing device 801. In other embodiments, an input pad 804, such as an arrow, a scroll wheel, or a keyboard, may be used to provide input to the portable computing device 801. In addition, the portable computing device 801 may have a microphone 806 that can receive and store spoken data, a camera 808 for receiving images, and a speaker 810 for transmitting sound.

[0064] The portable computing device 801 can communicate with the computing device 841 or multiple computing devices 841 that make up the cloud of computing device 811. The portable computing device 801 can communicate in a variety of ways. In some embodiments, the communication can be wired, such as through an Ethernet cable, a USB cable, or an RJ6 cable. In other embodiments, the communication can be wireless, such as through a The communication may be to the computing device 841 or may be carried out through the communication network 102 such as a cellular service, the Internet, a private network, Bluetooth, etc. Figure 5 may be a simplified illustration of the physical elements that make up the portable computing device 801, and Figure 6 This may be a simplified illustration of the physical elements that make up the server-type computing device 841.

[0065] Figure 5A sample portable computing device 801 may be physically configured as part of a system. The portable computing device 801 may include a processor 850 physically configured according to computer-executable instructions. The portable computing device may include a portable power source 855, such as a rechargeable battery. The portable computing device may also include a sound and video module 860 to assist in displaying video and sound, and may be turned off when not in use to conserve power and battery life. The portable computing device 801 may also include volatile memory 865 and non-volatile memory 870. The portable computing device may include GPS capability 880, which may be a separate circuit or may be part of the processor 850. An input / output bus 875 may also be present to transmit data to and from various user input devices, such as a microphone 806, a camera 808, and other inputs such as an input pad 804, a display 802, and speakers 810. Communication with a network may also be controlled via wireless or wired means. Of course, this is just one embodiment of a portable computing device 801, and the number and type of portable computing devices 801 are limited only by imagination.

[0066] As a result of the system, better information can be provided to users at the point of sale. Information can be user-specific and can be required to exceed a relevance threshold. Consequently, users can make better-informed decisions. The system not only speeds up the process but also uses computing systems to achieve better results.

[0067] The physical components that make up the remote computing device 841 may further be Figure 6 . At a high level, computing device 841 may include digital storage, such as magnetic disks, optical disks, flash memory, non-volatile memory, and the like. Structured data may be stored in the digital storage, such as in a database. Server 841 may include a processor 1000 physically configured according to computer-executable instructions. The server may also include a sound and video module 1005 that assists in displaying video and sound, and may be shut down when not in use to conserve power and battery life. Server 841 may also include volatile memory 1010 and non-volatile memory 1015.

[0068] Database 1025 may be stored in memory 1010 or 1015, or may be separate. Database 1025 may also be part of a cloud of computing devices 841 and may be stored in a distributed manner across multiple computing devices 841. An input / output bus 1020 may also be present, which transmits data to and from various user input devices, such as microphone 806, camera 808, inputs such as input pad 804, display 802, and speaker 810. I / O bus 1020 may also control communication with the network via wireless or wired means. In some embodiments, the application may be located on the local computing device 801, while in other embodiments, the application may be remote 841. Of course, this is just one embodiment of a server 841, and the number and type of portable computing devices 841 are limited only by imagination.

[0069] The user devices, computers, and servers described herein may be: Corporation, or A general-purpose computer with a microprocessor (e.g., a processor); volatile and non-volatile memory; one or more mass storage devices (i.e., hard drives); various user input devices, such as a mouse, keyboard, or microphone; and a video display system. The user devices, computers, and servers described herein may run on any of a number of operating systems, including but not limited to or However, it is contemplated that any suitable operating system may be used with the present invention. The server may be a cluster of web servers, each of which may be LINUX-based and supported by a load balancer that decides which of the web server cluster should handle a request based on the current request load of the available servers.

[0070] The user devices, computers, and servers described herein can communicate via networks, including the Internet, wide area networks (WANs), local area networks (LANs), Other computer networks (now known or invented in the future), and / or any combination of the foregoing. It will be understood by those skilled in the art, after familiarity with this specification, the drawings, and the claims, that networks can connect various components via any combination of wired and wireless channels, including copper wire, fiber optics, microwaves, and other forms of radio frequency, electrical, and / or optical communication technologies. It will also be understood that any network can be connected to any other network in various ways. The interconnection between computers and servers in the system is an example. Any device described herein can communicate with any other device via one or more networks.

[0071] Example embodiments may include additional devices and networks beyond those shown. Furthermore, functions described as being performed by one device may be distributed and performed by two or more devices. Multiple devices may also be combined into a single device that can perform the functions of the combined devices.

[0072] The various participants and elements described herein may operate one or more computer devices to facilitate the functions described herein.Any element in the above figures, including any server, user device, or database, may use any suitable number of subsystems to facilitate the functions described herein.

[0073] Any software components or functions described in this application may be implemented as software code or computer-readable instructions that may be executed by at least one processor using any suitable computer language (eg, JAVA, C++, or PERL), using, for example, conventional or object-oriented techniques.

[0074] The software code may be stored as a series of instructions or commands on a non-transitory computer-readable medium such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium may reside on or within a single computing device and may be present on or within different computing devices within a system or network.

[0075] It will be appreciated that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on this disclosure and the teachings provided herein, those of ordinary skill in the art will know and understand other ways and / or methods of implementing the present invention using hardware, software, or a combination of hardware and software.

[0076] The above description is illustrative and not restrictive. After reading this disclosure, many variations of the embodiments will become apparent to those skilled in the art. Therefore, the scope of the embodiments should not be determined with reference to the above description, but should be determined with reference to the pending claims and their full scope or equivalents.

[0077] Without departing from the scope of the embodiments, one or more features from any embodiment may be combined with one or more features from any other embodiment. Unless expressly indicated to the contrary, the use of "a," "an," or "the" is intended to mean "one or more." Unless expressly indicated to the contrary, the use of "and / or" is intended to indicate the most inclusive meaning of the terms.

[0078] One or more elements of the system of the present invention may be claimed as a member for realizing a specific function. In the case of using such means plus functional elements to describe some elements of the system for protection, it can be understood by those of ordinary skill in the art who can consult this specification, the accompanying drawings and the claims that the corresponding structure is a general-purpose computer, a processor or a microprocessor, and the microprocessor (depending on the specific circumstances) is programmed to use the function present in any general-purpose computer without special programming to perform the function of special narration and / or to realize the function by realizing one or more algorithms. As will be understood by those of ordinary skill in the art, an algorithm can be expressed in the present disclosure as a mathematical formula, a flow chart, a narrative formula and / or provide enough structures to implement any other way of the process and its equivalent to those of ordinary skill in the art.

[0079] While the disclosure may be embodied in many different forms, the drawings and discussion are presented with the understanding that the disclosure is an exemplification of the principles of one or more inventions and is not intended to limit any one embodiment to the illustrated embodiment.

[0080] The present disclosure provides a solution to the long-standing needs described above. Specifically, the systems and methods described herein can be configured to convert QR-based payment flows into encrypted PAN payment flows. Aspects of the present invention are further critical, especially since encrypted PAN payment flows cannot be processed or completed within a restricted computer network firewall, and the permitted QR payment flows are closed payment flows within a restricted computer network firewall. Other advantages and modifications of the above-described systems and methods may be readily apparent to those skilled in the art. Therefore, the present disclosure in its broader aspects is not limited to the specific details, representative systems and methods, and illustrative examples shown and described above. Various modifications and variations may be made to the foregoing description without departing from the scope or spirit of the present disclosure, and it is intended that the present disclosure cover all such modifications and variations, provided that they are within the scope of the appended claims and their equivalents.

[0081] appendix

[0082] The following information provides additional details about the API:

[0083] A token is a JWE or JWS formatted using a compact serialization format. In this case, we might provide a JWE in token format to a payment provider. According to the standard, it may have five parts: a JOSE header, a JWE encryption key, an initialization vector, a ciphertext, and an authentication tag. Each part is encoded in base64 and separated by a period (dot).

[0084] In each JWE, a new random 256-bit key can be used to encrypt the message. This key is called the content encryption key (CEK). The CEK itself can be encrypted using a shared secret known to both the sender and the receiver.

[0085] The first part of the JWE, the JOSE header, can indicate the algorithm for the CEK to use the "enc" parameter to encrypt the message. The algorithm used to encrypt the CEK can be stored under the "alg" parameter. The name of the shared key used to encrypt the CEK can be stored under the "kid" parameter. Here are all the fields, from https: / / visawiki.trusted.visa.com / display / DVSS / Encryption+Utilities

[0086] "alg": "AGCM256KW" / / The encryption algorithm to be used to encrypt the CEK. This value is constant and can be hard-coded.

[0087] "iv": "<The size of the IV is 96 bits.>" / / The IV to be used for the encryption of the CEK, the value is Base64-UrlSafe encoded as pure JSON itself

[0088] "tag": "<128-bit value>" / / The authentication tag generated by applying AES-256-GCM-KW to the CEK, the value is Base64-UrlSafe encoded as pure JSON itself

[0089] "kid": "50-character API key" / / The API key

[0090] "enc": "AGCM256" / / The encryption algorithm to be used to encrypt the text to be encrypted. This value is constant and can be hard-coded.

[0091] "Channel Security Content": "shared_secret" / / A custom header field to specify the type of encryption scheme.

[0092] Device-level encryption - The encryption scheme can only originate from / for the device. Examples - RSA_PKI, Transparency_A, Transparency_B.

[0093] Server-level encryption - The encryption scheme originates from / for the MAP / partner server. Examples - shared_secret

[0094] "iat": "1429796739" / / The creation timestamp in seconds, indicating that the JWE can only be valid within an x time interval after creation.

[0095] The following is an example of a JOSE header that might be present in a JWE generated from an encrypted frame: {"alg":"A256GCMKW","iv":"xPa1wjwNBOR2lbHY","tag":"95Pc_zVoR7r7Ti4aW7N2Cg","enc":"A256GCM","typ":"JOSE","kid":"kid13245","Channel Security Context":"Shared_Secret","iat":"1431594282"}

[0096] The second part of the token can be a base64 encoded version of the encrypted version of the CEK

[0097] The third part of the token may be the IV used by the CEK.

[0098] The fourth part of the JTW may be an encrypted message.

[0099] The fifth part is the authentication tag, which is another output of the encryption of the message by the CEK.

[0100] At Visa, the Crypto Framework does all of this for us and we should use it. We recommend that our partners use a library to decrypt the token and point it to Web page on token.io.

[0101] The encrypted message itself can contain a Pan and an expiration. See the API section for the actual payload.

[0102] Setting the Intent

[0103] This API can be passed a payment instrument. If called by CWS 120, it can also accept one or more client IDs. The full details of the content can be passed: payment instrument (PAN or token), password (if token), password type (if token), timestamp, customer id that created the intent (if from DCP 208, otherwise empty), card id of the payment instrument or token in the wallet, account type (credit_card, debit_card), expiration month, expiration year, and card type (VISA). Passing only the password without the password type is invalid. Passing the password type without the password is invalid. If both the password type and password are present, the payment instrument is considered a token, otherwise it is considered a PAN.

[0104] Regarding encryption: While CWS 120 can send PAN / token information to WPS 122 via TLS because it is internal to Visa, TLS is not sufficient when the PAN information is sent via DCP 208. Message-level encryption should be used for this purpose. This means that the DCP 208 project should be enabled for MLE.

[0105] Once the API receives the above items, it can create an intent id and a timestamp. The API can create a JSON payload of the above items (except the timestamp), and then store the intent id, JSON payload, timestamp, and created state in the database. Here is an example of a JSON payload:

[0106] {"IntentId":"1234578",

[0107] “Payment Instrument”:

[0108] {

[0109] "Account Type":"Credit_Card","Account Number":"4444333322221234","Expiry Month":"02","Expiry Year":"2012","Card Type":"VISA",Card ID:"aaa-bbb-ccc-ddd"

[0110] }

[0111] }

[0112] If the token:

[0113] For JWE, the message can be as follows:

[0114] {"IntentId":"1234578",

[0115] “Payment Instrument”:

[0116] {

[0117] "Account Type":"Credit Card","Account Number":"4444333322221234","Expiry Month":"02","Expiry Year":"2012","Card Type":"VISA",Card ID:"aaa-bbb-ccc-ddd","Password":"342","Password Type":"DTVV"

[0118] }

[0119] }

[0120] Each intent on the server may have up to two barcodes pointing to it: the currently active barcode (corresponding to the barcode displayed on the device) and a barcode generated before that. Therefore, each barcode has a lifespan of two minutes. During the first minute of a barcode's lifespan, it may appear on the user's screen. During the second minute, it may not appear on the screen, but the payment provider still has the barcode valid for us to pass it to them and receive the payment. The TTL returned with the barcode is one minute from the creation time. Therefore, the TTL refers to the time the barcode should be displayed, not the time when the barcode is no longer valid.

[0121] The barcode can be generated by generating random numbers using Java secure random. The first digit can be "4". The next three digits can be provided by the product to the MVP (or random). The next 14 digits can be random. The last digit can be a checksum. Algorithm for generating the barcode: Generate a 19-digit barcode using the above strategy. Check if the barcode exists. If it exists, generate a different barcode. If it does not exist, go ahead and use the barcode. We can store the barcode for 24 hours (even if the barcode is only valid for the first two minutes of its existence) to reduce the possibility of conflicts with older barcodes.

[0122] Once the barcode has been generated, if a client ID was passed, the setup intent method should now go to the DCP to get the configuration file and to the MCS to get the shared secret associated with the passed client ID. The shared secret should be used to encrypt the JSON payload generated above. For each client ID, the payload should be encrypted using one shared secret, meaning there may be one encrypted payload for each client ID passed. Encryption should be performed using the CryptoFrame library, making encryption a single call:

[0123] String jwe = TokenUtility.CreateSharedSecretJwe("text","kid13245","encryptedsecret");

[0124] For text, we set the text to be encrypted. The kid corresponds to the API key, and the encryption secret is a shared secret.

[0125] Once the barcode, intent id, and token (if present) have been created, the set intent method passes these specific items back to the caller.

[0126] Retrieve payment data

[0127] The payment service provider can call to retrieve the payment data and pass the barcode or cQR.

[0128] Just because a barcode is associated with an intent, it can be invalid - every barcode has an expiration timestamp, and this should be checked when the barcode is used to retrieve a token.

[0129] The WPS 122 can review the request and, based on the passed client ID, retrieve the configuration file from the DCP and the encryption key and shared secret from the MCS, and then encrypt the payload using the encryption frame method to encrypt the token. The WPS 122 can change the intent state to retrieved, place the payment service provider's ID in the intent, and place the current timestamp in the retrieved timestamp field.

[0130] WPS 122 may then pass the token back to the caller.

[0131] Update payment data

[0132] The payment service provider can call update payment data and pass the details of the transaction. WPS 122 can change the status of the intent to successful_transaction or unsuccessful_transaction based on the content sent in the response. The full details of the passed content can be found later in the API definition.

[0133] In the case of a refund, the payment service provider can call again to update the payment data and pass the details of the transaction. WPS122 can change the status of the intent to partial_refund or full_refund based on the content sent in the response.

[0134] For both the initial update payment call and the refund call, WPS 122 can call CWS 120 with details including merchant name, amount, currency type, timestamp and intent Id. CWS 120 can use the intent Id to look up the device Id that created the intent so that it knows which device to notify.

[0135] Get a barcode

[0136] A wallet can call get_barcode, passing the intent id, and get another barcode. This may cause the current barcode to be moved to the "old" barcode slot, where the old barcode is no longer associated with the intent, and the new barcode to be created and placed in the current barcode slot. Even if a barcode is no longer associated with an intent, we will retain it for 24 hours so that no conflicts occur during this time.

[0137] If the barcode is valid but points to an intent that is marked as something other than created, the WPS 122 should create a new intent that is a copy of the intent the barcode points to (but with a different intent id) and then pass the payload back. When copying the old intent record to the new one, be sure to go into the payload itself and update the intent to the new intent id.

[0138] Tokenization

[0139] At the time of registration, CWS 120 can pass the PAN to the profile service of DCA for storage purposes. DCA can pass back the card id. CWS 120 can call VTS to get the e-commerce token of the card and then store the card id, token, user guid mapping.

[0140] At payment time—in other words, when CWS 120 is about to call WPS 122 to store payment information and return a barcode—CWS 120 can check to see if the default card associated with the user has an e-commerce token. If an e-commerce token is present, CWS 120 can call VTS to obtain the token's password and password type. CWS 120 can then pass the token, password, and password type to WPS 122 instead of the PAN.

[0141] For future flexibility, we reserve the right to pass any kind of password and passphrase type in the payload, and a mapping can be provided to payment providers so they know which token / password should be placed at which position in the ISO.

[0142] Refund

[0143] We might pass back a refund ID in the payment history that the CWS 120 sends to the phone. When the user wants a refund, he or she can show the transaction in the transaction history, and the app can display the refund ID as both a numeric string and a barcode.

[0144] The merchant can locate the transaction in the merchant's system and then process a full or partial refund.

[0145] The merchant's system can call the payment service provider, which can call the payment processor to process the refund. The payment service provider can then call both the merchant and WPS 122 to update the original transaction with the refund information.

[0146] APIs exposed by WPS 122

[0147] Note that each time a payment provider calls the API, the payment provider can pass the API key as a query parameter so that ARM knows which shared secret was used to generate the x-payment-token being used. This parameter is not specified in the API definition below, but must be present.

[0148] Post to / intent

[0149]

[0150]

[0151]

[0152]

[0153] Get / payment code / {barcode}

[0154]

[0155]

[0156]

[0157] Update payment information

[0158]

[0159]

[0160]

[0161]

[0162]

[0163]

[0164] barcode

[0165]

[0166]

[0167] Important APIs of CWS 120

[0168] Log in:

[0169] Standard flow, where the app calls openAuth2 / token, which calls the identity service with user / passed. If the system replies confirming user / password, ARM can generate a token that is passed back to the app.

[0170] Get payment history

[0171]

[0172]

[0173]

[0174] Update payment history

[0175]

[0176]

[0177] In another embodiment, the API for refunds may include the following:

[0178] Post to / Pay / Refund

[0179] Purpose: Called by the payment provider when a partial or full refund of a transaction is made, so that the wallet app is aware of it.

[0180] Input: Transaction ID

[0181] Return: Success.

[0182] API, inbound service calls on the digital commerce app (DCA).

[0183] ARM can call DCA directly for standard term / profile management.

[0184] ARM can call the wallet profile service to obtain the encrypted card information and barcode.

[0185] In-app notifications

[0186] When something is purchased, aspects of the present invention may require sending an in-app notification.Since apps use DCA for profile services, other processes may perform any registrations beyond those described above.

[0187] Handling Locks

[0188] Based on threat indicators or DFM, one embodiment of the present invention may lock the account.If the account is locked, aspects of the present invention may require informing the consumer 108 of the problem and that the consumer 108 should try again later.

[0189] Indicators of Compromise

[0190] We might use threat indicators like typical DCA applications to determine the risk of various actions:

[0191] Touch ID

[0192] An embodiment of the present invention can request a long-lived token from ARM at login time and store the token in a secure element. During a subsequent face / touch login, an embodiment of the present invention can pass the long-lived token to ARM and obtain a session token.

[0193] DCP

[0194] The DCP can create a profile for each payment facilitator. The profile can allow the facilitator to indicate which specific shared secret should be used at any given time, as well as a specific URL pattern that will indicate that it should be the payment facilitator in the case of MQR.

[0195] Data Model

[0196] Aspects of the present invention may have two modes: one for CWS 120 and one for WPS 122. For CWS 120, embodiments of the present invention may need to track the following:

[0197] Whether or not the user has signed the inbound app T&Cs. Embodiments of the present invention may store this information in the user graph.

[0198] The user's device id that can be used for in-app notifications (if on iOS). This may be updated on each login.

[0199] Payment history.

[0200] User Chart

[0201] UserGuid String Matching with DCA and Identity Services TC Signature GUID TC timestamp Timestamp

[0202] Intent Graph

[0203] Intent Id Guid Wallet Device Id String, 200 UserGuid Guid Foreign keys from user graphs

[0204] Payment History

[0205]

[0206] For WPS 122, aspects of the present invention may require tracking of the following:

[0207] Intent, including intent id, created timestamp, status, retrieved timestamp, completed timestamp, most recent refund timestamp, intent creator id, intent retriever id, id of the entity that completed the intent, id of the most recent refund for the intent, merchant name, user id in the wallet for which the intent was created Barcode chart

[0208] A chart that indicates which barcode is the current barcode for a given intent and which barcode was the previous barcode for a given intent.

[0209]

[0210] Detailed chart. May be easily purged. Data retention policy required.

[0211] statement enumerate Ts Timestamp Client ID String / Guid Intent id String / Guid

[0212] barcode 19 numbers Created Timestamp

[0213] Intent Barcode

[0214] barcode Intent Id state Current, previous enumeration

Claims

1. A computer-implemented system for simplifying encrypted payloads of card transactions from merchants inside a restricted computer network firewall, comprising: Payment processing servers, which are used to process payment transactions; a wallet application that stores the user's payment device data for payment transactions; a payment facilitator coupled between the payment processing server and the wallet application; wherein the wallet application retrieves the merchant and transaction information by scanning a transaction code used to initiate the payment transaction with the merchant; In response to the retrieved information, the wallet application generates an encrypted payload including at least the following data: data of the payment device, information of the merchant, and information of the payment transaction; wherein the wallet application sends the encrypted payload to the payment facilitator within the restricted computer network firewall; wherein the payment facilitator decrypts the encrypted payload to form a decrypted payload; After decrypting the encrypted payload, the payment facilitator sends the decrypted payload in a payment data packet to the payment processing server outside the restricted computer network firewall; and After the payment processing server verifies the payment transaction, the payment processing server sends a payment notification from outside the restricted computer network firewall to the merchant inside the restricted computer network firewall.

2. The computer-implemented system of claim 1, wherein the transaction code comprises a Quick Response (QR) code.

3. The computer-implemented system of claim 1 , wherein the wallet application sends the encrypted payload via a URL formatted address.

4. The computer-implemented system of claim 1 , wherein the wallet application is configured to be installed on a mobile device of the user.

5. The computer-implemented system of claim 3, wherein the restricted computer network firewall restricts outbound transactions except for permitted URL sites, and wherein the URL formatted address is one of the permitted URL sites.

6. A computer-implemented system for simplifying encrypted payloads of card transactions from merchants inside a restricted computer network firewall, comprising: Payment processing servers, which are used to process payment transactions; a wallet application that stores the user's payment device data for payment transactions; a payment facilitator coupled between the payment processing server and the wallet application; wherein the wallet application receives information of the merchant and the transaction after presenting a transaction code to be scanned by the merchant for initiating the payment transaction with the merchant; In response to the received information, the wallet application generates an encrypted payload including at least the following data: data of the payment device, information of the merchant, and information of the payment transaction; wherein the wallet application sends the encrypted payload to the payment facilitator within the restricted computer network firewall; wherein the payment facilitator decrypts the encrypted payload to form a decrypted payload; After decrypting the encrypted payload, the payment facilitator sends the decrypted payload in a payment data packet to the payment processing server outside the restricted computer network firewall; and After the payment processing server verifies the payment transaction, the payment processing server sends a payment notification from outside the restricted computer network firewall to the merchant inside the restricted computer network firewall.

7. The computer-implemented system of claim 6, wherein the transaction code comprises a Quick Response (QR) code.

8. The computer-implemented system of claim 6, wherein the wallet application sends the encrypted payload via a URL formatted address.

9. The computer-implemented system of claim 6, wherein the wallet application is configured to be installed on a mobile device of the user.

10. The computer-implemented system of claim 8, wherein the restricted computer network firewall restricts outbound transactions except for permitted URL sites, and wherein the URL formatted address is one of the permitted URL sites.

11. A computer-implemented method for limiting the transmission of a plurality of encrypted transaction data packets between a merchant and a server, comprising: storing data of a user's payment device by the wallet application for use in performing payment transactions; The wallet application obtains information about the merchant and the transaction by obtaining a transaction code for initiating the payment transaction to the merchant; In response to the obtained information, generating, by the wallet application, an encrypted payload including at least the following data: data of the payment device, information of the merchant, and information of the payment transaction; sending the encrypted payload to a payment service provider within a restricted computer network firewall; Decrypting the encrypted payload by the payment service provider; After decrypting the encrypted payload, sending the decrypted payload in a payment data packet to a payment processing server outside the restricted computer network firewall; and After the payment processing server verifies the payment transaction, a payment notification is sent from outside the restricted computer network firewall to the merchant inside the restricted computer network firewall.

12. The computer-implemented method of claim 11, wherein the wallet application obtains the merchant and the transaction information by scanning the transaction code for initiating the payment transaction to the merchant via a camera.

13. The computer-implemented method of claim 11, wherein the wallet application obtains the merchant and the transaction information after presenting on a display the transaction code to be scanned by the merchant for initiating the payment transaction with the merchant.

14. The computer-implemented method of claim 11, wherein the transaction code comprises a Quick Response (QR) code.

15. The computer-implemented method of claim 11, wherein the wallet application sends the encrypted payload via a URL formatted address.

16. The computer-implemented method of claim 11, wherein the wallet application is configured to be installed on a mobile device of the user.

17. The computer-implemented method of claim 15, wherein the restricted computer network firewall restricts outbound transactions except for permitted URL sites, and wherein the URL formatted address is one of the permitted URL sites.

Images