merchantNetAmountAtomic, keyed on paymentId, and prove it with a confirmed transfer. Keying a payment to your own record and surviving duplicate or out-of-order events belong to the payment; see Reconciliation.
The expected total is the frozen net, not the gross
Fees are calculated from the verified destination amount and deducted at final settlement, so the amount the payer sent never matches. Three things move the expected total:- A confirmed refund reduces what remains to settle. The remainder still settles.
- Fee movement is its own leg and is not part of the net.
- Network costs sit outside the calculation and never appear in the frozen fee fields.
Underpayment does not settle
There is no partial credit path. A payment funded below its obligation does not settle at the lower figure, so there is no settlement row to reconcile and nothing to credit. Receipts accumulate against the obligation until the full amount is verified. Duplicate, late, overpaid and underpaid receipts are reported inincidentRecoverySummary, deliberately separate from refundSummary. Keep them separate in your books too, so returning a duplicate never makes a fulfilled payable look refunded.
Hold a settlement that is recorded but not confirmed
This state looks finished from one angle and unfinished from another, and it produces the most reconciliation bugs.1
Hold it open
An amount without a confirmed transfer is a pending obligation in your books, not a receipt. Do not release against it.
2
Create nothing
No replacement payment, no second settlement. The first may still confirm.
3
Read the payment
GET /v2/payments/{paymentId} is the current answer. Check status and operationalState separately.4
Escalate if it stays
A settlement in
requires_intervention is cleared by a person. See Settlement failures.accepted for a long time while settlement retries, and can stay there permanently if settlement stops for review. accepted is not a settled payable.
Book a returned settlement as its own entry
payment.settlement_returned fires when a settlement that was already broadcast is returned or rejected, and the payment’s stage reads settlement_returned. This is an accounting correction, not a change to the financial result: a succeeded payment does not become failed, and there is no automatic replacement. Hold any credit.
The same applies to reversed rows and to deposit.reversed. Compensating entries are written, the underlying funds have usually already moved, and nothing is coming back on chain.
Never reconcile against account activity totals
The account activity totals are a reporting projection, reported asrecorded_activity_projection and not_a_custody_balance. They can be negative, and they do not fall when value settles out to a wallet the customer controls. Transactions covers what they are for.
Re-read anything non-terminal past your settlement window
Read anything non-terminal that is older than your expected settlement window, rather than waiting for a delivery that may not arrive. Stop once the payment is terminal: a financial result does not regress, and only the operational axis can still move.Next: Settlement failures
Which failures you fix in code, and which a person resolves.