Refunds
The admin refund queue, the approval workflow, partial refunds, and what happens to your stock and receipts once a refund completes.
Go to Refunds in the left navigation. This is the queue and ledger for every refund request on your store, whether it started from an order cancellation, a customer return, or an item that arrived damaged.
The refund queue
The Refunds screen opens on a queue of requests, each showing the order, customer, requested amount, status, and reason. At the top you'll find:
- Pending — requests waiting on your decision.
- Approved today — how many you've processed today.
- Total refunded — running total for the period shown.
- Decline rate — the share of requests you've rejected.
You can filter by status (All, Pending, Approved, Declined, Completed), filter by reason, sort the list, and search across the queue.
Tip
Pending rows expose inline Approve and Decline actions directly in the table, so you don't always need to open the detail view to act on a request.
Acting on several requests at once (newer dashboard skin)
On the newer dashboard skin, pending rows also have a checkbox. Tick more than one and a bulk action bar appears at the bottom of the screen with three actions: Export (downloads just the selected requests), Decline, and Approve — letting you clear out a batch of pending requests in one pass instead of working through them one at a time. Only pending rows can be selected; approved, declined, and completed requests don't show a checkbox.
Refund intelligence (newer dashboard skin)
Above the queue, an advisory panel compares your refund rate against a category-average benchmark, and breaks down your most common refund reason and what share of requests it makes up. This is informational only — it doesn't change how requests are processed — and is meant to help you spot whether refunds are trending unusually high before it becomes a bigger problem.
Refund risk signals (newer dashboard skin)
A separate, collapsible panel surfaces advisory warnings worth a second look, such as a specific customer who has filed several refund requests recently, or your refund rate running above the category average. Each signal has Review and Hide actions. Like the intelligence panel above, these are advisory nudges — nothing is blocked or auto-actioned based on them.
The refund approval workflow
Every refund request follows the same status path:
Pending → Approved → Processing → Completed
↓
Rejected
Request arrives as Pending
The request shows the requested amount, the items involved, and the reason the customer or the order record gave.
You review it
Open the request from the queue (or use the inline actions on a pending row) to see the full detail: order, customer, items, and reason.
Approve or decline
Approve to authorize the refund — you can adjust the amount down first if only a partial refund is warranted, and you can add notes. Decline to reject the request; add a reason so the record explains why.
The platform processes the payment reversal
Once approved, BillionBiz instructs the payment gateway to return the money to the customer's original payment method — the same card, UPI account, wallet, or bank account they used to pay. This typically reaches the customer within 5–7 business days depending on their bank.
Status settles to Completed
The refund moves to Completed once the payment gateway confirms the reversal. If the gateway call fails, the refund is marked Failed and can be retried from Approved again.
Partial refunds
You are not required to refund the full requested amount. When approving a request, you can lower the approved amount below what the customer requested — for example, to deduct a restocking fee or because only some of the items were returned. The approved amount can never exceed the requested amount, and BillionBiz records your reason alongside the adjustment so the customer sees a clear breakdown of original versus approved amount.
Inventory restoration on refund
When a refund reaches Completed, the platform automatically adds the refunded item quantities back into your stock — you don't need to make a manual stock adjustment. This runs per line item, so a partial refund only restores the items that were actually part of that refund. If the stock update itself fails for some reason, the refund still completes; the discrepancy is caught by your normal inventory reconciliation rather than blocking the customer's money from moving.
Refund status tracking
Every refund carries its own status independent of the order it belongs to, so you can track it even after the order itself shows Cancelled or Returned. The order's payment record also updates to show a partial refund or full refund state once money has moved.
When a refund shows Failed
A Failed refund means Razorpay rejected the reversal — no money moved, and the customer has not been paid back. The reason is written into the refund's notes and into the Auto-Refund Failed notification in your admin notifications.
Retry the same refund rather than creating a second one: open it in the refund queue and approve it again. A Failed refund is allowed to go back to Approved, and re-approving reuses the same refund record, so there is no risk of the customer being paid twice.
Common reasons, and what to do about each:
| Reason shown | What it means | Fix |
|---|---|---|
| The payment was captured on a Razorpay account this store no longer has credentials for | The order was paid through a different Razorpay account than the one currently connected — usually because the Razorpay keys under Plugins → Razorpay were changed, rotated, or disconnected after the order was placed. | Re-connect Razorpay with the same key pair that was live when the order was paid — see Connecting Razorpay — then re-approve the refund. Your Razorpay dashboard shows which account holds the payment. |
| Your account does not have enough balance to carry out the refund operation | Your Razorpay balance is lower than the refund amount. | Add funds in the Razorpay dashboard (or wait for new captures to settle), then re-approve. |
| The payment has been fully refunded already | The money was already returned — usually refunded directly in the Razorpay dashboard. | No action needed on the money; re-approve to bring BillionBiz's record in line. |
| Could not verify which Razorpay account holds this payment | Razorpay was unreachable when the refund was attempted. Nothing was sent. | Transient — re-approve the refund. |
Note
BillionBiz always confirms which Razorpay account actually holds a payment before reversing it, so a refund is never sent from the wrong account. That check is why a mismatched or disconnected key surfaces as a clear Failed reason instead of a silent failure.
Credit notes
The moment a refund reaches Completed, BillionBiz automatically generates a credit note — no action needed from you. A credit note also gets generated the same way when a paid, invoiced order is cancelled — the cancellation cascade refunds the payment and issues a full credit note in one step, covered in Cancelling an order. And you can trigger one directly, without a refund, from an order's Invoice ▾ → Cancel & reissue menu — see Cancelling and reissuing an invoice — for correcting an invoice on its own, such as a data-entry mistake. Whichever path creates it, a credit note is:
- Immutable — once created, nothing about it (amount, GST split, or number) is ever edited.
- Sequentially numbered, using the same financial-year-scoped numbering as your invoices, with
a
CNmarker so it's clearly distinguishable from an invoice number. - Emailed automatically to the customer with the credit-note PDF attached.
On the order detail screen, a refund-triggered credit note's number appears on the Refund node of the order timeline once it's been generated — see The order timeline — and any credit note (refund- or cancellation-triggered) also shows on the Invoice & GST card. On the customer's own side, once it's ready, a credit note tied to a refund shows on their order page under that refund with its own Download link — see Payment & invoice.
A cancellation-only credit note (no separate refund request) may not show on the customer's order page yet
The customer order page's credit-note line is driven by a refund record. When cancelling an order triggers the refund-and-credit-note cascade together (the common case — see above), the customer sees both. But the standalone Invoice ▾ → Cancel & reissue action creates a credit note with no refund record attached at all — if you use it on an order that otherwise stays as-is, the customer won't see a credit-note line on their own order page, even though the credit note exists and was emailed to them. Point the customer to the email if they ask where their credit note is in this case.
No in-app download for your own team yet
The admin order screens show the credit note's number, but there's no download button for the PDF on the admin side yet — if you need a copy for customer service, forward the original notification email, or ask the customer to download it from their own order page.
Payment-method filter, evidence photos, and refresh now match on both skins
The newer dashboard skin's refund queue has a payment method filter alongside reason and sort, a manual refresh button next to the filters, and the refund detail drawer shows any customer-submitted evidence photos when the request has them — the same extras the classic screen has always had. The approval workflow itself — approve, decline, partial amounts, and status tracking — has always worked the same on both.
Next steps
- The Orders List & Order Lifecycle — where a refund request often starts.
- Order Detail: Status, Cancellation & Fulfilment Handoff — starting a refund from an order.