Managing partial refunds without duplicate transactions

Before issuing a partial refund, check the original payment’s provider transaction record for refunds already submitted. Check it again before retrying: a timeout or missing response does not establish that the request failed.

A duplicate is the same adjustment submitted more than once against the same original payment. A later refund for a separate adjustment is not a duplicate.

Calculate before submitting

Calculate the remaining refundable amount as the amount paid minus refunds already issued, and keep cumulative refunds at or below the amount paid. Check discounts, tax treatment and delivery charges before setting the refund amount.

Azupay’s example shows a $3 transaction with a $1.50 refund already processed, leaving a $1.50 refund balance. A refund greater than that remaining balance will not succeed.

Square allows full, partial or itemised refunds. Account owners or team members with the transactions permission can issue them, and permissions are set in Square Dashboard.

In Square, go to Transactions and select the original payment before starting another request. A Square refund cannot be cancelled, so verify the payment, amount and reason before submitting.

Square has no limit on the number of refunds, so do not rely on a refund-count limit to prevent duplicates. Submit once, then check the provider record before retrying if the request does not appear to have completed.

Where a refund API supports idempotency keys, create a unique key for each separate adjustment before sending the request. Reuse that key only for retries of the same adjustment; use a new key for a later adjustment.

Keep a refund register alongside the payment record, noting each submitted amount, reason, provider status and idempotency key when used. Check the provider status before retrying, and do not submit the same adjustment again while it is still in progress.

Azupay marks a refund in progress as RETURN_IN_PROGRESS, then changes it to RETURN_COMPLETE if successful or RETURN_REJECTED if unsuccessful. It does not allow another refund while the first is RETURN_IN_PROGRESS, so wait for a completed or rejected status before deciding whether another submission is needed.

For a genuinely later adjustment, wait for the earlier request to resolve and recalculate the remaining amount from the provider record. Choose an itemised refund or a specific amount, as appropriate, and select a reason.

Check the customer and ledger view

Confirm the amount initiated and payment method in the provider record; split tender may create more than one movement. Use the provider’s status to distinguish an in-progress refund from one that has completed.

Tell the customer factually whether the refund has been initiated or processed according to the provider. Bank posting can take additional time.