Do Payment Processors Charge for Failed Payments and Refunds?

A customer gets their money back. The merchant may still pay for the payment that took it in, and sometimes for the instruction that sent it back. Equally, an attempt that never became a sale may still create a billable request. Those outcomes are easy to miss if finance counts only successful captures.

The right question is not “does this processor charge for refunds?” It is which event did the contract bill, which original fees stayed with the processor, and which new fees arose? The answer differs by provider, pricing plan, payment method and currency path. This reference is about that fee ledger. For the steps to issue and reconcile a refund, use the refund operations runbook.

Start with the payment event

An authorization request, a risk or issuer decline, a cancellation before capture, a successful capture and a refund after capture are different events. Their charges should not be collapsed into one “transaction fee.” Adyen's invoice guide says its processing fee applies when it receives a payment or refund request. It separately explains authorization fees for payments that do not reach capture, including canceled, expired and refused cases. That is evidence that a failed sale can still generate processor costs; it is not a universal tariff for every Adyen contract.

Checkout.com says its processing fee applies even to payments declined by its risk system. Fraud Detection Pro may add a separate Risk Engine Fixed Fee. Its payment-action guide lists fee types against authorization, capture, refund and void. It gives possible billing categories, not a price card proving that every merchant pays every listed fee.

The cells are deliberately uneven. Public documentation does not establish one provider-wide fee rate for all merchants, and a missing published fee is unknown, not zero. For a like-for-like quote comparison, see the Stripe, Adyen and Checkout.com pricing guide.

A refunded payment has three different amounts

The customer's principal is the amount sent back. The original processing fee is what the merchant paid to take the payment. A new refund fee, if the agreement provides one, is charged for the return instruction. Confusing these makes a refund look costless in a customer ledger even when the merchant's fee ledger has a loss.

Stripe's refund-fee explanation states that original payment-processing, Connect and currency-conversion fees are not returned. On its standard pricing, most payment methods other than some bank transfers do not have a separate fee for issuing a refund. Under IC+ pricing, the refund-issuance fee depends on the merchant's schedule. Thus “no new refund fee” and “the original fee was returned” are different claims.

For a deliberately illustrative USD 100 sale, assume a USD 3 original processing fee under a hypothetical contract. The customer receives a full USD 100 refund. If the contract retains the USD 3 and imposes no new refund fee, the merchant's payment-fee cost is USD 3. If a separately contracted USD 0.50 refund fee also applies, it becomes USD 3.50. These are arithmetic assumptions, not a quotation of any provider's rate. They also exclude goods, fraud and dispute costs. For a USD 40 partial refund, the customer gets USD 40 back; whether any original fee is returned, or a new fee is added, requires the fee schedule and transaction record. Do not automatically allocate 40% of the original fee to that refund.

The principal matters to cash reconciliation, but it is not itself a processing fee. Reconcile the gross original payment, the original fees, each refund principal and each new fee as separate entries. On a marketplace, a platform application fee is another distinct ledger item; a customer's refund does not by itself prove that the platform fee was reversed.

Currency conversion can create another retained cost

Refunding in a different currency adds a separate question. Checkout.com's FX terms say that when it processes a refund involving currency conversion, an FX fee is charged and the FX fee on the original transaction is not returned. The page directs merchants whose agreement predates 4 September 2023 to their contract. That is a specific Checkout.com rule with a contract caveat, not evidence that every provider charges FX twice on every refund.

Record the original transaction and refund currencies, both conversion rates, and the currency in which fees settled. A shopper's full refund in purchase currency may coexist with a different amount in the merchant's settlement currency. Keep that difference apart from processor fees until the FX records explain it.

Questions for the fee schedule and statement

Ask each prospective PSP or acquirer for the chargeable event and rate for a refused authorization, a processor risk decline, an expiry and a void. Ask whether each is billed once per attempt or per resulting payment. Then ask which original fees are retained on a full or partial refund and whether issuing that refund creates a new gateway, processing, scheme, reconciliation or FX charge. Include minimums, monthly fees, and the treatment of a retry that generates another request.

Finally, request sample statement lines for a decline, a void, a capture and a partial refund using the same merchant profile. Match them to the processor's event IDs. That exercise exposes differences that a headline merchant discount rate cannot show. For the full statement decomposition, use the MDR stack guide; for chargebacks, which follow a separate process and cost model, use the chargeback unit-economics reference.