Receipt Confirmations

Target release	TBD
Epic
Document status	DRAFT
Document owner	@Medha Parlikar (Unlicensed)
Designer
Developers
QA

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

	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	Likely need to have some kind of timing constraint (as defined in #3) - by which time the transaction will be cancelled.
2	Receipt	As a payment processor, I require a receipt that confirms that funds arrived at a destination address (recipient).	Must Have	The receipt will have to have a data structure defined. TBD. Certain pieces of information - origin, destination, sender info, will likely be required.
3	Timing	As a payment processor, I would like to receive a receipt 'shortly' after the funds arrive at the destination address.	Must Have	The receipt need not be immediate, but it should be within a 'short' time after the funds have arrived at the destination address.
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	Separate transaction type that includes transaction receipts.
5	Ledger	As a payment processor, I need to have cancellations recorded on the blockchain ledger.	Must Have	Both the original transaction and the cancellation need to go on a blockchain ledger.

User interaction and design

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Question	Outcome

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?