Payment gateways and bank integrations: open banking explained

Charging online or connecting your product to the banks looks simple until you actually dive in. Between payment gateways, banking APIs, and open banking there is a whole ecosystem worth understanding so you can choose well and avoid reinventing the wheel (or skipping the rules). Here we explain it clearly.

What a payment gateway is

A payment gateway is the service that lets you accept cards or other methods securely: it processes the transaction between the customer, their bank, and yours. Solutions like Stripe handle the most sensitive part (card data, PCI DSS, fraud prevention), so you integrate just a few components and the critical data never touches your servers.

Integrating payments into your product

Integrating payments goes well beyond "adding a button": you have to handle retries, refunds, recurring payments, confirmation webhooks, reconciliation, and edge cases (declined payments, disputes, partial captures). Getting it right is the difference between reliable revenue collection and a leaky revenue stream that quietly erodes margins. That is why it pays to lean on robust, well-documented gateways and build a carefully crafted integration on top of them, with proper testing and clear error handling.

What open banking (and PSD2) is

Open banking, driven in Europe by the PSD2 directive, requires banks to open up their data and services through secure APIs, with the customer's consent. This lets a third party (with the proper authorization) check accounts, initiate payments, or aggregate financial information from several banks. It has been the trigger for much of the recent fintech innovation.

Banking APIs and aggregation

With open banking APIs you can build services that once required being a bank: aggregating all of a user's accounts into a single view, initiating direct transfers (without a card), or using real banking data for credit scoring. The key is working with the right aggregators or licenses, because access to that data is strictly regulated.

Common use cases

• Payments and subscriptions in e-commerce and SaaS.
• Account-to-account (A2A) payments with no card fees.
• Financial aggregation and personal finance.
• Income verification and scoring for lending.

Security and compliance

Everything related to payments and banking data is subject to PCI DSS, PSD2, and GDPR, plus strong customer authentication (SCA). The winning strategy is to delegate anything certifiable to specialized providers and focus your own effort on the experience and the business logic, keeping your regulatory scope as small and well-defined as possible. The less sensitive data your own systems touch, the lighter your compliance burden becomes.

Payment gateway or open banking: when to use each

They do not compete; they complement each other. Card gateways are universal and familiar to users: ideal for e-commerce payments and subscriptions. Open banking (account-to-account payment) eliminates card fees and fits high-value amounts, top-ups, or transfers, although user adoption is still growing. Many products offer both and let the user choose: card for convenience, account-to-account for the savings on fees.

The practical rule: start with a robust card gateway, which covers nearly every case, and add open banking when volume justifies the savings on fees or when you need real banking data for your product (aggregation, scoring).

At AxiomTech we integrate payment gateways and open banking APIs into your product, with the security and compliance the financial sector demands, through custom API integrations.

Worked example: migrating from a basic integration to a mature payments setup

A B2B SaaS platform running monthly and annual subscriptions was using its gateway's simplest integration: a redirect to the hosted payment page. It collected money, but the cracks were visible. Failed payments triggered no automatic retries, leading to involuntary churn every month. Annual renewals sometimes failed on expired cards without anyone knowing until the customer wrote in. There was no automatic reconciliation between the gateway and the ERP — someone exported a CSV each week and matched it by hand. And partial refunds required manual access to the gateway dashboard.

The migration to a proper integration took eight weeks. The key changes: payment confirmation and failure webhooks processed idempotently in the backend (so no double charges and no lost events), retry logic with exponential backoff for failed payments, automatic card updates via Stripe Card Updater before each annual renewal, and real-time payment event sync to the ERP. The outcome: involuntary churn rate fell 34 percent, payment-related support tickets dropped 60 percent, and reconciliation went from a two-hour weekly manual task to a fully automated process.

Checklist: robust payment integration

• Payment webhooks processed idempotently (no duplicates, no lost events).
• Automatic retry logic for failed payments with customer notification.
• Automatic card data update before recurring renewals.
• Automatic reconciliation between gateway and accounting system or ERP.
• Refunds (full and partial) manageable from your own dashboard or API.
• Dispute management with structured evidence to reduce lost chargebacks.
• Audit logs of all payment events for compliance and support.

Frequently asked questions

Do I have to be PCI DSS compliant if I use Stripe or Adyen? If you use their hosted components (Stripe Elements, Adyen Drop-in) and never handle card data on your own servers, your PCI scope reduces to the SAQ A self-assessment questionnaire, the simplest one. You still have obligations though: keep software up to date, restrict access to the gateway dashboard, and document both.

When is it worth adding account-to-account (open banking) payments? When average order value exceeds roughly 200-500 euros and card fees are a meaningful cost, or when you need real banking data from the customer for your product (income verification, credit scoring). For most e-commerce with low average order values, cards still deliver higher conversion rates and lower friction.