Systems and methods for revocable peer-to-peer payments

Abstract

A method, system, and computer program product for revocable peer-to-peer payments are provided. The method includes generating an asymmetric key pair including a first key and a second key, encrypting at least a portion of the peer-to-peer payment data with the first key to generate encrypted payment data, storing the encrypted payment data, communicating the second key to a first device associated with the first user, receiving the second key from a second device associated with the second user, decrypting the encrypted payment data based on the second key received from the second device, and processing a payment from the first account to the second account based on decrypting the encrypted payment data.

Description

Technical Field

[0001] This disclosure generally relates to payments between users, and in non-limiting embodiments, to systems, methods, and computer program products for revocable peer-to-peer payments. Background Technology

[0002] Users who want to send payments to other users can do so via direct payment, such as through their respective banks. However, once a payment is made in this way, the sender cannot reverse it. Thus, even if the recipient does not accept the payment immediately, the payment is transferred to the recipient's account, and the sender cannot recover it. Summary of the Invention

[0003] According to a non-limiting embodiment or aspect, a computer-implemented method is provided, comprising: receiving peer-to-peer payment data, including a payment amount, from a first account associated with a first user to a second account associated with a second user, using at least one processor; generating an asymmetric key pair including a first key and a second key using at least one processor; encrypting at least a portion of the peer-to-peer payment data with the first key using at least one processor to generate encrypted payment data; storing the encrypted payment data using at least one processor; transmitting the second key to a first device associated with the first user using at least one processor; receiving the second key from a second device associated with the second user using at least one processor; decrypting the encrypted payment data based on the second key received from the second device using at least one processor; and processing the payment from the first account to the second account based on the decryption of the encrypted payment data.

[0004] In a non-limiting embodiment or aspect, the computer-implemented method further includes: automatically sending a second key from a first device to a second device in response to input from a first user. In a non-limiting embodiment or aspect, the computer-implemented method further includes: automatically sending the second key from the first device to the second device in response to determining that at least one rule has been met. In a non-limiting embodiment or aspect, the computer-implemented method further includes generating a payment token based on peer-to-peer payment data using at least one processor. In a non-limiting embodiment, the payment token includes encrypted payment data. In a non-limiting embodiment, the encrypted payment data includes an encrypted value of the payment amount. In a non-limiting embodiment, the payment token includes a unique identifier, an identifier associated with a second user, and encrypted payment data, wherein the encrypted payment data includes an encrypted value of the payment amount. In a non-limiting embodiment or aspect, the computer-implemented method further includes: transmitting at least a portion of the peer-to-peer payment data to a first issuing system associated with a first account using at least one processor. In a non-limiting embodiment or aspect, at least one processor of a payment system located remotely from the first device, the second device, and the first issuing system generates an asymmetric key pair, encrypts at least a portion of the peer-to-peer payment data, and transmits the second key to the first device.

[0005] According to a non-limiting embodiment or aspect, a system for revocable peer-to-peer payments is provided, comprising at least one processor programmed or configured to: receive peer-to-peer payment data, including a payment amount, from a first account associated with a first user to a second account associated with a second user; generate an asymmetric key pair including a first key and a second key; encrypt at least a portion of the peer-to-peer payment data with the first key to generate encrypted payment data; store the encrypted payment data; transmit the second key to a first device associated with the first user; receive the second key from the second device associated with the second user; decrypt the encrypted payment data based on the second key received from the second device; and process the payment from the first account to the second account based on the decryption of the encrypted payment data.

[0006] In a non-limiting embodiment or aspect, at least one processor is further programmed or configured to automatically send a second key from the first device to the second device in response to input from a first user. In a non-limiting embodiment or aspect, at least one processor is further programmed or configured to automatically send a second key from the first device to the second device in response to determining that at least one rule has been met. In a non-limiting embodiment or aspect, at least one processor is further programmed or configured to generate a payment token based on peer-to-peer payment data. In a non-limiting embodiment or aspect, the payment token includes encrypted payment data. In a non-limiting embodiment or aspect, the encrypted payment data includes an encrypted value of the payment amount. In a non-limiting embodiment or aspect, the payment token includes a unique identifier, an identifier associated with a second user, and encrypted payment data, wherein the encrypted payment data includes an encrypted value of the payment amount. In a non-limiting embodiment or aspect, at least one processor is further programmed or configured to transmit at least a portion of the peer-to-peer payment data to a first issuing system associated with a first account. In a non-limiting embodiment or aspect, at least one processor is further programmed or configured to automatically send a second key from the first device to the second device in response to input from a first user.

