Which Payment Integration Model Should You Choose?

There is no single right way to integrate payments. A sole trader sending payment links has very different needs from an insurer submitting hundreds of thousands of debit orders per month. Integration models sit on a spectrum from no-code to deeply technical, and the right choice depends on your volumes, your team and how much control you need over the payment experience.

This page compares the common models and gives a framework for choosing between them.

What are the main integration models?

Payment links

A payment link is a URL you share by email, SMS or WhatsApp. The customer pays on a page hosted by the provider. No development is needed, which makes links the fastest way to start accepting payments.

Plugins and platform integrations

Pre-built modules for e-commerce platforms handle checkout, callbacks and reconciliation with configuration rather than code. Suitable when your store runs on a supported platform and you do not need custom payment flows.

Hosted checkout and embedded components

With a hosted checkout, the customer is redirected to the provider's payment page and returned afterwards. Embedded components keep the customer on your site while sensitive fields are hosted by the provider. Both dramatically reduce your PCI DSS scope because card data never touches your servers. The trade-offs are compared in hosted, embedded and API checkout.

Direct API integration

Your systems call the provider's APIs to create mandates, submit collections, initiate payouts and query statuses, and receive results via webhooks. APIs give real-time feedback and full control, at the cost of building and operating the integration: authentication, retries, idempotency and status handling all become your responsibility.

Host-to-host batch files

Fixed-format or ISO 20022 files exchanged with the bank or provider over secure channels such as SFTP, on defined submission cut-offs with acknowledgement and response files. This model suits organisations processing very large volumes of debit orders or payouts on predictable cycles. The detailed comparison lives in batch files vs APIs, and for DebiCheck specifically see API vs host-to-host.

How do you choose a model?

Work through these questions:

• Volume and cadence: occasional payments favour links and hosted pages; large recurring collection runs favour APIs or files.
• Latency: do you need a result while the customer waits (API), or is next-cycle confirmation acceptable (files)?
• Team capability: APIs and host-to-host integrations need developers to build them and operations staff to monitor them. No-code models need neither.
• Compliance appetite: hosted and embedded models keep card data off your systems; direct card APIs pull you into much heavier PCI DSS obligations.
• Control: the more you customise the experience and automate downstream processes, the further you move toward APIs.

Can you combine models?

Yes, and most growing businesses do. A common pattern is payment links for ad-hoc invoices, a hosted checkout for the online store, and an API integration for recurring debit order collections. Some large collectors run APIs for real-time DebiCheck mandate authentication and host-to-host files for bulk collections.

Whichever mix you choose, the operational fundamentals stay the same: unique references, idempotent submissions, status handling and daily reconciliation.

Back to the Payment Operations hub.