BigCommerce partial refund: the complete guide

To issue a BigCommerce partial refund, open the order in your control panel, choose Refund from the order's action menu, and refund either specific line items or a custom amount — provided the payment has settled and your gateway supports refunds. The two methods are not interchangeable: line-item refunds calculate the tax owed back to the customer, while custom-amount refunds are recorded with zero tax. Pick the wrong one and your books, your tax reports and your accounting integration all inherit the error.

Partial refunds are where BigCommerce's order tooling gets genuinely confusing, because three separate systems are involved — the order record, the payment transaction, and the tax engine — and a partial refund only updates the ones you explicitly tell it to. This guide walks through what actually happens on each path, the traps merchants hit most, and the workflow that keeps everything reconciled.

Where partial refunds live in BigCommerce

Refunds run from the order's action menu in the control panel. Two conditions must be true before the Refund action even appears:

• The transaction has settled. A payment that's only authorized can't be partially refunded — you'd void or capture it first. Refunds operate on captured money.
• Your gateway supports control-panel refunds. Most major gateways do. If yours doesn't, the option won't show, and you'll process the money movement in the provider's own dashboard instead — more on recording that correctly below.

When the action is available, BigCommerce offers two modes: refund specific line items (pick products and quantities, optionally include shipping or handling) or refund a custom amount against the whole order. This choice matters more than it looks.

Line-item vs custom amount: the zero-tax trap

A line-item refund is the well-behaved path. BigCommerce knows which products are going back, so the tax engine calculates the tax portion to return, the refund total comes out right, and downstream systems can attribute the refund to the right items.

A custom-amount refund is a blunt instrument. You type a number, and that number moves — but the existing order tax is not recalculated. BigCommerce records an order-level custom refund with zero tax, a documented behavior that surfaces constantly in merchant forums and in the docs of accounting integrations, some of which resort to mapping order-level refunds to a tax-exempt rate just to keep ledgers consistent.

The practical rule: use line-item refunds whenever products are involved, and reserve custom amounts for genuinely non-taxable concessions — a goodwill credit, a shipping refund where shipping wasn't taxed. If you refund a taxed product via a custom amount, you've returned the customer's tax money while your tax report says you didn't.

The second trap: the order doesn't re-net

A partial refund moves money; it does not edit the order. Remove-one-item refunds done as a bare money movement leave the order's line items, totals and analytics exactly as they were — the order still claims the customer bought and paid for everything. The inverse is also true: editing the order's items doesn't touch the captured payment, because BigCommerce can't re-charge or re-net a settled transaction.

So a clean "customer dropped one item" flow is two deliberate steps: refund the specific line item (money leg), then edit the order to remove it (record leg) so fulfillment doesn't ship it anyway. Skip the second step and the pick-pack team works from a lie.

The clean workflow, gateway by gateway

Supported gateways (the mainstream processors): do everything from the control panel with line-item refunds. The money returns through the original payment method automatically. Note that most processors keep the original transaction fee when you refund — the customer is made whole, but you're out the processing cost both ways.

Unsupported or offline payments (bank deposit, check, phone orders, legacy gateways): move the money in the provider's dashboard or by bank transfer, then record the refund in BigCommerce as an offline refund so the order data reflects reality. The refund exists in two places by definition; your job is keeping them in sync.

For developers: the Orders V3 API makes the safe path explicit with a two-step flow. First POST a refund quote, which returns the calculated tax amount, the total to refund, and the payment methods available; then create the refund using the quote's values and provider ID. The quote is the source of truth — computing refund amounts yourself is how rounding and tax errors creep in.

Store credit: the partial refund that keeps the sale

BigCommerce has native store credit: add an amount to the customer's account from the control panel, and it's automatically offered as payment at their next checkout. As a partial-refund alternative it has real advantages — the money stays in your store, you don't pay a second round of processing fees, and the customer comes back to spend it, often on a basket larger than the credit.

Two caveats. The customer needs a store account for credit to attach to, so guest checkouts need converting first. And store credit must be offered, not imposed: consumer law in several regions — the EU's 14-day cooling-off period most prominently — entitles customers to an actual refund, so credit-only policies can put you on the wrong side of it. The winning pattern is a choice with a sweetener: "$20 back to your card, or $25 in store credit."

Cut the ticket out of the loop

Step back and most partial refunds start the same way: a customer emails to remove an item, downsize a quantity, or swap to something cheaper. A staff member then performs the two-leg dance above by hand. The refund isn't the problem — the ticket is.

OrderEdit.io moves that whole loop to self-service on BigCommerce: the customer removes or swaps the item themselves within a time window you control, the difference is refunded under a rule you set — original payment method or store credit, their choice or yours — and the order record updates to match. Your team handles exceptions, not arithmetic. Plans start at $39/mo with a 21-day free trial.

The checklist

• Payment settled and gateway supported? If not, refund at the provider and record it offline.
• Products going back? Line-item refund, never a custom amount.
• Custom amount? Only for non-taxable concessions.
• Item removed? Refund the money and edit the order record.
• Offering store credit? Make it a choice, sweeten it, and check your jurisdiction's refund rights.