Pay by Bank Payment Links: Hosted Checkout Without Card Fields

Payments teams add pay by bank payment links when customers are not inside a logged-in checkout — dunning emails, SMS reminders, in-store QR codes, or partner portals — but still need a guided bank-app approval with the right amount and reference. A hosted link opens a short session: select bank, authenticate in the banking app, confirm, return. You receive status through webhooks instead of hoping the payer copied IBAN details correctly. This guide covers when links beat embedded checkout, how the payer journey works, security and expiry patterns, reconciliation, and what to validate with providers before you scale link-based collection.

Pay by bank payment links: Secure hosted URLs that start a one-off account-to-account payment — amount, payee, and reference pre-filled — so the customer approves the transfer in their banking app without entering card details or manually typing IBAN data offline.

For the core rail definition and checkout trade-offs, start with pay by bank explained. For B2B invoice-specific copy and ERP matching, see pay by bank invoice payment.

When should you use pay by bank payment links instead of embedded checkout?

Use pay by bank payment links when the payer starts outside your app — email, SMS, printed QR, or a third-party portal — and you still need structured bank approval with pre-filled payment data.

Strong fits:

• Payment recovery and dunning — one-off collection after a failed renewal or missed invoice without asking for a new card (open banking recurring dunning patterns)
• Field sales and events — QR on a receipt or stand that opens mobile bank pay without POS hardware
• Marketplace or platform payouts to sellers — seller pays a fee via link from a notification (pay by bank marketplace context)
• Guest or low-login journeys — tourism, utilities, or telco bills where the customer will not create an account first
• B2B approval chains — finance approver receives a link; amount and creditor reference are locked before bank redirect

Stay on embedded checkout when the customer is already in your cart, mobile conversion depends on minimal steps, and you control the full UI — see open banking redirect vs embedded for mode trade-offs.

According to Open Banking Limited, UK open banking payment volumes passed one billion cumulative payments in 2026 — most growth still comes from one-off initiation, which makes hosted links a practical entry pattern before recurring mandates.

How does a pay by bank payment link work for the payer?

The payer taps the link, lands on a hosted or co-branded page, selects their bank, completes strong authentication in the banking app, confirms amount and payee, and returns while your backend receives final status via API webhook.

Typical sequence:

1. Link issued — unique URL in email, SMS, portal button, or QR encode; may include opaque token, not raw invoice IDs in the path.
2. Session opened — server validates token, loads amount, currency, creditor name, and reference fields the bank must display.
3. Bank selection — list filtered by country; domestic institutions first for consumer payers.
4. Redirect or app-to-app handoff — mobile users often deep-link into the banking app; desktop users use online banking.
5. Authentication and confirm — payer approves in the bank channel, not on your domain.
6. Return URL — success, pending, or failure screen; never treat browser return alone as settlement proof.
7. Webhook — your system marks the order, invoice, or recovery case paid when the provider sends a final status event.

Links differ from manual bank transfer instructions because the payer cannot easily mistype amount or reference. They differ from card payment links because there is no card entry and dispute economics follow bank rails — see pay by bank chargebacks for ops implications.

For drop-off patterns once bank pay is visible, apply the same UX discipline as pay by bank checkout conversion: show fees, settlement timing, and support paths before redirect.

What security and lifecycle rules should finance and product agree on?

Treat every pay by bank payment link as a short-lived payment intent — expiry, single-use tokens, amount immutability, and webhook-first confirmation reduce fraud and reconciliation exceptions.

Expiry and reuse

• Time-box links — 24–72 hours for dunning; shorter for high-value one-offs; align copy with expiry on the landing page.
• Single-use vs multi-open — decide whether a clicked-but-unpaid link can be reopened; single-use tokens limit forwarding abuse.
• Amount locks — prevent client-side tampering; server-side session is source of truth.

Fraud and social engineering

• Branded landing — clear merchant name matching what the bank displays; reduces APP-style confusion.
• Channel hygiene — send links only from domains customers already trust; avoid look-alike shorteners.
• High-value review — manual approval before link issuance for unusual amounts or new payers.

Operational confirmation

Signal	Use
Webhook accepted / settled	Trigger fulfilment, credit release, or dunning closure
Browser return only	Show thank-you or retry UI — not ledger posting
Pending	Hold shipment; message payer with expected settlement window
Failed / cancelled	Offer alternate rail or new link

Teams running pay by bank refunds should wire refund APIs before scaling link traffic — link checkout removes card chargebacks but not refund obligations.

How do pay by bank payment links fit a multi-rail checkout strategy?

