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
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
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?

RChain wiki