PaymentTransaction
Making Promises (Commit-Request)
When the payer has found payment paths with enough combined available credit to complete the payment, it sends a promise message to the first node on each path, representing its commitment to redeem a valid receipt that can be authenticated with the promise's authentication key up to the amount of credit indicated on the receipt, if presented before the stated deadline. A promise renews the credit held for each path and gives a new deadline for the expiry of these holds.
- payment ID
- swarm ID
- path ID
- amount to be held for payment, in transaction units
- ID of account to be made part of path by this promise being passed
- amount to be held for payment, in account units, according to conversion rate defined by neighbour in
path-querymessage - promise penalty deadline
- daily penalty rate if receipt or path-cancel not received before the penalty deadline
- promise final deadline, after which promise expires
- the payer's receipt authentication key for this payment path
- the recipient's receipt authentication key for this payment path
- a timestamp to indicate the time the promise came into effect.
Each node passes the promise message on to the next node in the path, as determined by path-responses received in the previous phase. At each step, the promise message is signed to the next node by the passing node's authentication key. This serves to establish the integrity and non-repudiability of the promise.
The penalty deadline is the time after which the promising node may begin charging a penalty to its partner for having to hold credit it could be using for payment. The penalty is charged continuously at the daily rate specified. Intermediaries should always set a shorter deadline and higher penalty rate on promises out than they have received on promises in, to ensure that they are compensated for overdue receipts. This provides incentive for the recipient to ensure quick completion or cancellation of each promise path, without requiring hard-and-fast deadlines to come into play so soon that minor delays spawn major disputes.
Nodes should only accept promises for paths in a single swarm for any given payment.
The recipient sends the payer promise-received messages, each indicating that a promise has been received:
- payment ID
- received promise's path ID
- final amount of promise in transaction units
- recipient's deadline for accepting the receipt for this path
- timestamp indicating current time
The recipient's receipt deadline to the payer should be well before the penalty deadline on any promise received. Therefore, the recipient should wait until it has received promises equal to the entire payment amount before sending back any promises-received to the payer.
The recipient can cancel the transaction at any time by sending the payer a payment-cancel and releasing its neighbours from their promises with a path-cancel (see Cancelling Unneeded Paths). The payer can cancel the transaction by sending the recipient a payment-cancel, informing it that it can release its neighbours from their promises. Released promises should be propagated back down each payment path to free up those funds for other payments.
When the payer receives promise-received messages equal to or exceeding the amount of the payment, he generates receipt messages matching the promises received by the recipient, –- one receipt per promise/path -- authenticates them individually with each path's authentication key, and sends them each to the recipient:
- payment ID
- path ID
- amount for this path in transaction units
The collection of receipts signed by the payer represents the value of the payment, and once they are given to the recipient, the recipient is considered to have been paid. If any of the receipts does not match its promise (eg, one of the amounts is wrong) or is otherwise invalid (to be rigorously defined), the amount of that receipt is not considered to have been paid until a valid receipt is issued. The recipient must reply with an error code when receiving an invalid receipt.