[0007] According to a non-limiting embodiment or aspect, a computer program product for revocable peer-to-peer payments is provided, comprising at least one non-transient computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: receive peer-to-peer payment data, including a payment amount, from a first account associated with a first user to a second account associated with a second user; generate an asymmetric key pair including a first key and a second key; encrypt at least a portion of the peer-to-peer payment data with the first key to generate encrypted payment data; store the encrypted payment data; transmit the second key to a first device associated with the first user; receive the second key from a second device associated with the second user; decrypt the encrypted payment data based on the second key received from the second device; and process the payment from the first account to the second account based on the decryption of the encrypted payment data. In a non-limiting embodiment or aspect, the program instructions, when executed by at least one processor, further cause the at least one processor to generate a payment token based on the peer-to-peer payment data.

[0008] Other non-limiting embodiments or aspects will be set forth in the following numbered clauses:

[0009] Clause 1: A computer-implemented method comprising: receiving peer-to-peer payment data, including a payment amount, from a first account associated with a first user to a second account associated with a second user, using at least one processor; generating an asymmetric key pair including a first key and a second key using at least one processor; encrypting at least a portion of the peer-to-peer payment data with the first key using at least one processor to generate encrypted payment data; storing the encrypted payment data using at least one processor; transmitting the second key to a first device associated with the first user using at least one processor; receiving the second key from a second device associated with the second user using at least one processor; decrypting the encrypted payment data based on the second key received from the second device using at least one processor; and processing the payment from the first account to the second account based on the decryption of the encrypted payment data.

[0010] Clause 2: The computer-implemented method according to Clause 1 further includes: automatically sending a second key from the first device to the second device in response to input from a first user.

[0011] Clause 3: The computer-implemented method according to Clause 1 or 2 further includes: automatically sending a second key from the first device to the second device in response to determining that at least one rule has been satisfied.

[0012] Clause 4: The computer-implemented method according to any one of Clauses 1 to 3 further includes generating a payment token based on peer-to-peer payment data using at least one processor.

[0013] Clause 5: A computer-implemented method according to any one of Clauses 1 to 4, wherein the payment token comprises encrypted payment data.

[0014] Clause 6: A computer-implemented method according to any one of Clauses 1 to 5, wherein the encrypted payment data includes an encrypted value of the payment amount.

[0015] Clause 7: A computer-implemented method according to any one of Clauses 1 to 6, wherein the payment token includes a unique identifier, an identifier associated with a second user, and encrypted payment data, wherein the encrypted payment data includes an encrypted value of the payment amount.

[0016] Clause 8: The computer-implemented method according to any one of Clauses 1 to 7 further includes: using at least one processor to transmit at least a portion of the peer-to-peer payment data to a first issuer system associated with the first account.

[0017] Clause 9: A computer-implemented method according to any one of Clauses 1 to 8, wherein at least one processor of a payment system located remotely from the first device, the second device, and the first issuer system generates an asymmetric key pair, encrypts at least a portion of the peer-to-peer payment data, and transmits a second key to the first device.

[0018] Clause 10: A system for revocable peer-to-peer payments, comprising at least one processor programmed or configured to: receive peer-to-peer payment data, including a payment amount, from a first account associated with a first user to a second account associated with a second user; generate an asymmetric key pair including a first key and a second key; encrypt at least a portion of the peer-to-peer payment data with the first key to generate encrypted payment data; store the encrypted payment data; transmit the second key to a first device associated with the first user; receive the second key from the second device associated with the second user; decrypt the encrypted payment data based on the second key received from the second device; and process the payment from the first account to the second account based on the decryption of the encrypted payment data.

[0019] Clause 11: The system according to Clause 10, wherein at least one processor is further programmed or configured to automatically send a second key from the first device to the second device in response to input from the first user.

[0020] Clause 12: A system according to Clause 10 or 11, wherein at least one processor is further programmed or configured to automatically send a second key from the first device to the second device in response to determining that at least one rule has been satisfied.

[0021] Clause 13: A system pursuant to any one of Clauses 10 to 12, wherein at least one processor is further programmed or configured to generate payment tokens based on peer-to-peer payment data.

[0022] Clause 14: A system pursuant to any one of Clauses 10 to 13, wherein the payment token comprises encrypted payment data.

[0023] Clause 15: A system pursuant to any one of Clauses 10 to 14, wherein the encrypted payment data includes an encrypted value of the payment amount.

