Open Banking & Account Data · Use case

Add pay-by-bank checkout

Scope this use caseTalk to us

Short answer

Pay-by-bank starts an account-to-account payment from the customer's bank, authenticated in their banking app. It avoids card fees and chargebacks and settles fast on instant rails — the trade-offs are bank coverage, conversion in the redirect and how refunds work.

What this use case is

Pay-by-bank starts an account-to-account payment from the customer's bank, authenticated in their banking app. It avoids card fees and chargebacks and settles fast on instant rails — the trade-offs are bank coverage, conversion in the redirect and how refunds work.

Who builds this

E-commerce
Bill payments
Subscription and account top-ups
Travel
High-ticket merchants

What your customer sees

  1. 1Chooses "Pay by bank"
  2. 2Picks their bank
  3. 3Approves in the banking app
  4. 4Returns to a confirmation

How Open Banking & Account Data solves it

1

Customer selects pay-by-bank

Customer selects pay-by-bank

2

Bank chosen and payment details pre-filled

Bank chosen and payment details pre-filled

3

Customer authenticates with their bank

Customer authenticates with their bank

4

Payment initiated on instant or standard rails

Payment initiated on instant or standard rails

5

Status returned to your checkout

Status returned to your checkout

6

Funds settled; refunds initiated separately

Funds settled; refunds initiated separately

Want to have

  1. Bank coverage in your markets
  2. Instant payment support
  3. Reliable status updates
  4. Refund handling
  5. Checkout components
  6. Reconciliation data

Optional

  1. Variable recurring payments
  2. Stored bank preference for returning customers
  3. QR flows for desktop to mobile

Design decisions

Settlement

Direct to your account
Via the provider's account

simplicity versus reconciliation and fees.

Positioning

Alongside cards
As default

conversion versus cost savings.

What to put in your RFP

Coverage

  • banks
  • markets
  • instant availability

Checkout

  • flows
  • redirects
  • mobile handling

Operations

  • status
  • refunds
  • reconciliation

Commercials

  • per payment pricing
Add these to an RFP

How to evaluate providers for this use case

  1. 1Conversion per bank
  2. 2Status reliability
  3. 3Refund experience
  4. 4Cost versus cards

Pitfalls

  • Pushing pay-by-bank where coverage is thin
  • No refund process
  • Unclear status leading to duplicate payments

What providers will ask you

  1. Markets
  2. Payment volumes and ticket size
  3. Current card costs

Other Finlane categories that cover parts of this

This use case is solved mainly with Open Banking & Account Data. These categories cover specific parts of it and can be tendered alongside it.

Payment Processing & Acquiring

Card acceptance alongside pay-by-bank

Fraud & AML Monitoring

Risk checks on account-to-account payments

Banking-as-a-Service

Receiving accounts and instant settlement

Frequently asked questions

Other Open Banking & Account Data use cases

Verify income and affordability

Aggregate salary, expenses and balances across a user's accounts to power credit or KYC decisioning.

Automate accounting and reconciliation

Pull transactions and balances into an accounting or FP&A product, categorised and enriched.

Power personal finance and budgeting apps

Give users a unified view of their bank, card and loan accounts with enriched merchant data.

Scope add pay-by-bank checkout with Open Banking & Account Data providers

Scope this use case