Trustly Guide: Practical Use of Open Banking Account-to-Account Payments
Account-to-account payments appear frequently in discussion, but material explaining how to actually use them is scarce. The principle is not complicated: on your checkout page the user picks their bank, is redirected to online banking to log in and authorise, and an open banking channel initiates a transfer from the user account to your account, with funds bypassing card schemes. It looks like a bank transfer, yet the authorisation and confirmation run through open banking, so the experience is entirely different from a plain transfer.
This guide follows Trustly to set out the practical use of open banking account-to-account payments. Trustly is an account-to-account payment provider built on open banking, where the user authorises inside their own online bank to complete the payment, covering several European markets. Once you understand the mechanism, you will see why its engineering focus sits on confirmation and refund paths rather than on a payment form. For the wider European picture see the Europe Local Payment Guide.
1. Positioning: Open Banking Account-to-Account, Not Card Acquiring or a Plain Transfer
1.1 The Mechanism: Authorisation, Confirmation and Settlement
An account-to-account payment runs in four steps. The first is bank selection: the user picks their bank on your checkout page and the page redirects to that bank login page. The second is authorisation: the user logs in and confirms the payment, which is an explicit instruction to their own bank and the biggest difference from a traditional debit collection. The third is confirmation: the open banking channel returns the result to the provider and the merchant, who decides whether the transaction exists. The fourth is settlement: funds arrive under the provider settlement arrangement, usually faster than cards but not the same as real time.
The step where things most often go wrong is the gap between the third and the fourth. The user has authorised, but the result may arrive late, may be lost, or may arrive before your return redirect lands. The system must therefore not treat the front-end redirect as proof of success; server-side state governs.
1.2 What It Is Not
First, it is not card acquiring. It handles no card numbers and does not use card scheme authorisation, so chargeback evidence methods barely apply.
Second, it is not a plain bank transfer. A plain transfer requires the user to type the beneficiary account details, whereas account-to-account completes authorisation and confirmation inside the user online bank, so the merchant never has to expose beneficiary details.
Third, it is not a local entity. Integrating a provider changes which interface you collect through, not which jurisdiction holds your entity, tax and invoicing obligations.
Fourth, it is not a risk-free instant payment. Confirmation depends on bank-side state and refunds require reverse transfers, so both need extra design.
2. Onboarding and Entity Requirements
2.1 Entity, Settlement Account and Business Model
Open banking onboarding looks at three things: which jurisdiction the entity sits in, whether the business model is clear, and where the settlement account is opened. Because funds move straight out of the user bank account, the reviewer expects more on business explainability and dispute handling: you must be able to state what you sell, how it is delivered and how problems are refunded.
Market coverage matters just as much. Open banking capability rests on each market open banking infrastructure and bank coverage, and the range of available banks differs widely. What to ask is not how many countries are covered, but whether your buyers commonly used banks are supported, and how confirmation latency and failures behave at those banks.
2.2 Compliance and User Consent
Account-to-account payments rely on an explicit authorisation to the user own bank, so how consent is obtained, recorded and withdrawn all have to be compliant. Page copy must clearly state that this is a payment charged directly from a bank account, not a subscription mandate and not a card payment. Confusing the three produces disputes and complaints.
One obligation is easily overlooked: the rules for handling open banking data. Even with payment consent, account information obtained during the payment should not be used for other purposes. For the wider framework see the Payment Data Export Compliance Guide, though the conclusion must land on the rules of the applicable market.
3. Integration Options and Account Structure
3.1 Integration Shapes and the Redirect Flow
Open banking integration is usually redirect based: the merchant calls the provider to create a payment, receives a redirect URL, sends the user to a bank selection page, and the user returns after authorising. Some providers also support app switching or a QR code on mobile for the same flow. Whatever the shape, the flow includes leaving your site, which means you must handle abandonment, failed returns and repeated returns.
Page design should set expectations: tell the user that they will be redirected to their own bank, that they need to log in, and that they will return automatically after authorising. Those few sentences noticeably reduce abandonment. For the basic structure of a payment flow see the Payment Transaction Flow Basics.
3.2 State Machine and Confirmation
This is the most important technical judgement in this guide. An account-to-account payment must not be assumed to succeed instantly. The user completing authorisation only means the instruction has been issued; whether funds arrive and whether the amount matches exactly depends on server-side state and bank-side confirmation. The state machine must therefore include initiated, redirecting, awaiting confirmation, succeeded, failed, expired, refunding and refunded, and must tolerate long stays in awaiting confirmation.
Three engineering tasks follow. First, use server-side state as the source of truth and treat the front-end redirect as experience polish only. Second, give the awaiting-confirmation state a sensible timeout plus active querying. Third, make amount matching a separate process, because the amount returned by the bank may differ from the order amount. For reconciliation and state synchronisation see the Payment Reconciliation and Bill Operations Guide.
4. Core Capabilities and Market Coverage
4.1 Coverage and the Boundary of the Method
Account-to-account payment is already a common choice in parts of Europe, especially markets with strong online banking habits. Its advantages are a short payment path, no card number and relatively fast arrival. Its boundary is equally clear: it requires the user to authorise inside online banking, so it is less smooth than one-click payment on mobile and limited in markets where online banking use is low.
Evaluation should therefore start from the buyer profile. If buyers concentrate in markets with high online banking use, order values are mid-range and settlement speed matters, account-to-account deserves priority. If buyers are dispersed, mostly mobile and used to cards or local wallets, it works better as a supplementary method.
4.2 Confirmation and Refund Path Comparison
| Dimension | Account-to-account | Card payment | Direct debit |
|---|---|---|---|
| Where authorisation happens | User authorises inside online banking | Merchant initiates, issuing bank authorises | User signs a standing mandate |
| Arrival confirmation | Depends on bank-side state and callbacks, never assume instant | Authorisation is immediate, capture and settlement are asynchronous | Each collection is submitted separately and returns asynchronously |
| Dispute model | Fewer disputes, reliance on authorisation records | Card scheme chargebacks with a defined evidence flow | User can request a return from the bank and the merchant supplies evidence |
| Refund path | Reverse transfer requiring beneficiary details | Return to source, usually fast | Reverse instruction through the direct debit system |
| Operational focus | State confirmation and amount matching | Authentication and chargeback evidence | Mandate lifecycle and retry strategy |
| Typical scenario | One-off payments in markets with high online banking use | The broadest general-purpose method | Subscriptions and recurring collection |
The table is worth using directly in solution reviews. The most underestimated item is the refund path: an account-to-account refund is essentially a reverse transfer that needs beneficiary details, so timing and experience differ from cards and both scripts and process must adapt. For refund and settlement operations see the Payment Refund and Settlement Operations Guide.
5. Fee Structure and Real Cost
5.1 Fee Components
| Fee component | Description | What to judge |
|---|---|---|
| Transaction processing | Charged per payment or by amount | Different from proportional card pricing, so model your order value mix first |
| Settlement and FX | Determined by settlement currency and funding path | Cross-border business needs separate assessment |
| Refund handling | Cost of executing reverse transfers | High refund rates must include this item |
| Integration and maintenance | State machine, reconciliation and support headcount | Handling the awaiting-confirmation state needs extra engineering |
| Method mix cost | Reconciling and coordinating alongside cards | Every extra method adds another state and rule set |
Current rates and conditions belong to the official quote and the signed contract. Any percentage in an article goes stale, and budgeting from old numbers is the easiest error to make.
5.2 Real Cost: Refund Operations and Conversion Structure
The account-to-account advantage usually shows up in the transaction itself, but real cost must be read across the full path. The first item is refund operations: reverse transfers need beneficiary details and are heavier than card returns to source, so high-refund businesses feel the difference clearly.
The second item is conversion structure. Account-to-account requires a redirect and a login, and some users abandon at that point, so making it the default can lower overall conversion. A steadier approach is to show account-to-account alongside cards and local wallets, let users choose, and use real data to set the order. For general success rate methodology see the Payment Success Rate Optimization Guide.
6. How It Divides Work With Other Options
6.1 Against Card Acquiring
Card acquiring has the widest coverage, familiar user behaviour and a mature retry path, making it the default fallback. Account-to-account can lower transaction cost and speed up settlement in specific markets but requires users to change habits. In practice the two sit side by side: cards cover every buyer, and account-to-account offers a more economical option where online banking habits are strong.
When evaluating, compare how Adyen, Stripe and Mollie structure local method support, then decide the position of account-to-account on your checkout page. Order and defaults should be driven by data, not by fee rates.
6.2 Against Direct Debit
Direct debit and account-to-account both bypass card schemes, but the logic is entirely different: direct debit is one mandate with repeated collections and fits subscriptions, while account-to-account requires user confirmation each time and fits one-off payments. They divide work rather than replace each other, one carrying the first payment and the other carrying renewals.
If the business sells both one-off and subscription products, integrate both and make the division explicit in the user journey. For how direct debit works and what it costs operationally, compare GoCardless with the GoCardless Guide, and for the overall European method choice see the Local Payment Methods by Region Guide.
7. Who It Fits and Who It Does Not
7.1 Good Fit
First: teams whose buyers concentrate in markets with high online banking use. Users there are used to redirects, so the conversion loss is smaller.
Second: teams with mid-range order values that are sensitive to both settlement speed and transaction cost. Account-to-account usually has an edge on both.
Third: teams able to maintain a complete state machine and refund flow. Confirmation and reverse transfers both need engineering investment.
7.2 Weak Fit
First: teams whose buyers are mostly mobile and used to one-click payment. The redirect and login friction visibly hurts conversion.
Second: teams with very low order values and high refund rates. Refund operations erode the transaction-level cost advantage.
Third: teams expecting to integrate and then stop investing in operations. Awaiting-confirmation states and refunds are continuous work.
Fourth: teams whose buyers sit outside account-to-account coverage. However good the method is, it creates no value where it cannot be used.
8. Rollout Notes and Common Misreadings
8.1 Rollout Notes
| Rollout point | Practical approach |
|---|---|
| Server-side state governs | Use the front-end redirect for experience only and judge success on server state |
| Always handle awaiting confirmation | Set timeouts and active querying so orders do not hang |
| Separate amount matching | Compare arrived amount with order amount in its own process and handle differences |
| Design refunds separately | Reverse transfers need beneficiary details, so separate the process from cards |
| Set page expectations | Explain the redirect, login and automatic return in advance to reduce abandonment |
| Order by data | Let real conversion data decide the display order of account-to-account and cards |
8.2 Common Misreadings
The first misreading is treating account-to-account as a bank transfer. It does end in a transfer from the user account to yours, but authorisation and confirmation run through open banking, so both the experience and the process differ from a plain transfer, and you cannot ask users to type beneficiary details.
The second misreading is assuming refunds return instantly to source the way cards do. An account-to-account refund is a reverse transfer requiring the beneficiary account details, with different timing and experience, so the refund flow and support scripts must be designed separately.
The third misreading is assuming completed authorisation means a successful payment. Authorisation only issues the instruction, and the final result depends on server state and bank-side confirmation.
The fourth misreading is treating account-to-account as a dispute-free method. Disputes are indeed fewer than with cards, but authorisation records, amount matching and refund handling remain mandatory work.
| Common misreading | What actually happens |
|---|---|
| Account-to-account is a plain bank transfer | Authorisation and confirmation run through open banking, so experience and process differ |
| Refunds return instantly to source like cards | Refunds are reverse transfers needing beneficiary details, with different timing |
| Completed authorisation means payment success | The final result depends on server state and bank confirmation |
| Fewer disputes means no records needed | Authorisation records, amount matching and refund handling are still required |
| Account-to-account is always cheaper than cards | Compare after including refund operations, conversion loss and engineering effort |
If you are working on European payment selection, use this guide as a checklist: confirm whether your buyers markets and common banks are supported, confirm whether confirmation and refund paths close the loop in your system, and finally let real data decide the position of account-to-account on the checkout page. For the wider regional judgement, continue from the Payment category page.
Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow the relevant providers’ official documentation and contract terms.