Refund the right transaction with the right approval
For Billing / revenue-cycle manager · Plan implementation
TL;DR — what you’ll learn
- Link a refund request to the original payment and an authorised commercial adjustment.
- Keep approval, payment execution and confirmed outcome as separate states.
- Reserve approved pending amounts so concurrent requests cannot reuse the same balance.
- Reconcile retries and duplicate callbacks against one intended refund.
A clinic receives a ₹5,000 payment and approves a ₹2,000 refund after a reviewed billing correction. The payment service returns a delayed response. An operator retries, then the original callback arrives twice. Without a stable refund identity, the system may mistake these events for separate instructions to pay.
A refund pilot should establish one authorised instruction, its original payment reference, its approved destination and amount, and a reconstructable execution history. An unknown outcome needs reconciliation before another financial instruction is created. Approval to refund is not evidence that the payment processor has completed it.
Establish the authorised amount before execution
Begin with a refund decision supplied by the authorised finance/commercial owner, linked to the payment, adjustment evidence, amount and permitted destination. Obtain the actual beneficiary checks and approval rights before enabling execution. The R-48 example tests the instruction’s history; it establishes no refund entitlement, tax entry, statutory deadline or universally permitted payment route.
The system needs an approved amount and a way to distinguish it from the processor's refundable limit. A ₹5,000 original payment does not mean that a full ₹5,000 refund is currently authorised. Other refunds, disputes or unsettled instructions may also affect what can safely be submitted.
Razorpay documents refund creation, retrieval and idempotent requests. Check the supported payment state and exact request/lookup contract for the intended integration, then demonstrate lost responses and repeated callbacks in its test environment. These documented options do not prove the hospital’s implementation or confer the same retry semantics on another gateway or a manual bank transfer.
Reconcile the ₹5,000 example through pending and completed states
Assume the original ₹5,000 payment is eligible for the supported refund route and no other adjustments exist. Finance approves refund R-48 for ₹2,000. While execution is pending, reserve that ₹2,000 against additional refund submissions. The unreserved payment amount is ₹3,000, but a further refund still needs separate authority.
When the confirmed outcome records one completed ₹2,000 refund, the remaining payment amount is ₹3,000. Replaying the callback should leave both numbers unchanged. It records or recognises an existing outcome; it does not create another refund.
Scroll horizontally to see all columns.
| Event | Completed refunds | Pending reserved amount | Unreserved payment amount |
|---|---|---|---|
| Before R-48 | ₹0 | ₹0 | ₹5,000 |
| R-48 submitted, unresolved | ₹0 | ₹2,000 | ₹3,000 |
| R-48 confirmed complete | ₹2,000 | ₹0 | ₹3,000 |
| Same completion replayed | ₹2,000 | ₹0 | ₹3,000 |
The pending reservation is an illustrative control model that finance and the payment owner must approve for the actual integration. Require evidence distinguishing confirmed completion, definitive failure and unknown outcome, and agree the corresponding ledger treatment. A timeout remains unknown in this model, so it cannot by itself release the reservation or authorise a replacement instruction.
Compare gateway and manual-bank paths
A gateway path can often link execution to the original transaction and return machine-readable references. It still needs approved credentials, appropriate access and a reconciliation owner. A manual bank path may require separately verified destination evidence, bank approval and later statement matching. It should not inherit assumptions about gateway idempotency.
For either path, keep creation authority separate from execution permission where the provider's policy requires it. A changed destination or amount should return to the required review rather than being treated as a technical retry.
Worked workflow
Original illustrative workflow. Follow the labelled transitions, including the exception paths.
- A · StepPayment and authorised adjustment identified
- B · StepApprove amount and permitted destination
- C · StepReserve amount under one refund identity
- D · StepSubmit through approved payment route
- E · DecisionOutcome confirmed
- F · StepHold reservation and reconcile status
- G · StepRecord completed or definitive failed outcome
- H · StepFinance reconciles payment and refund ledger
Scroll horizontally to see all columns.
| From | Condition | Next |
|---|---|---|
| A: Payment and authorised adjustment identified | Continue | B: Approve amount and permitted destination |
| B: Approve amount and permitted destination | Continue | C: Reserve amount under one refund identity |
| C: Reserve amount under one refund identity | Continue | D: Submit through approved payment route |
| D: Submit through approved payment route | Continue | E: Outcome confirmed |
| E: Outcome confirmed | No | F: Hold reservation and reconcile status |
| E: Outcome confirmed | Yes | G: Record completed or definitive failed outcome |
| F: Hold reservation and reconcile status | Continue | E: Outcome confirmed |
| G: Record completed or definitive failed outcome | Continue | H: Finance reconciles payment and refund ledger |
Run a bounded pilot with a stop condition
Use synthetic or provider-approved sandbox transactions first. Test partial refunds, two simultaneous requests against one payment, a lost response, duplicated callbacks, changed payloads under the same request key and a definitive failure. Record expected balances before execution. Do not expand the pilot if the system cannot explain one intended refund and every pending amount.
A reviewed manual fallback should query or investigate the existing instruction before creating a replacement. Log who made that decision and its evidence. The acceptance condition is no duplicate financial instruction in the agreed challenge set, correct amount/destination validation, and a queue that exposes unresolved outcomes. It is not a promise that every external payment will complete within a fixed time.
Refund control succeeds when finance can reconstruct the authorisation and the payment owner can reconstruct execution. Keeping those histories linked makes retries manageable without confusing a technical message with fresh authority to pay.
Next actions
- Agree refund authority, destination validation and the payment-state balance model with finance.
- Run R-48 through pending, completed, replayed and definitively failed cases in a safe test environment.
- Accept the pilot only when every refund instruction and unresolved amount reconciles to its original payment.
Discuss this workflow
Request a workflow assessment focused on this question: How can an operator prevent duplicate or misdirected refunds after a cancelled or corrected bill?
Describe the operation using business information only. Please leave out patient details.
Applying this guide
The scenarios and numbers are illustrative. Confirm these provider-specific inputs before implementation:
- Finance approver, payment owner and legal/security reviewers: Applicable commercial/refund policy, corrected liability evidence and approved destination/access controls.
- Finance controller and payment operations lead: Approved balance model and accounting entries for pending, completed, failed and disputed instructions.
- Payment integration engineer and gateway/bank owner: Current provider/version documentation plus sandbox tests for concurrent requests, replay, payload changes and unknown outcomes.
References
- Razorpay refund APIs — Documented API surface only; supported payment states, version and actual implementation must be checked.
Topics: hospital refund management · hospital patient refund workflow · clinic refund approval · payment refund reconciliation