ReturnSplit

Operator signals

Marketplace refund ownership is still unclear.

Public operator discussions showing the same reconciliation gap across marketplace payment rails.

In multi-store orders, this feels inconsistent and harder to reconcile: reporting, refund logic, disputes, accounting clarity.

multi-store paymentsView on Reddit

Public threadpayment operations

Whenever I refund a charge, the refund is actually getting taken from the business account instead of the connected account.

connected-account refundsView on Reddit

Public threadpayment operations

With split payments, the application is liable for fees, chargebacks and refunds. I would like the vendor to be liable.

multi-vendor marketplaceView on Reddit

Inside the workbench

Three views. One controlled refund.

Focused tools for deciding what moves, preparing for what returns, and keeping the outcome reviewable.

01 · Allocation

Balance every seller to the last paisa.

Integer-paise math assigns the exact seller reversal and platform contribution before approval.

Inspect the calculation

02 · Reserve

See refund exposure before it hits the queue.

The reserve view turns expected returns into a planning signal for finance operations.

Open reserve planning

03 · Assurance

Keep the decision attached to the outcome.

Approval, provider results, and paused exceptions stay together for review and reconciliation.

Ordering ruleReversals confirm before the customer refund starts.

FAQ

Questions? Answered.

Start with the golden claim, then inspect the evaluation snapshot.

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.