Pay by Bank Refunds: How EU Merchants Handle Returns

Merchants add pay by bank at checkout for lower fees and strong payer authentication — then discover returns season works differently. Pay by bank refunds send money back to the customer's bank account, not the card they never used. Without a verified IBAN, clear timing copy, and webhook-driven status, support queues fill with "where is my refund?" tickets that card rails handled invisibly. This guide covers how refund flows work on bank rails, when to verify payee details before payout, partial and failed refund handling, and what to validate with providers before your first return.

Pay by bank refunds: Returning money to a customer after a bank-initiated checkout payment — usually by sending a credit transfer to the IBAN that paid the order, or another verified account the customer confirms — instead of reversing a card authorisation through an acquirer.

For how pay by bank works at checkout, start with pay by bank explained. For fees, chargebacks, and when bank rails beat cards, see pay by bank vs cards at checkout.

How do pay by bank refunds work?

After you approve a return, your payment provider initiates an outbound credit transfer to the customer's bank account — typically the IBAN that funded the original payment. The customer sees funds arrive in their banking app; there is no card network reversal.

The operational sequence:

1. Return authorised — your OMS or support tool marks the order eligible for refund (full or partial).
2. Destination account confirmed — refund-to-original-IBAN when your provider stores payer account data from the checkout webhook; otherwise collect and verify IBAN manually or via account verification.
3. Payout initiated — provider API creates an outbound payment with amount, reference, and creditor name your customer will recognise on the bank statement.
4. Status tracked — webhooks report accepted, pending, failed, or rejected; customer email triggers on terminal success even if they never revisit your site.
5. Ledger updated — finance closes the return line when the outbound payment settles, not when support clicks "refund" in admin.

Most EU implementations route refunds through the same licensed payment initiation or payout API the merchant used for collection. You do not need a separate banking relationship with every payer institution — your provider handles ASPSP connectivity.

According to Open Banking Limited, open banking payments in the UK passed one billion cumulative transactions by mid-2026. As checkout volume grows, refund volume follows — ops teams that designed only for card reversals feel the gap first.

Why are pay by bank refunds different from card refunds?

Card refunds reverse through acquirer and scheme paths customers already understand; bank refunds are push payments that need a correct IBAN and honest timing copy. Chargeback reason codes do not apply.

Dimension	Card refund	Pay by bank refund
Destination	Same card automatically	Bank account — usually original payer IBAN
Customer expectation	"Refund to my card" in 3–10 days	"Refund to my bank" — timing varies by rail
Dispute path	Chargeback / scheme rules	Bank complaint channels — different ops playbook
Partial refunds	Acquirer supports partial reversal	Provider must support partial outbound amount
Failed destination	Rare (card still valid)	Wrong IBAN, closed account, name mismatch

Teams migrating high-return categories — fashion, travel, marketplaces — should budget support training before scaling bank checkout share. A customer who paid by bank but expects card-style instant reversal will contact support even when the refund is processing correctly.

For marketplace-specific buyer protection copy, see pay by bank marketplace checkout. Conversion work that reduces mistaken purchases also lowers refund load — see pay by bank checkout conversion.

When should you verify the customer's IBAN before refunding?

Verify IBAN before every refund when you did not store payer account data from the original checkout webhook, the customer requests refund to a different account, or your risk rules flag third-party payers. Wrong-IBAN payouts are expensive to recover.

Refund-to-original-account (preferred)

When checkout webhooks captured payer IBAN and your provider supports refund-to-source, route returns to that account automatically. This matches customer mental models ("money goes back where it came from") and removes manual data entry.

Refund to a new IBAN

Some returns require a different account — joint accounts, business payers, or gifts. Collect IBAN through a secure form and run verification of payee or equivalent name-matching before initiating payout. A "no match" result should block automatic refund and route to manual review.

High-risk patterns

• Third-party payer — payer IBAN does not match account holder name on the order; flag before outbound transfer.
• High-value B2B returns — finance may require written confirmation of destination IBAN.
• Cross-border EUR/GBP — confirm currency and corridor; do not assume SEPA rules apply to every pair.

Treat IBAN verification as part of refund SLAs, not an optional fraud extra. Insurance and marketplace teams already know wrong-IBAN cost from payout operations — checkout refunds inherit the same discipline.

What provider features matter for refund operations?

Shortlist providers on outbound payout APIs, refund-to-source support, webhook granularity for failed payouts, and sandbox fidelity — not just inbound checkout conversion rates.

Criterion	Refund-specific question
Refund-to-source	Can you refund to the payer IBAN captured at checkout without re-collecting details?
Partial amounts	Does the API accept arbitrary partial refund amounts tied to order line IDs?
Payout speed	Standard SCT vs SEPA Instant — what do you promise in customer email templates?
Failed payout handling	Webhook reason codes for invalid IBAN, closed account, or limit exceeded?
Creditor name on statement	Will the customer recognise your legal entity on the inbound credit?
Multi-currency	GBP and EUR refunds from one dashboard or separate integrations?
Reporting	Can finance export outbound payments matched to original payment IDs?

