An order-level refund returns an amount against an order or its payment without necessarily assigning that amount to particular line items. It is not a universal ecommerce standard: each platform can treat products, shipping, tax, inventory, and reporting differently. In Runner, the closest supported workflow is a payment-level refund entered in Orders, while payment and fulfillment remain separate states that operators verify independently.
Key takeaways
- “Order-level” describes where a refund is recorded, not whether the refund is full or partial.
- Item allocation, shipping, tax, inventory, and reporting behavior depend on the commerce platform.
- A refund changes payment state. It does not automatically cancel an order, stop fulfillment, or return stock.
- Before submitting, verify the order, payment, amount, currency, prior refunds, fulfillment state, and provider rules.
- In Runner, an eligible refund uses an amount and optional note against a captured payment; the operator reviews fulfillment separately.
What does “order level refund” mean?
An order-level refund is a refund amount associated with the order or payment as a whole rather than an amount allocated to one or more specific product lines. That makes it useful for adjustments that do not map neatly to one item, such as a courtesy credit, a shipping adjustment, or a percentage-based correction across an order.
The term does not tell you how much money is returned. An order-level refund can be partial or full. It also does not tell you how a platform will distribute the adjustment across subtotal, shipping, tax, discounts, inventory, or reporting. Those behaviors are implementation details, so the platform and payment provider remain the authority.
The distinction is visible in platform documentation. A BigCommerce Help Center search-result snippet lists individual-item, entire-order, and order-level refund choices, while Walmart Marketplace requires sellers to adjust each item separately. The same phrase therefore cannot be treated as a portable accounting rule.
How does an order-level refund differ from other refunds?
The practical difference is allocation. First decide whether the refund must be tied to particular products, then decide the amount.
| Refund scope | What it records | Typical use | What still needs verification |
|---|---|---|---|
| Order-level refund | An amount against the order or payment without required line allocation | Courtesy credit, shipping correction, or broad order adjustment | Tax, shipping, discount, inventory, and reporting treatment |
| Item-level refund | An amount or quantity tied to selected order lines | Returned, damaged, missing, or incorrectly priced products | Quantity, item tax, restocking, and inventory disposition |
| Full refund | The entire refundable payment amount | Complete cancellation or return when the payment is eligible | Whether the order or fulfillment also needs cancellation |
| Partial refund | Less than the total refundable amount | Price adjustment, retained item, partial return, or service recovery | Remaining refundable balance and the reason for the deduction |
These categories overlap. A platform can issue a partial item-level refund, a full item-level refund for one line, or a partial order-level adjustment. “Full versus partial” describes the amount; “order versus item” describes the allocation.
How Runner handles refunds
Runner keeps the financial action narrow. In the current Orders experience, an eligible captured payment exposes Refund Payment with a refund amount and optional note. After a successful request, Runner reloads the order so the operator can inspect the updated payment state. The Runner Orders guide documents the visible payment and fulfillment states and the actions available from each state.
Runner does not present that payment amount as an item-allocation tool. If a store needs to decide which products return to stock, which shipment should stop, or whether a line remains fulfillable, those are separate operational decisions. This boundary matters because refunding money and changing the physical order are not the same action.
The direct Orders action and an AI-proposed store change use different execution paths. The direct action sends the selected payment, amount, and note, then refreshes the order after the provider reports success. Operators should inspect that refreshed record before retrying.
When Runner proposes a refund as a reviewed AI-generated store change, the safeguards are stronger. That separate path checks the targeted order and payment revision, currency, captured amount, and already-refunded amount before dispatch. It uses a stable operation key, checks the provider response, then reads the payment state again. If a lost response makes the result ambiguous, it stops rather than claiming that a similar-looking refund belongs to the request or blindly repeating the financial mutation.
Neither path promises that every provider uses the same refund rules or completion time. The broader AI ecommerce order management capability connects this payment work to the order record, while the Orders guide remains the source for the current task flow.
What should you check before submitting a refund?
Check the financial target and the physical-order consequences separately. A short review prevents an amount correction from creating a second inventory, shipment, or customer-service problem.
- Confirm the order and customer. Match the order identifier, customer, currency, items, totals, and addresses to the request.
- Read the payment state. Confirm the payment was captured, identify the connected provider, and calculate the remaining refundable amount after earlier refunds.
- Choose the right scope. Decide whether the adjustment belongs to the whole order or to specific item quantities. Use the platform flow that preserves the allocation your reporting requires.
- Account for shipping, tax, and discounts. Do not assume an order-level amount will distribute these values the way an item-level refund does.
- Read fulfillment separately. Determine whether goods are unfulfilled, shipped, delivered, returned, or still expected to ship.
- Record the reason. Use a concise note that explains the approved adjustment without placing sensitive customer data in an unnecessary field.
- Review provider constraints. Confirm destination, balance, payment-method, timing, and cancellation rules with the connected processor.
Stripe’s refund documentation illustrates why the provider check matters. Stripe supports full and partial refunds up to the captured amount, generally sends funds back to the original payment method, and can place a refund in pending, failed, or action-required states depending on the payment method and account conditions. Those details describe Stripe, not every provider Runner can connect.
Why refund and fulfillment stay separate
A refund answers a money question: how much of the captured payment should be returned? Fulfillment answers a goods question: what has been prepared, shipped, delivered, canceled, or returned? One can change without the other.
Consider four common cases:
- A customer keeps a cosmetically damaged item and receives a partial refund. Fulfillment remains delivered.
- A merchant refunds shipping after a late delivery. No product quantity returns to inventory.
- An unshipped order is refunded, but its fulfillment still needs cancellation so it is not packed later.
- One item is returned from a multi-item order. The refund, returned quantity, and inventory disposition all need compatible records.
Platform procedures reinforce this separation. Commerce7’s refund guide asks operators to choose quantities, inventory treatment, refund amounts, and payment tender, then handle fulfillment explicitly. Walmart Marketplace, by contrast, ties non-standard adjustments to individual items. Neither model should be assumed for another system.
Runner’s Orders page displays Payment and Fulfillment as separate state groups for the same reason. The ecommerce customer support playbook also recommends giving an operator current order, payment, fulfillment, policy, and action context before a consequential refund decision.
What should you verify after submitting?
Treat submission as the start of verification, not proof that the customer already has the money.
- Wait for Runner to show success and reload the updated order.
- Confirm the refund entry, amount, remaining paid total, and current payment state.
- Check Activity for the recorded change before retrying a request that appeared slow or timed out.
- Reopen the order and verify fulfillment, shipment, cancellation, and inventory state separately.
- Use the payment provider’s refund status and reference when the customer asks when funds will appear.
Provider timing varies. Stripe says a card refund is typically visible approximately 5–10 business days later depending on the bank, but it can also appear as a reversal, fail, or require additional action. Do not turn that provider-specific estimate into a universal customer promise.
For a broader view of safe handoffs between support and operations, see AI-driven orders, returns, and workflows. Use it as an operating overview; use the current order and provider records for the actual refund decision.
Order-level refund FAQ
Is an order-level refund always a full refund?
No. “Order-level” describes the scope or allocation of the adjustment, while “full” and “partial” describe its amount. A merchant can issue a partial amount at the order level when the platform supports it.
Can an order-level refund include shipping or tax?
It can on some platforms, but the calculation and reporting treatment vary. Review how the commerce platform allocates shipping, tax, and discounts before submitting. If precise product-level reporting matters, an item-level workflow may be more appropriate.
Does refunding an order cancel fulfillment?
Not necessarily. Payment and fulfillment are separate states. A refunded order can still contain an active or completed fulfillment, so verify whether packing, shipment, delivery, cancellation, return, or inventory work remains.
How long does an order-level refund take?
The commerce platform can record the request quickly, but customer-visible timing depends on the payment provider, payment method, bank, and refund status. Check the connected provider rather than promising one universal timeframe.
Is a refund the same as canceling a payment?
No. A refund generally returns money after a payment succeeds. An eligible uncaptured payment may instead be canceled before capture. The available action depends on the payment state and provider.
Make the refund and fulfillment decisions explicit
Before acting, write down the approved amount, reason, payment, item scope, fulfillment consequence, and expected provider state. In Runner, open the order, review Payment and Fulfillment separately, submit the eligible refund once, and confirm the updated record before any retry. That leaves the customer, money, and goods in states the operator can explain.