Receipt Confirmations

Target releaseTBD
Epic
Document statusDRAFT
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

#TitleUser StoryImportanceNotes
1Transaction cancellationAs 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.
3TimingAs 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.
4New transaction typeAs 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 transferMust Have
  • Separate transaction type that includes transaction receipts.
5LedgerAs 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:

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


Not Doing