Payments

Mollie knows the customer paid. Your invoice, your books and your shop each found out separately

Mollie is the easy part. Almost every Dutch shop gets a Mollie payment working in an afternoon, and it works.

The hard part starts after the payment: a weekly payout of €12,847.31 arrives in your bank account, covering ninety-one orders minus fees minus two refunds, and somebody has to turn that one number back into ninety-one paid invoices. That is not a Mollie problem. It is the gap between Mollie and everything else you own.

  • Webhooks, so status is right within seconds
  • Fees, refunds and chargebacks handled too
  • From €1,700 plus service fees
The tool

What Mollie is, and which part of it people underestimate

Mollie is a Dutch payment service provider: iDEAL, Bancontact, credit card, PayPal, SEPA direct debit, Klarna and the rest, behind one account and one API. It is the default choice for Dutch webshops for good reasons — no monthly minimum worth arguing about, a per-transaction fee you can read without a calculator, and a checkout that Dutch customers recognise.

Its API is a clean, well-documented REST API with proper webhooks. That is the part people underestimate: Mollie will tell your system the moment a payment status changes, which is what makes an accurate paid-status possible at all. A connection that polls Mollie every hour instead of listening to its webhooks is technically working and practically an hour behind on everything.

The other underestimated half is that a payment has more states than "paid". It can be open, pending, authorised, expired, cancelled, failed, paid, refunded, partially refunded or charged back, and several of those arrive days after the order. A connection that only handles "paid" is the one that leaves a shop full of orders stuck in limbo and a bookkeeping full of differences.

What goes wrong

Three things that go wrong around a Mollie payment

All three are about the states nobody builds for. Every shop handles a successful iDEAL payment on the first try; these are what happens next.

The reminder that goes to somebody who already paid

The customer paid through Mollie in seconds. The invoice in the accounting package is still open, because it will not be marked paid until somebody reconciles the weekly payout — and the automatic reminder runs on day fifteen. So a customer who paid three weeks ago is told they are late. It costs you nothing on paper and a surprising amount of goodwill in practice.

What you see instead

Mollie's webhook marks the invoice paid within seconds of the payment. The reminder never fires, because there is nothing open. The payout that arrives later reconciles to a set of invoices that are already settled.

The transaction fee that quietly eats your margin

A €40 order becomes €39.61 in your bank account. If the connection books €40 as revenue and lets the difference disappear into the payout reconciliation, your margin per order looks better than it is — by roughly one per cent on iDEAL and considerably more on credit card and Klarna. Across a year that is a real number, and it is a number that influenced your pricing.

What you see instead

The fee is booked as its own line on its own ledger account, per transaction and per payment method. Gross revenue is gross revenue, costs are costs, and you can see for the first time what iDEAL costs you versus what Klarna costs you.

The refund and the chargeback that become mystery differences

A refund is processed in the shop or in Mollie's dashboard. Nothing tells the bookkeeping, so the payout is €89 lighter than the invoices say it should be, and somebody spends twenty minutes finding out why. A chargeback is worse: the money comes back out weeks later, with a fee attached, and by then nobody remembers the order.

What you see instead

A refund becomes a credit note against the original invoice, automatically, with the same reference. A chargeback books the reversal and its fee and flags the order, so a pattern of chargebacks on one product or one country is visible rather than being absorbed as noise.

The bill for doing it by hand

What reconciling Mollie by hand costs you

The visible cost is the reconciliation itself. A weekly Mollie payout covering fifty to a hundred orders takes somebody between thirty minutes and two hours to split back out against invoices, depending on how many refunds are in it. Call it an hour a week: fifty hours a year, on arithmetic that both systems could do.

The invisible cost is bigger and comes in three parts. Reminders to customers who already paid, which cost goodwill rather than money. Margins that look one to two per cent better than they are, because the transaction fees are hidden in a reconciliation difference rather than booked as costs. And an aging report you cannot trust, which means you cannot tell a genuinely late payer from an administrative artefact — so either everybody gets chased or nobody does.