[0024] Clause 16: A system pursuant to any one of Clauses 10 to 15, wherein the payment token comprises a unique identifier, an identifier associated with a second user, and encrypted payment data, wherein the encrypted payment data comprises an encrypted value of the payment amount.

[0025] Clause 17: A system pursuant to any one of Clauses 10 to 16, wherein at least one processor is further programmed or configured to transmit at least a portion of the peer-to-peer payment data to a first issuer system associated with the first account.

[0026] Clause 18: A system according to any one of Clauses 10 to 17, wherein at least one processor is further programmed or configured to automatically send a second key from the first device to the second device in response to input from the first user.

[0027] Clause 19: A computer program product for revocable peer-to-peer payments, comprising at least one non-transient computer-readable medium, the at least one non-transient computer-readable medium comprising program instructions, which, when executed by at least one processor, cause the at least one processor to: receive peer-to-peer payment data, including payment amounts, for a payment from a first account associated with a first user to a second account associated with a second user; generate an asymmetric key pair including a first key and a second key; encrypt at least a portion of the peer-to-peer payment data with the first key to generate encrypted payment data; store the encrypted payment data; transmit the second key to a first device associated with the first user; receive the second key from a second device associated with the second user; decrypt the encrypted payment data based on the second key received from the second device; and process the payment from the first account to the second account based on the decryption of the encrypted payment data.

[0028] Clause 20: A computer program product pursuant to Clause 19, wherein the program instructions, when executed by at least one processor, further cause the at least one processor to generate a payment token based on peer-to-peer payment data.

[0029] The operational methods and manufacturing economics of these and other features and characteristics of this disclosure, as well as the combinations of related structural elements and parts, will become more apparent after considering the following description and appended claims with reference to the accompanying drawings, all of which form part of this specification, wherein similar reference numerals denote corresponding parts in the figures. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to be limiting of the invention. Attached Figure Description

[0030] Additional advantages and details are explained in more detail below with reference to the non-limiting, exemplary embodiments shown in the illustrative accompanying drawings, in which:

[0031] Figure 1 This is a schematic diagram of a system for revocable peer-to-peer payments according to a non-limiting embodiment;

[0032] Figure 2This is a sequence diagram of a system for revocable peer-to-peer payments according to a non-limiting embodiment;

[0033] Figure 3 This is a flowchart of a method for revocable peer-to-peer payment according to a non-limiting embodiment; and

[0034] Figure 4 Example components of a device used in conjunction with a non-limiting embodiment are shown. Detailed Implementation

[0035] For the purposes of the following description, the terms “end,” “upper,” “lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,” “lateral,” “longitudinal,” and their derivatives should be associated with the orientation of the embodiments in the accompanying drawings. However, it should be understood that embodiments may employ various alternative variations and sequences of steps, except where explicitly specified as the opposite. It should also be understood that the specific apparatus and processes shown in the accompanying drawings and described in the following specification are merely exemplary embodiments or aspects of the invention. Therefore, specific dimensions and other physical characteristics relating to the embodiments or aspects disclosed herein should not be considered limiting.

[0036] The terms "aspects," "components," "elements," "elements," "structures," "actions," "steps," "functions," and "instructions" used herein should not be construed as critical or essential unless explicitly stated otherwise. Furthermore, as used herein, the article "a" is intended to include one or more items and is interchangeable with "one or more" and "at least one." Additionally, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and is interchangeable with "one or more" or "at least one." Where only one item is desired, the term "a" or similar language is used. Furthermore, as used herein, the terms "having" and similar expressions are intended to be open-ended terms. Additionally, unless explicitly stated otherwise, the phrase "based on" is intended to mean "at least partially based on."

[0037] As used herein, the term "communication" can refer to the receiving, accepting, sending, transmitting, and providing of data (e.g., information, signals, messages, instructions, commands, etc.). For one unit (e.g., a device, system, component of a device or system, combination thereof, and / or the like) to communicate with another unit means that the first unit is able to receive information directly or indirectly from and / or send information to the other unit. This can refer to a direct or indirect connection that is inherently wired and / or wireless (e.g., a direct communication connection, an indirect communication connection, and / or the like thereof). Furthermore, although the transmitted information may be modified, processed, relayed, and / or routed between the first and second units, the two units can also communicate with each other. For example, the first unit can communicate with the second unit even if it passively receives information and does not actively send information to the second unit. As another example, the first unit can communicate with the second unit if at least one intermediate unit processes information received from the first unit and transmits the processed information to the second unit.

