Partial refunds: an operations checklist for merchants

Establish the commercial decision first

Document the item or service adjustment, the original order and the approved refund amount. Separate the decision that a refund is appropriate from the technical act of submitting it. In the example, one item in a three-item order is unavailable, so staff need an approved adjustment rather than an arbitrary percentage of the original payment. Record who approved the decision and what the customer has been told. Your business's contractual and legal obligations require their own appropriate assessment; an API integration does not decide those obligations for you.

Refund workflow

Check the original payment and previous operations

Find the verified original transaction and inspect its currency, current status and refund history. Confirm which provider and account processed it. Do not use a customer screenshot as the sole basis for initiating a refund, and do not assume an open order implies a refundable payment. Earlier partial refunds or unresolved requests may affect what can safely be requested next. Where the system exposes separate processing and order currencies, check the supported refund boundary explicitly. If the record is incomplete or inconsistent, resolve that uncertainty before sending another financial instruction.

Payment webhooks

Create a traceable refund request

Give the refund operation its own internal reference while retaining its link to the original payment and order adjustment. Store the requested amount, currency, reason category and responsible operator in the appropriate internal record. Avoid putting unnecessary customer details into public descriptions or technical logs. If the API supports idempotency for the relevant operation, follow its documented contract. The request record should remain identifiable even if the network response is delayed. This makes it possible to investigate what was submitted without guessing from a later change in the order total.

Treat submission and completion separately

A successful API response may describe acceptance of a refund request rather than every later financial outcome. Follow the documented statuses and verified notifications for the integration you use. Keep the customer-facing message accurate about what the business has initiated and what remains pending, without promising a bank arrival time the system cannot guarantee. If a request times out, inspect the existing operation before creating another one. A repeat button should not become an uncontrolled second refund merely because the first response was not visible to the employee.

• Check the payment reference and eligible provider.
• Review earlier refunds and unresolved requests.
• Keep an independent refund operation reference.
• Confirm the final supported status before closing the case.

Reconcile the order after the refund

Update the order's commercial record and the payment history without deleting the original successful transaction. The record should explain the initial payment, the partial adjustment and the remaining amount. Reconciliation must use the relevant currencies and provider records rather than treating a refund as an unrelated negative sale. Give support a clear view of what happened so a later enquiry does not restart the whole investigation. If the operational and provider records disagree, retain the discrepancy as an open task with an owner instead of editing one side until the figures appear to match.

Confirm OrsunPay availability before designing around it

OrsunPay's current refund execution scope covers eligible Stripe payments where order and processing currencies match, and requires deployment activation. Other provider refund execution and merchant-cabinet refund controls are separate roadmap work. These limits should appear in the implementation plan and operator instructions. A team that needs a broader refund matrix should confirm the required scope before launch. Use signed updates and transaction status to track the supported workflow, while keeping provider processing and settlement responsibilities distinct from OrsunPay's software role and separately invoiced fee.

Sources

• Stripe — Payments
• Stripe — Webhooks