Peer-to-Peer Payment Key Control for Revocable Transfers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing peer-to-peer payment systems do not allow payors to revoke payments once they have been made, even if the payee is not present to accept them, leading to potential disputes and inefficiencies.
Innovation Solution
A system utilizing asymmetric key pairs for encrypting payment data, where the decryption key is controlled by the payor, allowing them to revoke payments by controlling the decryption process.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If direct payments are made through banks, then payment transfer is completed, but the payment cannot be revoked once made
Solution Approach 1:
The payment process is segmented into distinct phases: payment initiation, key generation, encrypted data storage, and conditional decryption. By separating the payment authorization from the actual fund transfer and introducing intermediate encryption/decryption steps, the system enables revocability while maintaining security. The payment is not fully executed until the decryption key is provided, allowing the payor to revoke by simply not providing the key.
Solution Approach 2:
The system performs preliminary actions by generating encrypted payment data and storing it before the actual payment execution. The decryption key is generated and held separately, allowing the payor to control whether the payment proceeds. This preliminary encryption step creates a reversible state where the payment can be cancelled by withholding the decryption key, resolving the contradiction between security and revocability.
2Reliability
If asymmetric key pairs are used for encryption, then payment security is improved, but computational resources increase
Solution Approach 1:
The system uses asymmetric key pairs where the public key can be freely distributed and the private key remains secure. This copying mechanism allows the encrypted payment data to be stored and transmitted without compromising security, while the computational intensive operations are performed only once during key generation and encryption, not continuously during storage or transmission.
Solution Approach 2:
The system changes the cryptographic parameters by using asymmetric encryption specifically for the payment data encryption step, while relying on symmetric encryption or simpler authentication mechanisms for other parts of the system. This selective application of strong cryptography minimizes overall computational overhead while maintaining security where it is most critical.
3Adaptability or versatility
If decryption key control is given to payor, then payment revocability is enabled, but system complexity increases
Solution Approach 1:
The system introduces an intermediary component that manages the decryption key and coordinates between the payor, payee, and payment processor. This intermediary handles the complexity of key management, secure storage, and conditional release, allowing the payor to control revocability through simple actions (withholding or releasing the key) without directly managing complex cryptographic operations.
Solution Approach 2:
The payor is empowered to self-manage the payment revocation by controlling the decryption key themselves, without requiring intervention from bank officials or complex dispute resolution processes. The system provides automated mechanisms for key generation, storage, and release that the payor can control through standard user interfaces, reducing the need for manual intervention and simplifying the overall process despite the cryptographic complexity underneath.
Data Source
AI summary
A method, system, and computer program product is provided for revocable peer-to-peer payments. The method includes generating an asymmetric key pair comprising 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 the payment from the first account to the second account based on decrypting the encrypted payment data.