[0038] As used herein, the term "computing device" can refer to one or more electronic devices configured to process data. In some instances, a computing device may include the necessary components for receiving, processing, and outputting data, such as a processor, display, memory, input device, network interface, etc. A computing device can be a mobile device. As examples, a mobile device may include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., a watch, glasses, lenses, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. A computing device can also be a desktop computer or other forms of non-mobile computer.

[0039] As used herein, the term "server" may refer to or include one or more computing devices operated by or facilitating communication and processing by multiple parties in a network environment such as the Internet, but it should be understood that communication may be facilitated through one or more public or private network environments, and various other arrangements may be possible. Furthermore, multiple computing devices (e.g., servers, point-of-sale (POS) devices, mobile devices, etc.) communicating directly or indirectly in a network environment may constitute a "system." As used herein, references to "server" or "processor" may refer to a previously stated server and / or processor, different servers and / or processors, and / or combinations of servers and / or processors that implement a prior step or function. For example, as used in the specification and claims, a first server and / or first processor that implements a first step or function may refer to the same or different servers and / or processors that implement a second step or function.

[0040] As used herein, the term “graphical user interface” (GUI) refers to a generated display, such as one or more displays that a user can interact with directly or indirectly (e.g., via a keyboard, mouse, touchscreen, etc.).

[0041] As used herein, the term "transaction service provider" can refer to an entity that receives transaction authorization requests from merchants or other entities and, in some cases, provides payment guarantees through an agreement between the transaction service provider and the issuing authority. For example, a transaction service provider may include a payment network such as Visa®, or any other entity that processes transactions. The term "transaction processing system" can refer to one or more computing devices operated by or on behalf of a transaction service provider, such as a transaction processing server executing one or more software applications. A transaction processing system may include one or more processors and, in some non-limiting embodiments, may be operated by or on behalf of a transaction service provider.

[0042] As used herein, the term "issuing institution" may refer to one or more entities, such as a bank, that provide customers with accounts for transactions (e.g., payment transactions), such as initiating credit and / or debit payments. For example, an issuing institution may provide a customer with an account identifier, such as a primary account number (PAN), that uniquely identifies one or more accounts associated with said customer. The account identifier may be implemented on a payment device such as a physical financial instrument like a payment card, and / or may be electronic and used for electronic payments. The term "issuing system" refers to one or more computing devices operated by or on behalf of an issuing institution, such as a server computer executing one or more software applications. For example, an issuing system may include one or more authorization servers for authorizing transactions.

[0043] Non-limiting embodiments relate to a revocable and verifiable peer-to-peer payment system and method that enables users to make payments to other individuals securely and efficiently. In a non-limiting embodiment, cryptographic techniques are used to protect a portion of a payment token, allowing the payment token to be held by the issuing system until a decryption key is provided, thereby achieving a delay between the initiation of a payment request and the processing of the payment. The disclosed infrastructure and the data flow between the payment system, a first user device (e.g., the payer), a second user device (e.g., the payee), and the issuing system (for the accounts of both the payer and the payee) enable improvements to the peer-to-peer payment system, thereby avoiding the additional computational resources associated with disputes, refunds, or reversal attempts.

[0044] Figure 1A system 1000 for revocable peer-to-peer payments is depicted according to a non-limiting embodiment. System 1000 includes a payment system 108 communicating with a first issuing system 112 and a second issuing system 114. Payment system 108 also communicates with multiple user devices via one or more network environments such as the Internet. In the depicted example, payment system 108 communicates with a first user device 104 operated by a first user 100 and a second user device 106 operated by a second user 102. Payment system 108 may include one or more computing devices, such as a server computer. Payment system 108 may also include one or more components of an electronic payment network, such as a payment gateway and / or transaction processing system associated with a transaction service provider. In some instances, payment system 108 may be used to perform various different types of payments. In some instances, payment system 108 may be dedicated to peer-to-peer payments between users. It should be understood that other variations are possible.

[0045] Continue to refer to Figure 1 In the depicted example, a first user 100 (e.g., a payer) attempts to make a payment to a second user 102 (e.g., a payee). To this end, the first user 100 operates a first user device 104, and the first user device 104 generates a payment request message for communication with the payment system 108. The payment request message may identify the first user 100, the account associated with the first user 100 (e.g., account identifier, token, etc.), the second user 102, the account associated with the second user 102 (e.g., account identifier, token, etc.), the payment amount, and / or other information. For example, the payment request message may include the second user's user identifier (e.g., a recipient control code). The first user device 104 and / or the second user device 106 may include one or more software applications configured to facilitate interaction with users 100 and 102 to send and receive payments. The software applications may display one or more GUIs on devices 104 and 106 to facilitate user interaction. The applications may be dedicated payment applications, banking applications, web browsers, operating system components, etc.

