A refund and a return are two different jobs.

Separate the records

A refund concerns the payment. A return concerns the goods. Restocking concerns inventory. These events may happen together, but they need separate decisions and evidence. A refund does not mean the item is back on a shelf.

Write a policy your team can actually follow, including how customers request help and what information the team needs. Product-specific and jurisdictional obligations require appropriate review; a software default is not your final policy.

Walk through a partial case

Suppose an order contains five units and one line needs a partial refund. Record which amount was refunded, whether anything is expected back and whether returned goods may be resold under your process. Do not automatically add a unit to available stock just because money moved.

If a provider action fails or times out, check its status before retrying. Duplicating a refund is not an acceptable way to resolve an uncertain screen.

• Keep the original order and payment references.
• Separate requested, approved and completed actions.
• Reconcile discounts and shipping when calculating amounts.
• Tell the customer what happened and what remains pending.

Check support for your processor

Refund capability can differ by provider and account configuration. Verify the exact method your store uses, not merely a generic “refunds supported” feature label.

Torva’s in-platform refund coverage requires provider-specific verification. Ask about your processor before moving a business-critical workflow; do not assume all adapters offer identical actions.