Refund rules belong to the payment model
Stripe’s current documentation says stablecoin payments settle in local currency, with the applicable currency dependent on the current product and merchant region. USD presentment must not be confused with settlement currency. Refunds return as stablecoins to the customer's original wallet.[1] That is a provider-specific rule, not a universal property of stablecoins or PayIn. Before publishing a policy, confirm the refund capabilities of the actual integration and the markets where you operate. This guide is an operational framework, not legal advice or a statement that PayIn currently offers an automated refund endpoint.
Separate entitlement from execution
A commercial decision answers whether the customer is entitled to a refund and how much is owed. A payment operation answers how that amount will be returned. Keep those decisions separate so support staff do not approve an irreversible transfer merely to close a ticket. Our recommendation is to record the original order, original payment, reason, approved amount, denomination, approver and execution status. Store a refund record as a new event; do not rewrite the original payment as though it never happened.
Resolve amount and destination explicitly
State whether the obligation is measured in invoice currency or token units and how any conversion or fees are handled, subject to the applicable contract and law. Do not promise a universal fee or assume a peg will make every amount interchangeable. For a provider-managed refund, follow its documented destination rules. For merchant-controlled transfers, validate destination ownership through an appropriate process and require review of changes. A new wallet address sent in a support message is not, by itself, sufficient authorization.
Handle partial refunds and uncertain outcomes
For each order, track the approved and completed refund totals against the refundable amount. Prevent two operators from approving the same remaining balance at once. If execution times out or the result is unknown, investigate the existing operation before sending another transfer. PayIn’s reconciliation guide emphasizes matching references and identifying manual support changes.[7] Apply that discipline to refunds by retaining both the approval record and the eventual provider reference or transaction evidence. Pending and failed are different states.
A release checklist for support and finance
Before enabling sales, publish customer-facing instructions that explain how to request a refund without sharing secrets, what information support needs and where status will be communicated. Internally, test partial approval, duplicate requests, an altered destination and a payment operation with an unknown outcome. Define who may authorize exceptions and who reconciles the result. These are recommended controls, not reports of field experience. Recheck provider rules and jurisdictional requirements before using the policy in a new market.
Sources & currency
Continue reading
Reconcile the order, the transfer and the business result →
All field guides →