Run sandbox tests for the failure paths — invalid IBAN, amount exceeding original payment, duplicate refund requests — before Black Friday or end-of-quarter return peaks. Inbound checkout sandboxes that work perfectly still break ops when outbound refunds fail silently.

When you are ready to compare providers on payout and refund capabilities for your markets, use the provider-matching form to share return volumes, countries, and ERP constraints — or start from how to choose an open banking provider in the EU.

How do timing and customer communication affect refund satisfaction?

State realistic arrival windows per rail and country — SEPA Instant where both banks support it can land in seconds; standard credit transfer may take a business day. Overpromising "instant refund" in markets without instant settlement creates NPS damage.

Copy that reduces tickets

• Email on initiation — "We have sent €X to the bank account ending ****1234. Most banks show this within [timeframe]."
• Email on webhook success — confirmation even if the customer never opens your returns portal again.
• Email on failure — clear next step ("We could not send to this IBAN — update your details here") instead of generic "processing."

Partial refunds

E-commerce platforms refund shipping, restocking fees, or individual line items. Confirm your provider accepts partial outbound amounts and that your OMS passes the exact figure — silent rounding to the nearest cent creates finance exceptions.

Refund pending vs order cancelled

Customers conflate "order cancelled" with "money returned." Separate status in your UI: return approved, refund initiated, refund completed. Support macros should mirror those three states.

The European Payments Council continues to drive SEPA Instant adoption; availability still varies by bank pair. Product copy should name the rail you actually use, not generic "instant bank refund" unless your provider confirms instant settlement for that payer bank.

How do you roll out pay by bank refunds without overloading support?

Pilot refunds on a low-volume SKU or single market, measure ticket rate per 100 returns, then expand bank checkout share. Train support on bank-rail timing before marketing pay by bank as a card replacement.

Rollout checklist:

1. Document refund SLAs by country and rail (standard vs instant).
2. Automate refund-to-source where webhooks stored payer IBAN.
3. Integrate VoP or IBAN validation for manual refund forms.
4. Build admin retry for failed outbound payments without duplicate customer credits.
5. Reconcile outbound payments to original payment IDs in your ledger — finance should not hunt two systems.
6. Update returns policy page — bank refunds differ from card; legal review before publishing timing claims.

Teams running pay by bank invoice payment for B2B collections often reuse the same payout API for credit notes — unify inbound and outbound provider contracts where possible to simplify reconciliation.

High-return verticals should compare refund cost per rail, not just checkout cost. A lower acquisition fee loses margin if every return requires a 15-minute support call to collect IBAN details.

Frequently Asked Questions

What is a pay by bank refund?

A pay by bank refund returns money to a customer's bank account after they paid via account-to-account checkout — typically by sending a credit transfer to the IBAN that funded the order. It is not a card reversal because no card was charged.

How long do pay by bank refunds take?

Timing depends on the payout rail and banks involved. SEPA Instant transfers can arrive within seconds when both banks support instant credit transfer. Standard SEPA or domestic transfers may take one business day or longer. Merchants should state realistic windows in customer emails rather than promising instant refunds in every market.

Can I refund to a different bank account than the one that paid?

Yes, but you should verify the new IBAN before sending money. Refunding to the original payer account is safest when your provider captured that IBAN at checkout. Refunding to a different account requires customer confirmation and name-matching checks to prevent wrong-IBAN payouts.

Are pay by bank refunds the same as chargebacks?

No. Chargebacks are card-network dispute processes with reason codes and acquirer timelines. Pay by bank refunds are merchant-initiated outbound bank transfers after a return is approved. Customers can still complain through bank channels, but the operational workflow is closer to treasury payouts than card dispute management.

Do I need customer IBAN details to process a pay by bank refund?

If your provider stored payer account data from the original checkout payment and supports refund-to-source, you may not need to ask again. If not, you must collect and verify IBAN before payout — manual collection increases support load and wrong-account risk.

Can providers handle partial pay by bank refunds?

Many payment initiation providers support partial outbound amounts via API, but you must confirm this in sandbox before launch. Your order management system must pass the exact partial figure; rounding errors create finance reconciliation gaps.

How do pay by bank refunds work for marketplaces?

Marketplaces may need to refund buyers while separately clawing back seller payouts. Buyer refunds follow the same bank-rail rules; seller-side recovery is a ledger operation distinct from the customer credit. See open banking for marketplaces for two-sided payout context.

Conclusion

Pay by bank refunds are push payments to verified bank accounts — not invisible card reversals. Teams that capture payer IBAN at checkout, automate refund-to-source, verify new accounts before payout, and set honest timing copy keep support load manageable as bank checkout share grows. Before scaling returns season on bank rails, validate outbound APIs and failure webhooks with your provider in sandbox — inbound checkout success is only half the operational story.