Refunds
Follow a refund from the original payment to its outcome
Handle full or partial refunds from the original payment and follow their progress.
Follow money returned against the original payment
- The original payment
Start from the payment and keep the refund tied to the right order.
- Choose the amount
Record a full or partial refund according to the amount still refundable.
- Follow the outcome
Read refund status and history; gateway execution depends on the configured provider.
Start with the amount still refundable
Open the original payment before requesting a refund. Full or partial amounts stay linked to the same order, with the refundable balance providing the context for how much may still be returned.
Read the refund's state and history after the action. A request, an in-progress operation and a finished refund are different outcomes; an unanswered provider call must not be treated as money successfully returned.
Know what is still refundable
The original payment. Review the amount paid and its order before requesting reimbursement. The refund stays attached to that payment’s context.
Full or partial amounts. Use the available refundable balance to choose the amount. Already completed or in-progress refunds must not be treated as freely available again.
Provider-dependent execution. Read whether the operation is recorded, in progress or completed. The configured gateway and its response determine the actual execution result.
Use the provider result as the reference
Execution depends on the supported gateway, configured account and available payment service. When the operation is recorded only or its outcome is uncertain, the record says so rather than proving that a bank transfer occurred.
Keep the customer conversation connected to the payment result. The return of an item can justify reviewing a refund, but its physical arrival does not itself establish that a payment provider completed reimbursement.
Follow a refund through its actual result
Check the balance first. Open the payment breakdown and prior refunds. For example, a pending refund reduces the amount available for another request.
Request the supported operation. Use the available refund action with the intended amount. Keep the customer’s return case linked without assuming it completes the financial step.
Confirm before informing the buyer. Re-read the state and history. An unanswered provider call is an uncertain outcome, not confirmation that the money was returned.
Handle after-sales money with a clear record
Keep each refund connected to its payment, remaining amount and actual outcome.
Questions about Refunds
Yes. The workflow supports partial or full amounts within the amount still refundable.
To its original payment and the order context behind it.
No. Consult the resulting state and provider outcome.
Execution depends on the supported provider and payment service; recorded-only handling is identified when applicable.
Read the history and follow the correction or verification workflow, rather than assuming success or sending again blindly.
No. The refund and its payment outcome must be checked separately.