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.
Refund receipt generation
Once a refund completes, a formatted PDF receipt is available — refund ID, date, amount, the affected items, reason, and the payment reference. Customers can download it from their own account, and you can pull the same document from the refund's detail view for customer-service purposes.
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.