The honest counter-case: if you take fewer than about thirty payments a month, the weekly reconciliation is fifteen minutes and this does not need a project. What might still justify one at that volume is the margin visibility, if you are making pricing decisions on numbers that are quietly a percent off.

  • Around an hour a week splitting a payout back out into invoices.
  • One to two per cent of overstated margin, because fees hide in the reconciliation.
  • Reminders sent to customers who paid weeks ago.
  • Refunds and chargebacks that turn up as unexplained differences at month end.
What we build

We build the thing on the other end too

With Mollie the connection is almost never the whole job: the interesting version is a checkout that behaves properly on every payment state, which is a shop project. An order that sits in "pending" for four hours because a bank transfer is slow needs a page that says so, not a spinner.

A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.

API integrations

The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.

Websites

WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.

Webshops

WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.

Web applications

When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.

What can be connected

What can be connected between Mollie, your shop and your books

Mollie sits in the middle of two connections rather than at the end of one: the shop tells Mollie what to charge, and Mollie tells the shop and the accounting package what happened. Both halves are listed here.

  • Payments created from your shop, site or portal

    Amount, currency, description, the order reference as metadata, and the methods you want offered for that order — so a B2B order can be invoice-only and a consumer order iDEAL-first, without two checkouts.

  • Payment status by webhook, all of it

    Open, pending, authorised, paid, expired, cancelled and failed, each with its own consequence in the shop and in the books. The states that arrive late are the ones that matter: a bank transfer paid three days after the order should still release that order.

  • Transaction fees per payment and per method

    Booked as their own line on their own ledger account, so gross revenue stays gross and you can compare what each payment method actually costs you per order.

  • Refunds and partial refunds

    A refund started in the shop executed in Mollie, and a refund started in Mollie's dashboard becoming a credit note in the accounting package against the original invoice. Two-way, because both places are where people actually do it.

  • Chargebacks and their fees

    Booked, and the order flagged. Rare enough that most connections skip it, and expensive enough per case that skipping it is how a pattern goes unnoticed for a year.

  • Subscriptions and SEPA direct debit mandates

    A subscription started on your site creating the Mollie customer and mandate, charging on schedule, and stopping when the customer cancels on the site. The cancelling half is the one that gets forgotten and the one that generates angry email.

  • Payouts, reconciled against the invoices in them

    The bank statement line matched to the set of payments, fees and refunds that make it up, so the bank reconciliation in your accounting package resolves in one click instead of forty.

Rows two, three and four together are the version almost everyone should have: status by webhook, fees booked properly, refunds handled. The subscription and payout rows are worth adding when they apply, and are a bad first project when they do not.

How it works

How a connection gets built at JKC

The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.

  1. 1. We look at what is actually being retyped

    Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.

  2. 2. We pick the route, and say why

    A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.

  3. 3. We build it to survive the other system

    Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.

  4. 4. We hand it over with the failure modes written down

    Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.

More about system integrations at JKC

After it goes live

A connection that fails silently is worse than no connection

This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.

An alert per failed message, not a monthly report

A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.

Replay, not re-enter

Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.

We watch the vendor's changes, so you do not have to

APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.

What it costs

From €1,700, and the biggest variable is who built the other end

For Mollie specifically: getting a payment to work is not the project and we would not quote €1,700 for it — a WooCommerce plugin does that for free. What costs money is the accurate side: every status handled, fees booked, refunds and chargebacks reconciled, and the matching against whichever accounting package you use.

A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.

What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.

Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.

Questions

Frequently asked questions about connecting Mollie

Yes, and it is the most-asked pairing on this page — people search for it by name. Mollie's webhook fires, the matching Moneybird invoice is marked paid on the day the money actually cleared, and the transaction fee is booked as its own line so your margin per order stays honest.

The part worth insisting on is the refund half: a refund becomes a credit note against the original invoice rather than a negative that turns up in the bank feed with no explanation. Without that, you have solved the reminders and kept the month-end differences.

Often next to this one

Tools that often sit next to this one

Almost nobody connects one tool. These are the ones that come up in the same conversation, either because they sit in the same part of the business or because people ask for the two together.

See all integrations

Free, 10 minutes

Not sure where the manual hours actually go?

That is what the Growth Scan is for. Ten minutes, no sales call attached: you get back where the double work sits, which connection would pay for itself first, and which one honestly would not.

Do the free Growth Scan