[0046] Still referencing Figure 1In a non-limiting embodiment, the payment request message is processed by payment system 108. For example, payment system 108 may communicate with a first issuing system 112 corresponding to the account of the first user 100 identified in the payment request message to determine that sufficient funds are available. Payment system 108 may generate a key that can be used to complete the requested payment. For example, payment system 108 may generate a key value and use the key value to encrypt the payment request message and / or payment data derived therefrom. For example, payment system 108 may generate a payment token and encrypt the payment token. Payment system 108 may transmit the key to the first user device 104. When the first user 100 selects, the first user 100 may transmit key 116 to the second user 102. This communication may be out-of-band (e.g., outside the payment processing network). For example, the first user 100 can physically transfer the key 116 to the second user 102, the first user 100 can send the key 116 to the second user device 106 via email or SMS, the first user 100 can operate an application on the first user device 104 to transmit the key 116 through the corresponding application on the second user device 106, and so on.

[0047] In a non-limiting embodiment, payment system 108 generates a payment token (e.g., a one-time use token) valid for a single use based on the user identifier of the second user 102, a unique identifier (e.g., a one-time code unique to the payment request), and an encrypted payment amount value (and / or some other portion of the payment data). The encrypted value can be generated using a key from a key pair (e.g., the public or private key in a public / private key pair). For example, the payment amount value can be encrypted using the public key in the public / private key pair. In a non-limiting embodiment, the key used to encrypt the payment amount value corresponds to key 116 passed from the first user 100 to the second user 102 to unlock the payment. For example, the payment amount value can be encrypted using the public key corresponding to the private key 116 used to unlock the payment. In a non-limiting embodiment, the payment token may include a data structure comprising the user identifier, a unique identifier, and the encrypted payment amount value.

[0048] In a non-limiting embodiment, payment system 108 may generate an asymmetric key pair for each payment request. In other non-limiting embodiments, the key pair may be established before transmitting the payment request message and may be assigned to the first user 100 and / or the first user device 104. It should be understood that the payment token or a portion thereof (e.g., the payment amount value) may be encrypted using either key in the asymmetric key pair. In other non-limiting embodiments, a symmetric key may also be used.

[0049] Still referencing Figure 1The second user 102 can request payment completion by sending a payment completion message, including key 116, to payment system 108. For example, the second user 102 can input key 116 into a webpage, software application, etc., to send key 116 to payment system 108. In this way, the first user 100 can change their mind about making the payment until key 116 is sent to the second user 102. Therefore, even if the payment has been initiated and approved by the first issuing system 112, the first user 100 can cancel the payment by not providing key 116 to the second user 102. In some instances, key 116 may expire after a predetermined period, such that if the first user 100 does not provide key 116 to the second user 102 within the predetermined period and / or the second user 102 does not provide key 116 to payment system 108, the payment is cancelled and cannot be completed by the second user 102.

[0050] Furthermore, even after key 116 has been transmitted to second user 102, first user 100 can still cancel the payment before second user 102 completes the payment. For example, first user 100 can transmit key 116 to the second user and later decide to cancel the payment. If second user 102 has not yet completed the payment by transmitting key 116 to payment system 108 to request payment completion, first user 100 can operate first user device 104 to transmit a cancellation payment message to payment system 108. The cancellation payment message may identify the original payment request message and may include key 116 or some other key previously transmitted by payment system 108 to first user device 104. In response to receiving the cancellation payment message, payment system 108 can cancel the payment, preventing second user 102 from receiving payment, even if second user 102 possesses key 116.

[0051] Still referencing Figure 1The first issuing system 112 can transmit payment data to the second issuing system 114 at any point. For example, after payment system 108 initially communicates with the first issuing system 112 (e.g., to authorize payment, etc.), the first issuing system 112 can transmit a payment request message or at least a portion of the data contained therein to the second issuing system 114. For example, the first issuing system 112 can transmit the user identifier of the second user 102 to the second issuing system 114. In response to receiving the user identifier and / or other payment data from the first issuing system 112, the second issuing system 114 can generate or request the generation of a challenge to be transmitted directly, via payment system 108, or via some other channel to the second user device 106. For example, the challenge may include data encrypted with a public key corresponding to the private key 116 passed from the first user 100 to the second user 102. In a non-limiting embodiment, the second issuing system 114 may transmit a challenge request message to the payment system 108, which, in response to receiving the challenge request message, generates a challenge and transmits the challenge to the second user device 106. In other non-limiting embodiments, the payment system 108 may transmit a challenge to the second user device 106 without being requested by the second issuing system 114.

