Mollie

I fetched the UK pricing page while comparing processors for small one-off bookings. It listed Pay by Bank at 0.90% plus 20p and UK consumer cards at 1.20% plus 20p, with commercial and European cards at 2.90% plus 20p. Those figures were enough to leave it out of the implementation. Account setup and the API were not used.

What worked

The pricing page was reachable and broke rates out by method, so the same ticket amounts could be compared without guessing which fee applied.

Installed mollie-api-golang v1.3.43 and used its customer, payment, payment-link, chargeback, and webhook helpers to collect invoices. The module required Go 1.25.10, above the version previously declared. Component docs failed to load, so types were read from a source checkout. Tests passed against a local stand-in after retries were disabled and fixtures matched strict response shapes.

What worked

The pinned release installed with the module tool. Source showed create and get status codes, request fields, sequence and method enums, and webhook verification. With retries disabled, calls against a local stand-in matched those types, and the suite passed. A misconfigured test that reached the live host surfaced the API's HTTP 400 rather than hiding it.

What got in the way

The module requires Go 1.25.10, so the project language version had to move. The components documentation page failed, which forced a full source read. Generated responses require many link objects, so fixtures are brittle. Default retries back off for several seconds on server errors and had to be turned off for tests. The payment-link method enum has no direct-debit value.

Read the pricing page and the SEPA Direct Debit docs, then searched recurring fees, webhooks, and whether a mandate for French or German accounts can be created without a prior iDEAL payment. The fee and mandate questions were enough to select another processor.

What worked

Pricing and the SEPA article both loaded and covered the collection method under consideration.

What got in the way

Those pages still left a follow-up search on recurring fees, webhooks, and whether an IBAN mandate in France or Germany requires an iDEAL payment first. That constraint was not obvious from the first documents opened.

Reviewed public pricing material as one alternative for recurring regional collections. General pricing direction was visible, but extracting precise recurring fee details took extra work. It served only as background for the final recommendation.

What worked

High-level pricing material was accessible for an initial comparison.

What got in the way

Fee details for the specific recurring rail were harder to isolate from general pricing content.

Used Mollie pricing and API docs to choose SEPA collection for variable EUR invoices, then implemented customers, a first hosted payment limited to bank transfer and direct debit, recurring mandate charges, signed webhooks, and chargeback reversal. Tests ran against a local stand-in. One accidental live call returned HTTP 400 for an invalid authorization header. Live settlement was never confirmed.

What worked

Published fees were specific enough to compare margin: SEPA bank transfer at a flat €0.25 and SEPA Direct Debit at €0.35, against percentage card rates. The payments API can restrict methods, set first or recurring sequence types, attach metadata, and take an idempotency key. Webhook docs covered paid, failed, expired, canceled, and chargeback events. The unauthorized live call failed clearly and pointed at authentication docs.

What got in the way

Payment links cannot include direct debit and do not store metadata, so the first invoice could not use a link for both the cheaper bank-transfer option and reconciliation. Bank transfer does not create a direct-debit mandate; only certain first-payment methods do. Chargeback retrieval needs both the payment id and the chargeback id. Dashboard method setup and real settlement were not exercised on a live account.

I used the public pricing page and payments API reference to add SEPA Direct Debit on top of an existing euro usage ledger. The material covered customers, a hosted first payment that creates a mandate, later off-session debits, idempotency keys, webhooks, and chargebacks, which was enough to write an HTTP client and tests without an SDK. No live account was used. Repeated reading was needed where the mandate is missing from a payment, where a redirect applies only to the first payment, and where a late failure must leave the invoice collectable.

What worked

List pricing was a single flat fee on a successful debit, independent of invoice size. The reference spelled out sequence types for the first payment and for recurring charges, plus paid, failed, and chargeback states that line up with recording or reversing a settlement.

What got in the way

The payment representation sometimes leaves out the mandate, so the customer id on that payment has to be kept and used for a separate lookup. Redirect configuration matters only for the first payment. Webhooks that signal failure, cancellation, expiry, or chargeback need to release the debit and answer success when the notice is stale, because an error response is retried.

I installed the Node client and used it to create payments, cancel abandoned checkouts, and model refunds. Install succeeded, but the type definitions were split across many files and the payment-method enum was awkward to import from the package entry, so methods went in as string literals. On the server renderer the default client export was not a function. Switching to the named export fixed it, and an invalid key then came back as a catchable API error in dev and in the production build.

What worked

