One item comes back.Reverse the exact transfer.
One seeded claim, five illustrated steps.
Each seeded scenario is presented on the same reviewable surface - evidence, split, reversal, approval, reconciliation. Here is demo claim RET-260903-031, start to close.
For partial refunds on a payment transferred to multiple accounts, Razorpay cannot determine which transfer to reverse partially. You will have to use the transfer reversal API.
Evidence in. Balanced plan out. Each demo step recorded.
After a return is approved, the prototype runs a reviewable state machine. It records intent before provider calls, pauses unknown outcomes for reconciliation, and waits for confirmed reversals before refunding.
needs_reviewPrecomputed returned-line and policy fixtures are treated as untrusted, validated against the seeded order, then passed to deterministic paise calculation.
ready_for_approvalA named operator approves the frozen plan, bound to an exact fingerprint. Separate maker-checker roles and RBAC remain production work.
processingPre-flight re-fetch fails closed on drift. Intent and a stable receipt are recorded so unknown Route outcomes pause for reconciliation, not a blind retry.
completedThe customer refund starts only after required reversals confirm; the simulator or configured Test Mode status is then recorded.
The missing brain between a return and your payout ledger.
Exact-paise allocation
Every rupee computed in integer paise with largest-remainder rounding - no floats, no drift. The split sums to the refund, to the last paisa, or it never runs.
Shortfall handling
When the reversible transfer balance is too low, the demo blocks approval, shows the residual, and can open an owned payments-reconciliation case instead of moving partial money.
Needs ₹850.85 · only ₹49.15 reversible → approval blocked, reconciliation required.
Fail-closed retry safety
A timed-out reversal becomes unknown, never a blind retry. The prototype fetches by stable receipt; durable cross-process protection remains production work.
reversal_result_unknown → reconcileProcess-local audit history
Exposure forecasting
A dated TimesFM 2.5 backtest measured aggregate refund exposure on 56 synthetic daily totals. It is illustrative planning evidence, not production accuracy.
Cross-rail roadmap
The prototype implements Razorpay Route simulation and an optional Test Mode adapter. Stripe Connect and Cashfree are roadmap research; no adapters are included.
Boring where it counts. Provable where it matters.
The prototype calculates the money plan without holding or pooling funds. Its default provider is a deterministic simulator; an optional Razorpay Test Mode adapter is available, and live keys are rejected.
Plan first. Execute after approval.
The workbench posts the reviewed fingerprint to its same-origin preflight route before approval, then enforces reversal-before-refund ordering. Demo state is process-local.
const claimId = "RET-260903-031";const endpoint = `/api/claims/${claimId}/preflight`; // Re-fetch provider state before approvalconst check = await fetch(endpoint, { method: "POST", body: JSON.stringify({ expectedPlanFingerprint }),}); if (!check.ok) return "fail_closed";// Approval uses the same reviewed fingerprint// and executes through the server-side saga.No. The default provider is a deterministic simulator, and the optional adapter accepts Razorpay Test Mode credentials only. ReturnSplit never pools or custodies funds; live keys are rejected.
For a partial refund on a payment split across multiple Route transfers, Razorpay cannot decide which transfer to reverse - its own docs say so. This prototype computes the per-seller paise and demonstrates reversal-before-refund ordering in a resumable, process-local saga. Durable crash recovery remains production work.
The demo blocks approval when the reversible balance is insufficient (claim RET-260903-038 has only ₹49.15 available), exposes the residual, and can open an owned payments-reconciliation case. It does not silently continue or write off the gap.
Amounts are computed in integer paise with largest-remainder rounding. Across 64 pre-structured synthetic records, the engine matched all expected finance-control decisions with ₹0 wrong-seller overage and 0 unsafe automations. That is fixture agreement, not extraction accuracy or live-provider evidence.
The workbench records process-local approval, execution, and operations history and can generate a redacted audit export. It is not durable, signed, hash-chained, WORM-retained, or a compliance record; production needs an authenticated, tenant-scoped, tamper-evident store.
Open the workbench and replay seeded partial-refund scenarios through the deterministic split, human approval, simulated execution, and audit export. The fixtures are synthetic and do not ingest a live merchant return.
See exactly which transfer to reverse.
Open the workbench and replay a seeded partial-refund scenario - the per-seller split, approval gate, simulated execution, and process-local audit history.