[0052] refer to Figure 2 The diagram illustrates a sequence according to a non-limiting embodiment. It should be understood that... Figure 2 The sequences shown are for example purposes only, and variations are possible, including additional steps, steps in different orders, alternative steps, etc. Figure 2 In step 1, the first user device 104 transmits a payment request message to the payment system 108. This message may be the first communication during payment initiation, or in other instances, it may be in response to a payment request initiated by the payment system 108 and / or the second user device 106. The payment request message may specify the payment amount, a user identifier associated with the second user to whom the payment will be made, the account of the first user to whom the payment will be made, and / or other information.

[0053] exist Figure 2In step 2, payment system 108 generates a payment token and transmits it to a first issuing system 112 associated with the account of the first user from whom the payment will be made. The payment token may include, for example, information about a second user (e.g., the payee), such as a unique identifier associated with the second user, a unique identifier associated with the payment (e.g., a one-time code), and an encrypted payment amount value. The payment amount value can be encrypted using one of the keys in an asymmetric key pair stored and / or accessed by payment system 108. It should be understood that in some non-limiting embodiments, in addition to encrypting the payment amount value, or as an alternative, the entire token and / or other parts of the token may be encrypted. In some non-limiting instances, the key pair may be used for a single payment transaction and may be generated by payment system 108 for each payment request message.

[0054] exist Figure 2 In step 3, the payment system 108 transmits the unlock key to the first user device 104. The unlock key can be the key in a key pair that corresponds to the key used to encrypt the payment amount value. Figure 2 In step 4, the first issuing system 112 identifies the second issuing system 114 associated with the second user's account and transmits a payment token or a portion thereof. For example, the first issuing system 112 may transmit a unique identifier associated with the second user and a unique identifier associated with the payment transaction. Figure 2 In step 5, the first user device 104 transmits the unlock key to the second user device 106. It should be understood that the unlock key may also be transmitted to the second user in any other way and entered by the second user into the second user device 106 and / or the payment system 108.

[0055] exist Figure 2 In step 6, the second issuing system 114 requests the payment system 108 to transmit a challenge to the second user device 106. For example, the second issuing system 114 may transmit a unique identifier associated with the second user to the payment system 108 to initiate a challenge. In other instances, the payment system 108 and / or the second user may initiate a challenge. Figure 2 In step 7, the payment system 108 transmits the query to the second user device 106. For example, the query can prompt the second user to enter an unlock key via the second user device 106. Figure 2 In step 8, the second user device 106 transmits the unlock key to the payment system 108. It should be understood that in some non-limiting embodiments, the unlock key can be transmitted from the second user device 106 to the first issuing system 112. Figure 2In step 9, payment system 108 transmits the unlocking key to first issuing system 112. As mentioned above, in some non-limiting embodiments, the unlocking key can be transmitted from second user device 106 to first issuing system 112. Figure 2 In step 10, the first issuing system 112 uses an unlock key to decrypt the payment token or a portion thereof (e.g., the payment amount value) and process the payment to send the payment amount from the first user's account to the second issuing system 114. Payments can be made between issuing systems in various ways.

[0056] refer to Figure 3 The diagram illustrates a flowchart according to a non-limiting embodiment. It should be understood that, in the non-limiting embodiment, [the following can be used]... Figure 3 The example shown has additional, fewer, different, and / or different order of steps compared to others. In step 300, a payment request message is received from a first user device. In step 302, the payment system determines whether to approve the payment request message. For example, it may determine whether the first user (payer) has sufficient funds to make a payment to the second user (payee). If the request is not approved, the method may end at step 301. If the request is approved, the method may proceed to step 304, and a key pair may be generated for the transaction. A unique identifier for the transaction may also be generated in step 304. In step 306, a payment token is generated based on the key in the key pair generated in step 304 and the payment data associated with the payment request received in step 300. For example, the token or a portion thereof may be encrypted using the key in the key pair.

