A merchant commissioning a refund status page needs more than a green success message after an API response. Customers and staff need to distinguish an accepted request, a pending provider state and a failed refund. The display should retain an operation identity so a retry does not obscure the original outcome.
Primary evidence and claim boundaries
Stripe documents pending and failed refund outcomes, payment-method differences and status updates. Funds and completion timing depend on the actual method and provider state; creating a refund does not establish that the customer’s bank received it. Primary reference · Read 18 October 2026.
Filled acceptance example
Original synthetic teaching scenario, not a client case, provider integration test or business result. The example policy needs the actual owner’s approval; scroll the table on narrow screens.
| Input and state | Declared check | Expected output and decision |
|---|---|---|
| Captured10000 minor units; refundR1=2000 succeeded | Verified provider record | Show R1 succeeded; do not infer a bank posting date |
| R2=1000 pending | Merchant model reserves pending amount | Reserve1000; show pending, not completed |
| R3=1000 failed | Failure record retained | Escalate; do not relabel as success or silently create a new refund |
| R1 succeeded plus R2 pending | Declared reservation model | 10000−2000−1000=7000 unreserved; not a bank balance |
Practical handover procedure
- Agree customer wording and the merchant’s internal reservation rule. Keep captured, requested, pending, succeeded and failed amounts in separate fields with currency and operation IDs.
- Use the four synthetic rows to check arithmetic and state transitions. In an authorised provider test account, reconcile actual status updates without treating a browser return as payment evidence.
- Require staff to resolve an unknown or failed operation before retrying. Reconcile customer-facing messages with the retained provider record and disclose unresolved completion.
Interpret the outcome
The7000 is the output of an explicitly declared teaching reservation policy. It is not Stripe’s universal available-refund formula, a payout balance or proof of bank settlement. Keeping R3 visible makes a failure reviewable instead of erasing it with a replacement success badge.
Acceptance decision
Require correct state labels, arithmetic and operation continuity against verified test records. A customer completion promise needs its own method-specific evidence.
Limits and unverified work
Synthetic amounts and policy only. No refund, payment, account lookup or financial advice; provider permissions, fees and actual bank outcomes remain unverified.
Download the filled bilingual acceptance record — Contains the inputs, steps, expectations and limits. This is a teaching record, not an executable production integration.