A payment system on your website: how to integrate online payments

A payment system on your website seems simple: add a payment button and you are done. Anyone who has built one knows there is more to it. What happens if the customer closes the window halfway through? How does your system know that payment has been made? What if a payment is reversed later? In this article we walk through the choices, components and pitfalls that come with online payments, so you know what is needed before you start.

How does a payment system on your website work?

A payment system on your website sends the customer via a payment provider to their bank or card issuer and then tells your system whether the payment succeeded. Behind those few seconds is a fixed sequence:

1. The customer chooses a payment method and completes the payment.
2. Your payment provider, such as Mollie or Stripe, processes the transaction with the bank or card issuer.
3. The transaction is approved or declined.
4. The provider sends your system a notification with the result.
5. Your system processes the order, grants access or sends a confirmation.
6. The money is paid into your account later.

Every step is a point where something can go wrong. A good payment system handles all of those moments.

Which choices do you make in advance?

In advance, you decide which payment methods you offer, whether payments are one-off or recurring, how your pricing model works and what needs to happen after payment. Those choices determine how complex the build will be.

Payment methods. iDEAL is indispensable in the Netherlands. You need credit cards for international customers. Bancontact for Belgium, Apple Pay and Google Pay for fast mobile checkout, buy now pay later for certain audiences. Each method has its own costs and its own risks.

One-off or recurring. A one-off payment is straightforward. Recurring payments require mandates, direct debits and an approach for failed payments. We cover that in setting up recurring payments and subscriptions.

Pricing model. A fixed price is simple. Prices based on configuration, discount codes, tiered pricing or VAT for customers in other countries require more logic.

What happens after payment. Just a confirmation email, or also access to an account, a download, an order to the warehouse and an invoice to accounting? The more follow-up steps, the more important a reliable connection becomes.

Which payment provider suits your website?

For most Dutch websites, the choice is Mollie or Stripe. Mollie is strong in local payment methods and quick to set up, Stripe in international sales and complex invoicing. Both charge per transaction. We weigh them up in detail in Stripe or Mollie: which payment provider should you choose?

What components make up a payment integration?

A payment integration consists of four components: the checkout, the processing of status notifications, error handling and record keeping.

The checkout. What the customer sees. That can be a hosted payment page from the provider, where the customer goes and then returns, or a checkout built into your own page. Hosted is faster to implement and takes many security requirements off your hands. Embedded gives more control over the experience, but requires more work.

Webhooks. After every status change, the provider sends a message to your system: paid, failed, expired, refunded. Your system has to receive, verify and process those messages. This is the heart of the integration and the place where things go wrong most often.

Error handling. Payments fail, sessions expire and customers click twice. Your system shows a clear message, allows a new attempt and prevents duplicate orders.

Record keeping. Every transaction is recorded and linked to the customer and the order. For your own overview, for accounting and in case a dispute arises. That data belongs in a central database, for example in Supabase or Xano, so that all systems see the same status.

Which mistakes do we see most often?

The mistakes we see most often are not in the payment itself but in what happens around it.

Not tested. Every provider has a test environment. Test all scenarios there, including failed and abandoned payments, before you go live.

Relying only on the customer returning. If the customer closes the window after paying, they never reach your thank-you page. If your system only processes the order there, the customer has paid but received nothing. Always process the payment based on the webhook.

Unclear error messages. A blank page or a technical error code leaves the customer uncertain. Tell them what went wrong and what they can do.

VAT not set up correctly. Simple for Dutch customers, but different rules apply when selling to consumers in other EU countries. Sort this out in advance, possibly with your provider's tax module.

No plan for refunds. Customers sometimes ask for their money back. Define how a refund runs in the provider, in your own system and in your accounting.

What do the costs of a payment system depend on?

The costs consist of transaction fees at the provider and the one-off build of the integration. The transaction fees depend on the payment methods and the size of your purchases. The build costs depend on the pricing model, one-off or recurring, the number of follow-up steps after payment and the number of systems that need to listen in. A hosted checkout with one follow-up step is a small project; a full subscription platform with connections to accounting and CRM is a different story.

How do we approach a payment integration?

We start with what you need now and where you want to go, so that the choice of provider and setup still holds up in a few years. Then we build, test every scenario and go live with extra attention during the first weeks. We build payment systems into webshops, reservation and booking systems and custom applications. Want to know what you need? Get in touch.