PAYMENT TOOL · ATTEMPTS AND RECEIPTS
Payment operation: inspect attempts, receipts and refunds
A charge times out after the card was taken, a bank asks for 3-D Secure, and a refund is requested twice. Read the provider’s records against what the agent says.
Your experiment
Order O-1 costs 80. The first charge is captured by the provider but the response times out, and the agent retries. Order O-2 costs 65 and the provider answers HTTP 200 with status requires_action, because the bank wants 3-D Secure. Then the customer asks for 50 back on O-1, and the agent, unsure, asks again. The customer should end up paying 30 for O-1.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Fictional provider behaviour following common payment-API conventions: a timeout after the request was sent leaves the outcome unknown, and repeating a request with the same idempotency key returns the original result. Real providers differ in key lifetime and status names. No payment service is called.
Three records that must agree
Every payment step has the provider’s record and the agent’s reading of it. Idempotency key decides whether a repeated charge can be recognised as the same payment: none, a fresh key per attempt, or one key per order. Retries after a timeout sets how often the agent tries again. Tell the customer “paid” on chooses between any HTTP 200 and a receipt whose status is succeeded. Look the order up before retrying asks the provider what already happened. Cap refunds at the order’s captured amount stops refunds beyond what was taken.
The opening run: 60 instead of 30
The first O-1 charge was captured as ch_1, but the response timed out, and with no key the retry captured another 80 as ch_2. O-2 got HTTP 200 with requires_action, and the agent told the customer it was paid although nothing was captured. Then both refund requests of 50 went through. The customer has paid 160 and received 100 back for an order that should cost them 30: net 60, one duplicate charge, one false confirmation, one extra refund.
Making retries and confirmations safe
A new key for every attempt changes nothing: the provider sees two different payments. One key per order makes the retry return ch_1, so only one 80 is captured. Look the order up before retrying finds ch_1 and sends no retry at all. With 0 retries and no lookup, the agent tells the customer the payment failed although 80 was taken. A receipt with status succeeded keeps O-2 from being confirmed and sends the 3-D Secure step instead.
Failure boundary: the refund side
With one key per order and receipts, both refunds still run: 100 back on an 80 order, net -20. Tick Cap refunds at the order’s captured amount: the second request finds only 30 left and is refused, and the net is the intended 30. All three, key per order, receipt and cap, or a lookup with no retries, give a clean record. A timeout is an unknown outcome, never a failure, and every message to the customer must be backed by a provider record.
Reading the run and its limits
Play replays each charge, the O-2 answer and both refunds over sixty inspection seconds; the table lists every request, the provider’s record and the agent’s reading. Next event, Restart, Speed and Inspection time control the replay. Provider behaviour is a simplified convention: real APIs expire keys, return different status names and settle refunds later, so read your provider’s documentation and reconcile from its records and webhooks.