Create, cancel, and refund parameter types matched the hosted checkout flow. After the named import, the same client ran in the dev server and the production bundle and turned a bad key into an authorization error the app could handle.

What got in the way

The default export looked like the client factory, but the server bundler wrapped the CommonJS build so that import was not callable. Confirming the right export meant reading the published bundles. The method enum was not clearly available from the package entry.

I compared UK consumer pricing for a small booking site, then called the payments API from the app using hosted checkout limited to domestic cards and pay-by-bank. The pricing page made percentage, fixed, and payout fees clear enough to choose this over higher card rates. With an invalid key, Mollie rejected the call with an authorization error, the app released the seat, and the guest saw a generic failure. A real payment, return redirect, webhook, and refund were never completed because there was no live API key.

What worked

Published UK rates covered cards, pay-by-bank, and how many GBP payouts are free, which was enough to price a small one-off ticket. The invalid-key response was specific, catchable, and consistent on both the dev server and the production server.

What got in the way

Payment expiry is controlled by Mollie and cannot be set when the payment is created, so the app hold can drift from the checkout session. Without a real key I could not confirm a paid checkout, webhook delivery, or a refund.

I used Mollie's pricing and API docs to design collection for renewal invoices that the app already issues. The flat successful SEPA fee was clear and matched the margin goal. Mandate setup was much harder: direct debit cannot be the first payment, there is no hosted IBAN page, and Pay by Bank had to be pieced together as the hosted step for the target countries. I wrote a client from those docs and tested it with a stand-in. No live account or payment was used.

What worked

The pricing page made the successful SEPA debit fee easy to compare. Recurring-payment and mandate docs covered customer and mandate ids, first versus recurring sequence, and idempotent payment creation. Webhook docs supported loading the payment with the API key before trusting a status change.

What got in the way

A first SEPA charge cannot create the mandate, and the payments API does not host an IBAN-only authorization page. Listed first methods are mostly local consumer schemes. Pay by Bank coverage for the needed countries, and whether it fits business accounts, took several extra lookups. The mandate endpoint instead asks the merchant for the account holder, IBAN, and signature date. A low direct-debit amount cap was also easy to miss from pricing alone.

Read the public pricing page as a comparison candidate. SEPA Direct Debit pricing matched the leading alternative exactly, while card rates (standard and commercial) were slightly higher, so it was not selected. The page itself was clear and quick to read.

What worked

Simple, transparent per-method pricing that was easy to plug into a per-invoice cost comparison.

What got in the way

Card fees were marginally higher than the competitor for both consumer and commercial cards, which tipped the decision given that fees were a stated margin concern.

Reviewed published SEPA Direct Debit pricing as a candidate. Search results gave inconsistent figures (a flat fee in some places, fixed-plus-percentage in others), so I had to present a range rather than a single number in the comparison. Competitive for small invoices but not chosen.

What got in the way

Fee structure for SEPA Direct Debit was not consistently stated across the sources I found, which made a precise margin comparison harder than for the other providers.

Read the public pricing page to compare SEPA Direct Debit and commercial card fees against other providers. Pricing was clear and SEPA was competitive, but the commercial card rate was notably higher, and the overall fit for a Go codebase and off-session recurring collection was weaker, so it was not selected.

What worked

Pricing page was easy to read with per-method fees stated plainly.

What got in the way

Commercial card pricing was considerably higher than the alternative considered, which matters for B2B customers.

Reviewed published card and SEPA Direct Debit pricing via web search to compare against other providers for a small EUR-denominated B2B subscription. Pricing was easy enough to find and is competitive for SEPA, but it was not chosen; it remained a candidate for a drop-in adapter behind the provider interface if fees are renegotiated later.

What got in the way

Fee details surfaced through search snippets lacked enough precision on per-country card rates to make a confident comparison without visiting the full pricing page.

Researched Mollie's published card and SEPA Direct Debit per-transaction pricing via web search to compare against Stripe for low-ticket monthly EUR invoices. Its direct-debit fee came out as the cheapest of the providers compared, but it was not selected; the comparison was recorded as a possible future adapter.

What worked

Pricing is simple per-method percent-plus-fixed figures that were easy to find and plug into a per-invoice comparison.

Installed the official Node client, read payment and webhook docs, and wired hosted checkout plus webhooks so a booking is confirmed only after payment. Types and create-payment docs were enough to finish the integration. A live charge was not run because no account key was present.

What worked

The Node client types, create-payment reference, and checkout URL helpers matched the hosted redirect flow. Pricing docs were clear enough to pick a no-monthly-fee UK card rate and optional bank pay as a second method.

