Short answer
A sound refund process starts before the first payment: clear public terms, reliable lookup of the original transaction, amount controls, final-status tracking and reconciliation.
- Publish clear refund terms before accepting payment.
- Always link a refund to the original payment.
- Distinguish a customer request, created refund and final result.
- Include refunds in daily reconciliation.
1. Website refund policy
Before paying, a customer should understand when a refund is available, where to submit a request, what information is required and how partial or disputed cases are handled. The policy should match the actual service, contract and applicable law.
Support contacts, seller details and service terms should be consistent across checkout, public terms and the merchant application. Contradictions create customer friction and complicate onboarding review.
- show support channels and working hours;
- describe eligibility and review stages;
- separate order cancellation from refunding a completed payment;
- do not promise timing that the payment setup cannot confirm.
2. Processing a request
Support identifies the customer and order without requesting unnecessary payment data. The team then checks the final status of the original transaction, available refundable amount and the merchant-policy basis. The decision and its owner are recorded.
The technical system creates a refund transaction with its own identifier and a reference to the original payment. The command should be idempotent so a network retry cannot produce a duplicate refund.
- never request full card credentials;
- validate the remaining partial-refund balance;
- use a unique operation key;
- record the reason and supporting evidence.
3. Statuses and communication
Creating a request does not mean that the refund is complete. The system should distinguish processing, final success and error states. The exact status model depends on the payment method and documentation.
Customer communication should reflect the confirmed result in plain language. An internal technical status should not be presented as money already received. If timing depends on a bank or payment method, explain that without unsupported promises.
- update the order only from a confirmed event;
- handle duplicate notifications safely;
- retain customer communication history;
- escalate delayed or disputed cases under a defined process.
4. Control and reconciliation
Refunds should appear separately from sales in operational reporting and financial reconciliation. Monitor refund value, repeated attempts, unresolved errors and cases where support closed a ticket before the final status.
Within WHITECAPITAL infrastructure, refund rules and available operations depend on the approved method, contract and banking setup. The merchant completes onboarding before launch, and the actual process is documented for the integration.
- match each refund to the original payment;
- prevent refunds above the paid amount;
- define internal support response targets;
- review failure reasons regularly.
Questions and answers
Are partial refunds available?
Availability depends on the payment method and approved setup. Where supported, the system must track the amount already refunded.
When is a refund complete?
Only after a final successful result is received from the payment flow, not immediately after request creation.
What customer data is needed?
Use enough information to find the order and verify the requester. Full payment-instrument credentials should not be requested.
Sources and policies
We use official payment-system information and WHITECAPITAL policies. Contractual documents prevail for an individual merchant setup.
This material is for operational orientation and is not a promise of approval, universal method availability, a fixed fee or settlement timing.