[0057] Continue to refer to Figure 3 In step 308, the payment token or a portion thereof (e.g., a unique identifier associated with the payee) is transmitted to a first issuing system associated with the payer's account. In step 310, an unlocking key from the key pair, which can be used to decrypt the token or a portion thereof, is transmitted to the payer's device. The payer can then transmit the unlocking key out-of-band to the payee via any communication channel or mechanism. In step 312, after the payee receives the unlocking key from the payer, it receives the unlocking key from a second user device associated with the payee. The unlocking key can be received in response to a query as described herein. In step 314, the payment token or a portion thereof is decrypted using the unlocking key. The payment system or issuing system associated with the payer's account can perform the decryption. In step 316, it is determined whether the decryption was successful (e.g., whether the unlocking key is valid). If the unlocking key is valid and the token is decrypted, the payment is processed in step 318.

[0058] For reference Figure 4 The diagram illustrates example components of a device 900 according to a non-limiting embodiment. As an example, device 900 may correspond to... Figure 1 The system includes user device 104, second user device 106, payment system 108, first issuer system 112, and / or second issuer system 114. In some non-limiting embodiments, such a system or apparatus may include at least one device 900 and / or at least one component of device 900. The number and arrangement of components shown are provided as examples. In some non-limiting embodiments, with... Figure 1 Compared to those shown, device 900 may include additional components, fewer components, different components, or components arranged in a different manner. Alternatively, a set of components of device 900 (e.g., one or more components) may perform one or more functions described as being performed by another set of components of device 900.

[0059] like Figure 4 As shown, device 900 may include bus 902, processor 904, memory 906, storage component 908, input component 910, output component 912, and communication interface 914. Bus 902 may include components that allow communication between components of device 900. In some non-limiting embodiments, processor 904 may be implemented in hardware, firmware, or a combination of hardware and software. For example, processor 904 may include processors (e.g., central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), etc.), microprocessors, digital signal processors (DSPs), and / or any processing component that can be programmed to perform functions (e.g., field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), etc.). Memory 906 may include random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by processor 904.

[0060] Continue to refer to Figure 4Storage component 908 may store information and / or software related to the operation and use of device 900. For example, storage component 908 may include a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, solid-state disk, etc.) and / or another type of computer-readable medium. Input component 910 may include components that allow device 900 to receive information, for example, through user input (e.g., touch screen display, keyboard, keypad, mouse, buttons, switches, microphone, etc.). Alternatively or additionally, input component 910 may include sensors for sensing information (e.g., Global Positioning System (GPS) components, accelerometers, gyroscopes, actuators, etc.). Output component 912 may include components that provide output information from device 900 (e.g., display, speaker, one or more light-emitting diodes (LEDs), etc.). Communication interface 914 may include transceiver-like components (e.g., transceivers, separate receivers and transmitters, etc.) that enable device 900 to communicate with other devices, for example, via wired connection, wireless connection, or a combination of wired and wireless connection. Communication interface 914 may allow device 900 to receive information from another device and / or provide information to another device. For example, the communication interface 914 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi® interface, a cellular network interface, and / or the like.

[0061] Apparatus 900 can perform one or more processes described herein. Apparatus 900 can perform these processes based on software instructions stored in a computer-readable medium such as memory 906 and / or storage component 908, executed by processor 904. The computer-readable medium may include any non-transient memory device. Memory devices include memory space located within a single physical storage device or memory space distributed across multiple physical storage devices. Software instructions can be read into memory 906 and / or storage component 908 via communication interface 914 from another computer-readable medium or from another device. When executed, the software instructions stored in memory 906 and / or storage component 908 cause processor 904 to perform one or more processes described herein. Alternatively or additionally, hardwired circuitry may be used in place of or in conjunction with software instructions to perform one or more processes described herein. Therefore, the embodiments described herein are not limited to any particular combination of hardware circuitry and software. The term “programmed or configured” as used herein refers to an arrangement of software, hardware circuitry, or any combination thereof on one or more devices.

[0062] Although embodiments have been described in detail for illustrative purposes, it should be understood that such details are for the purposes described only, and this disclosure is not limited to the disclosed embodiments, but is instead intended to cover modifications and equivalent arrangements that fall within the spirit and scope of the appended claims. For example, it should be understood that this disclosure contemplates, where possible, that one or more features of any embodiment may be combined with one or more features of any other embodiment.

Claims