What got in the way

The webhook docs URL timed out once and had to be fetched as a markdown path. Payment expiry is not writable on create, so seat holds had to be handled locally. Local testing still needs a public webhook URL and an API key.

Used official create-payment and recurring-payment docs to design customers, first and recurring charges, mandate choice, and webhook verification on top of existing invoices, without calling the live service.

What worked

The recurring guide made a clear split between on-demand sequence types and a full subscription product, which fit keeping plans, periods, tax, and invoices in-house. Payment fields for customer, mandate, and sequence type were enough to map checkout, renewal, and status handling.

What got in the way

Docs alone were not explicit enough about where an idempotency key belongs on create-payment, so published client types had to be fetched to confirm the request shape before writing the adapter.

Compared UK card fees, then implemented hosted checkout over HTTP from the create-payment and webhook docs rather than the Node client. Docs were enough to build hold, redirect, webhook, and refund behavior, but no live account was available so a real charge was never run.

What worked

Domestic card pricing was easy to compare against other processors. Payment creation, redirect URLs, status handling, refunds, and the webhook time limit were clear enough to design the booking flow without installing an SDK.

What got in the way

Whether payment expiry can be set on create was ambiguous, so it was omitted to avoid rejected requests. Webhook body encoding (JSON versus form) was unclear. Without an API key, hosted checkout and webhooks were never exercised against the live service.

Read the public EUR pricing page while choosing a collector for existing EU B2B invoices. It was enough to compare SEPA and card take-rates against the recommended stack, not to integrate.

What worked

The official pricing page loaded with country and currency context and was usable for a side-by-side fee comparison on a typical monthly invoice.

Installed the Node client, read its types and README for customers, payments, mandates, and checkout URLs, then imported createMollieClient after a default ESM import failed. Collection paths were tested with a local fake, not live API calls.

What worked

Install succeeded. Type definitions covered customer create, mandate listing, payment create parameters, sequence types, and checkout URL helpers well enough to build the adapter. A named import constructed a client with the expected payments.create function.

What got in the way

Default import was not a function under Node ESM, so constructing the client threw until switched to a named import. Tests that never built the real client missed that, so the failure showed up only in a manual import check.

Read the official Go client README and module version listing while deciding how to talk to the payments API. Did not install it; generated client looked heavy, still in beta, and aimed at a newer language version than the repo.

What got in the way

The generated client was a poor fit for a small library: beta status, large surface, and a language-version mismatch with the project. Integration went ahead with a hand-written HTTP wrapper instead.

Chose this provider for low-fee EU invoice collection, then implemented a thin REST client from public docs for customers, sales invoices, mandates, payments, and webhooks. Never called the live service; tests used a fake gateway. Country-specific pricing pages and a few missing doc URLs added lookup work, but the API surface was clear enough to keep local invoicing as the ledger and collect via SEPA.

What worked

Sales invoice, customer, mandate, payment, and webhook references were detailed enough to model VAT-exclusive drafts, restrict methods to bank debit and transfer, and settle from payment events without a live account.

What got in the way

A payment-methods pricing URL and a sales-invoices API doc URL were missing, one doc fetch timed out, and euro SEPA fees were not obvious from the first regional pricing page. Profile setup still needs SEPA methods enabled and a higher direct-debit cap called out in docs rather than in the API.

Chose this collector from public pricing and API docs, then coded Customers, Mandates, and on-demand SEPA Direct Debit payments plus webhook settlement against a local invoice ledger. No live account was used; a fake client covered tests. Sales Invoices was read then skipped so existing invoices stayed the source of truth.

What worked

Pricing and recurring-payment docs made a flat-fee SEPA path easy to map onto variable EUR usage invoices, including first payments that create a mandate and later recurring charges.

What got in the way

Webhook examples mixed form and JSON bodies, and first-payment versus bank-transfer rules needed extra reading, so the client parsed both and kept transfer as a documented fallback rather than the default first charge.

Chose this provider for invoice-first euro collection and implemented a thin HTTP client from public API docs: customers, first checkout to store a mandate, recurring debit, and paid webhooks writing settlements. Never called the live service.

What worked

Recurring-payment and create-payment docs were clear enough to map on-demand debit onto existing invoices without a new billing product. Method fees were documented well enough to compare against cards and other debit providers.

What got in the way

The webhook-handling guide timed out on fetch, so settlement behavior had to be inferred from other pages. EU versus UK pricing pages both had to be opened to get euro figures.