Receipt Confirmations
Goals
- Growth
Background and strategic fit
Payment processors will want receipt confirmations. If there is a problem with sending funds (no receipt is received), the transaction can be cancelled, and reverted. This is to prevent funds from winding up in a 'black hole' or being lost.
Assumptions
- This will not be required as part of a basic transaction. This will be a separate transaction type that has receipt confirmations to support cancellations.
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | Transaction cancellation | As a payment processor, I require the ability to cancel a transaction when I fail to receive a receipt that the funds arrived at the destination address (recipient). | Must Have |
|
| 2 | Receipt | As a payment processor, I require a receipt that confirms that funds arrived at a destination address (recipient). | Must Have |
|
| 3 | Timing | As a payment processor, I would like to receive a receipt 'shortly' after the funds arrive at the destination address. | Must Have |
|
| 4 | New transaction type | As a payment processor, I need a separate transaction type that includes transaction receipt functionality so that I can ensure that no funds are lost to a bad transfer | Must Have |
|
| 5 | Ledger | As a payment processor, I need to have cancellations recorded on the blockchain ledger. | Must Have |
|
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
| What is the data structure of the receipt? | |
| What is the expected latency before a receipt can be sent? | |
| What is the structure of the cancellation message? | |
| How do we ensure that a race condition isn't in play? What if the network hits unexpected latency is reaching consensus on the transaction- and the transaction cancellation is sent just as the transaction confirms? | |