Of all the providers I have not built, Mollie is the one people ask about most. The requests come from the Netherlands, Belgium and Germany, and the argument is always the same one. Mollie is what European shops already use. It does iDEAL, SEPA Direct Debit, Bancontact, cards and PayPal. And if a publisher already has a Mollie account, why on earth would they want to open another one somewhere else?
I spent a good part of July with the API and came out the other side saying no. The changelog entry says “won’t build” and not much else, which is a bit thin for anyone who had been hoping for it. So here is the longer version.
What Mollie’s API is good at
Nothing in this article is a complaint about the API, and I want that on record before I say anything else. Mollie built it for shops, so it thinks in payments and orders, and the webhook side does the sensible thing. Mollie calls your URL with the id of the object that changed. You fetch that object and read its status yourself. If your server does not answer within 15 seconds, Mollie retries with increasing intervals for up to 26 hours, which is more patience than some providers I could name. A payment webhook fires on paid, expired, failed and canceled, and again on refunds and chargebacks.
That is the shape PayGlue wants from a provider. Something gets bought, a webhook tells us about it, we go and look at the object, and then the member in the publisher’s Ghost gets created or updated or loses access, depending on what we found. If the whole question were “can PayGlue hear what happens at Mollie”, the answer would be yes and this article would not exist.
Where recurring lives
The trouble is the other half. Most of what PayGlue users sell is a membership. A membership is a subscription, a subscription means renewals, and renewals are where Mollie’s model and PayGlue’s model stop overlapping.
Here is how recurring works in Mollie. You create a Customer. Then you take a first payment from that customer, which for cards and PayPal can be a zero or one-cent payment, and what you get back is a mandate. Once you hold the mandate you can either charge the customer whenever you like or create a Subscription object with an amount, an interval, an optional number of charges and a webhook URL for the payments that come out of it.
Every bit of that is API only. There is no way to set up a subscription in Mollie’s web app, and SEPA Direct Debit or credit card has to be active on the profile before any of it works at all. In test mode, subscriptions cancel themselves after ten payments.
For what it is, it is a clean design. It also assumes something: that the merchant has already written the software that creates the customers, collects the mandates and looks after the subscriptions. Mollie gives you the rails and leaves the rest to you.
What is missing for PayGlue
Compare that with Polar, Paddle, Lemon Squeezy or Gumroad. The publisher creates a product at the provider, copies the checkout link, pastes it into PayGlue, and from then on the provider runs everything: the checkout, the renewals, the dunning when a card fails, the invoices, the tax. PayGlue listens to the webhooks and keeps Ghost in sync. That is the whole job.
Mollie has no hosted product with a subscription checkout link. There is nothing a publisher can create in Mollie’s dashboard and paste into PayGlue. So every piece the other providers own would have to become code somewhere: creating the customer, collecting the mandate, creating the subscription, dealing with a failed renewal, giving the member a way to cancel, producing invoices. Either the publisher writes that code, and if they could do that they would not need PayGlue, or PayGlue writes it and runs it on the publisher’s behalf.
I sat with the second option for a while, because it is possible, and a possible thing is hard to put down. Then I worked out what it would turn PayGlue into. A tool that creates mandates and charges them every month is a billing system, whatever else it calls itself. PayGlue hands billing to providers on purpose. I want a publisher’s money handled by a company whose entire business is handling money, and I do not want to be the one on the hook when a renewal fails at three in the morning. A Mollie adapter that owned subscriptions would throw that away on day one.
The slice that would work
One-time purchases are a different story. Mollie has Payment Links, which are hosted and one-off, and together with the payment webhook they map cleanly onto a single sale. A publisher creates a link, pastes it into PayGlue, and when the paid webhook arrives a member with access falls out the other end. That would work today.
I still did not build it, and that was arithmetic, not principle. An adapter costs more than the adapter. It comes with docs, with tests, and with a share of every support conversation from that day on, and a provider that covers one-time sales only, for a user base that mostly sells memberships, did not pay for all of that. I could see the first support ticket before I had written a line: “how do I sell a subscription with this”. And I could see my answer: “you do not”.
The tax question
There is one more difference, and for European publishers it may be the bigger one. Mollie is not a merchant of record. The publisher stays the seller, so the publisher stays responsible for VAT: the right rate for each buyer’s country, and the filing that comes after. Most of the providers PayGlue does connect are merchants of record and take that job off the publisher’s desk. I wrote about the difference earlier, and it is a big part of why those providers suit people who would rather write than do tax.
Again, that is not a mark against Mollie. A shop has an accountant. A lot of solo publishers have a shoebox.
What would change my mind
Two things could. The first is a hosted subscription checkout at Mollie, where the publisher creates the product in Mollie’s own interface and Mollie runs the renewals. That would make the Mollie adapter a normal adapter, and I would build it without much fuss. The second is enough demand for one-time sales on their own, from publishers who are fine selling single products through Mollie and memberships somewhere else. That would justify the smaller adapter by itself. I can imagine either happening. As I write this, I have neither.
What July taught me is that PayGlue’s promise, “share a link, we handle the rest”, only holds while the provider owns the subscription. I had assumed that an open, well documented API was most of what I needed from a provider. Mollie has both, and it is still the wrong shape for what this tool does, and I did not see that until I had spent weeks inside it.
One more thing, because leaving it out would feel dishonest. I use Mollie myself, as a customer, in an e-commerce side project of mine. They do a very good job there, and the payment link in particular is the kind of small feature that just works every single time. None of that moves the verdict. It just does not fit what PayGlue does.
Update, September 2026: the same thing happened a second time, with Steady. Different platform, same shape of problem.