1. A computer-implemented method comprising: receiving, with at least one processor of a payment system arranged remote from a first device operated by a first user and a second device operated by a second user, peer-to-peer payment data for a payment from a first account associated with the first user to a second account associated with the second user, the peer-to-peer payment data comprising a payment amount; generating, with the at least one processor, an asymmetric key pair comprising a first key and a second key; encrypting, with the at least one processor, at least a portion of the peer-to-peer payment data with the first key to generate encrypted payment data; storing the encrypted payment data; transmitting, with the at least one processor, the second key to the first device associated with the first user; receiving, with the at least one processor, the second key from the second device associated with the second user, wherein the second key was transmitted by the first user to the second user; decrypting, with the at least one processor, the encrypted payment data based on the second key received from the second device; and processing the payment from the first account to the second account based on decrypting the encrypted payment data.

2. The computer-implemented method of claim 1, further comprising: automatically sending the second key from the first device to the second device in response to input from the first user.

3. The computer-implemented method of claim 1, further comprising: automatically sending the second key from the first device to the second device in response to determining that at least one rule has been satisfied.

4. The computer-implemented method of claim 1, further comprising generating, with the at least one processor, a payment token based on the peer-to-peer payment data.

5. The computer-implemented method of claim 4, wherein the payment token comprises the encrypted payment data.

6. The computer-implemented method of claim 5, wherein the encrypted payment data comprises an encrypted value of the payment amount.

7. The computer-implemented method of claim 4, wherein the payment token comprises a unique identifier, an identifier associated with the second user, and the encrypted payment data, wherein the encrypted payment data comprises an encrypted value of the payment amount.

8. The computer-implemented method of claim 1, further comprising: transmitting, with the at least one processor, at least a portion of the peer-to-peer payment data to a first issuer system associated with the first account.

9. A system for revocable peer-to-peer payments comprising at least one processor of a payment system arranged remote from a first device operated by a first user and a second device operated by a second user, the at least one processor programmed or configured to: receive peer-to-peer payment data for a payment from a first account associated with the first user to a second account associated with the second user, the peer-to-peer payment data comprising a payment amount; generate an asymmetric key pair comprising a first key and a second key; encrypt at least a portion of the peer-to-peer payment data with the first key to generate encrypted payment data; store the encrypted payment data; transmitting the second key to the first device associated with the first user; receiving the second key from the second device associated with the second user, wherein the second key was transmitted by the first user to the second user; decrypting the encrypted payment data based on the second key received from the second device; and processing the payment from the first account to the second account based on decrypting the encrypted payment data.

10. The system of claim 9, wherein the at least one processor is further programmed or configured to automatically send the second key from the first device to the second device in response to input from the first user.

11. The system of claim 9, wherein the at least one processor is further programmed or configured to automatically send the second key from the first device to the second device in response to determining that at least one rule has been satisfied.

12. The system of claim 9, wherein the at least one processor is further programmed or configured to generate a payment token based on the peer-to-peer payment data.

13. The system of claim 12, wherein the payment token includes the encrypted payment data.

14. The system of claim 13, wherein the encrypted payment data includes an encrypted value of the payment amount.

15. The system of claim 12, wherein the payment token includes a unique identifier, an identifier associated with the second user, and the encrypted payment data, wherein the encrypted payment data includes an encrypted value of the payment amount.

16. The system of claim 9, wherein the at least one processor is further programmed or configured to transmit at least a portion of the peer-to-peer payment data to a first issuer system associated with the first account.

17. The system of claim 9, wherein the payment system includes at least one of a transaction processing system or a payment gateway.

18. A computer program product for revocable peer-to-peer payments, comprising at least one non-transitory computer-readable medium including program instructions, the program instructions, when executed by at least one processor of a payment system arranged apart from a first device operated by a first user and a second device operated by a second user, cause the at least one processor to: receive peer-to-peer payment data for a payment from a first account associated with the first user to a second account associated with the second user, the peer-to-peer payment data including a payment amount; generate an asymmetric key pair including a first key and a second key; encrypt at least a portion of the peer-to-peer payment data with the first key to generate encrypted payment data; store the encrypted payment data; transmit the second key to the first device associated with the first user; receive the second key from the second device associated with the second user, wherein the second key was transmitted by the first user to the second user; decrypt the encrypted payment data based on the second key received from the second device; and process the payment from the first account to the second account based on decrypting the encrypted payment data. decrypt the encrypted payment data based on the second key received from the second device; and process the payment from the first account to the second account based on decrypting the encrypted payment data.

19. The computer program product of claim 18, wherein the program instructions, when executed by the at least one processor, further cause the at least one processor to generate a payment token based on the peer-to-peer payment data.

Images