Solidgate logo in black and white.

Refund authorization

What is refund authorization?

Refund authorization is a process where a verifies a cardholder's account before issuing a . Similar to purchase authorization but in reverse, the checks with the to confirm the account can receive the funds.
The check runs before the refund is submitted for clearing, so the merchant finds out straight away whether the account is still open and able to accept a credit. An approval means the issuer will post the funds. A decline stops the refund while it can still be handled another way, instead of after the money has left the merchant account. Whether a refund has to be authorized before submission varies by card network and region, so acquirers configure the behavior per scheme and market.

Key facts

  • Also known as: refund auth
  • Direction of funds: merchant to cardholder, the reverse of a purchase
  • Who checks what: the routes the request through the card network to the issuer, which confirms the account can receive a credit
  • Possible outcomes: approved, and the refund moves on to clearing, or declined, with a carrying the reason
  • Applies to: refunds sent back to the original card; requirements on when authorization is mandatory vary by scheme and region

How it works

  1. Merchant initiates the refund. The refund is raised against the original transaction, in full or in part.
  2. Processor builds the refund authorization request. The request carries the card credentials, amount, currency, and a reference to the original authorization.
  3. Card network routes it to the issuer. The network passes the request to the bank that holds the cardholder's account.
  4. Issuer responds. It confirms the account exists, is open, and can accept a credit, then returns an approval or a decline code.
  5. Refund moves to clearing. On approval the refund goes into clearing and settlement, and the funds post to the cardholder's account on the issuer's own schedule.

Why it matters

  • Refunds addressed to closed, blocked, or invalid accounts stop before the merchant releases anything, so funds don't leave the merchant account for a credit the issuer can't post.
  • A decline arrives while the refund is still in the merchant's hands, so it can be reissued to another method under the merchant's refund policy rather than being chased after the fact.
  • The approval response is a dated record that the issuer accepted the credit. That record is the evidence a merchant uses when a cardholder later files a claiming a promised refund never arrived.
  • The refund carries a status from the moment it is raised, so support and finance teams can answer "where is my refund" from the authorization response instead of waiting for settlement files.

Common issues

  • Closed or expired card. The account behind the original payment no longer accepts credits, the refund is declined, and the money has to reach the cardholder another way.
  • Generic decline reasons. The issuer returns a broad response rather than a specific cause, and the decline code is the only diagnostic signal available.
  • Amount mismatches. When the captured amount differs from the original authorized amount, a refund request built on the original figure can be rejected.
  • Scheme and region differences. Because the requirement isn't uniform across networks and markets, the same refund flow behaves differently depending on the acquirer and the cardholder's issuer.
  • Approval is not arrival. An approval confirms the issuer accepts the credit, not that the cardholder can see it. Posting to the account follows the issuer's timetable.

Related terms