Links are the lightweight rail for off-session collection; embedded or redirect checkout stays on-site for high-intent cart sessions — most merchants run both under one provider backend.

Scenario	Link	Embedded / redirect checkout
Dunning email after failed renewal	Primary	Secondary fallback
Logged-in e-commerce cart	Rare	Primary
In-store QR at counter	Primary	N/A
B2B invoice from ERP	Primary (see invoice spoke)	Optional portal embed
International buyer	Validate bank list first	Cards may still win

Trade press coverage of multi-rail strategies at Sibos 2026 (Finextra) emphasises interoperability across rails — for day-to-day product work, that translates to consistent webhook schemas and reconciliation keys across link and checkout flows, not forcing one UX everywhere.

Product marketing from infrastructure vendors describes link-based POS patterns (Token.io) — your evaluation should still stress institution coverage and webhook reliability rather than hardware narratives alone.

Which provider criteria matter for hosted pay-by-bank links?

Shortlist on link-session APIs, bank coverage for your payer countries, webhook fidelity, reference field support, and sandbox parity with production bank lists.

Criterion	Link-specific question
Session API	Can you create, expire, and revoke links programmatically?
Coverage	Do top payer banks in each market support initiation from hosted sessions?
References	Will remittance data appear verbatim on the bank confirmation screen?
Webhooks	Final status without relying on payer returning to your site?
QR / deep link	Mobile app-to-app handoff tested on iOS and Android?
Branding	Co-branded hosted page vs bring-your-own front-end with redirect
Recovery	Re-issue link on same invoice ID without duplicate settlement risk

Run sandbox tests with production-shaped amounts, currencies, and references. Test failure paths: payer cancels in bank app, insufficient funds, and bank maintenance during month-end.

When you need live coverage mapped to your payer markets and link volume assumptions, use the provider-matching form — or start from how to choose an open banking provider in the EU for baseline evaluation dimensions.

How do you roll out pay by bank payment links without hurting conversion?

Pilot on one recovery or notification channel, measure link-open to bank-approval rate, then expand — do not replace embedded checkout until link funnels prove stable.

Suggested rollout:

1. Pick one use case — e.g. dunning day+3 email with a single-use link and clear expiry.
2. Instrument funnel events — link open, bank selected, webhook accepted, webhook failed.
3. Align finance — reconciliation keys match ERP or billing IDs before marketing sends volume.
4. Add QR or SMS only after email metrics stabilise — each channel adds support load.
5. Keep card or manual transfer fallback until bank approval rates meet your threshold per market.

Document settlement timing on the landing page — instant schemes are not universal across every EU bank pair. Under-promise on speed; over-deliver on reference accuracy.

Frequently Asked Questions

What is a pay by bank payment link?

A pay by bank payment link is a secure URL that starts a hosted payment session where amount, payee, and reference are pre-filled. The customer selects their bank, authenticates in the banking app, and approves an account-to-account transfer without entering card details or copying IBAN data manually.

How is a pay by bank link different from a pay by bank invoice link?

Invoice links optimise for B2B structured references, ERP matching, and finance approval workflows. Generic pay by bank payment links serve the same hosted pattern for checkout recovery, SMS, QR, and guest flows — the rail is the same; the business rules and copy differ.

Can you use pay by bank payment links for in-store or POS?

Yes, when the link is encoded as a QR code the customer scans with a phone. There is no card terminal required; payment completes in the banking app. Coverage and mobile handoff quality vary by provider and bank — validate before replacing card-present flows.

Do pay by bank payment links expire?

Best practice is to expire links after a defined window and invalidate tokens after successful payment. Expiry reduces forwarded-link abuse and keeps dunning amounts aligned with current balances.

Should you mark an order paid when the customer returns from the bank app?

No. Treat provider webhooks as the source of truth for ledger updates. Browser return URLs improve payer experience but can arrive before final settlement or after a cancelled attempt.

Can pay by bank payment links work alongside embedded checkout?

Yes. Most teams use embedded or redirect checkout in the cart and hosted links for email, SMS, and QR recovery. One provider backend keeps webhooks and reconciliation consistent across both modes.

Conclusion

Pay by bank payment links give payments and product teams a low-friction way to collect off-session — dunning, notifications, QR, and guest flows — while keeping amount and reference discipline. The payer still authorises in the banking app; your ops win when webhooks, expiry rules, and reconciliation keys are designed before volume scales. Pilot one channel, measure bank-approval rate, and keep embedded checkout for high-intent cart sessions until link metrics prove out.