GhostGlue: sell Ghost memberships with any payment provider, not just Stripe

[Nuenni]

I’ve been running mutliple german Ghost publications for a few years. Some on hosting providers and some self-hosted. At some point I wanted to move away from Stripe for my paid memberships and start experimenting with alternatives like Polar. What I found was a gap that nobody had properly filled yet.

Ghost is built around Stripe. That’s not a criticism, it makes sense as a default. But if you want to use a different provider, you’re left building your own automation with Zapier or Make, or writing webhook handlers from scratch.

Here an example of my old n8n:

Every solution I tried felt fragile. A webhook fails at midnight, a membership doesn’t activate, and you find out the next morning when a subscriber emails you wondering why they can’t access content they just paid for.

So I started building a small relay layer for myself, to fix that problem.

What it does

GhostGlue sits between your payment provider and Ghost. When a purchase event comes in from a provider like Polar, GhostGlue receives the webhook, validates it, and updates the Ghost membership on the other side. The subscriber gets access, Ghost stays the member hub, and you never have to touch Stripe if you don’t want to.

Key things it handles that I kept having to solve manually:

• Webhook signature verification so only real events get processed
• Retry and replay so a temporary Ghost API failure doesn’t lose a purchase
• Multi-tenant support so one instance can serve multiple Ghost publications
• Product to tier mapping so different purchases land in the right Ghost membership tier

Current status

Polar is live and running in production. Lemon Squeezy and Stripe are in deployment. PayPal, Paddle and Gumroad are planned.

The dashboard lets you connect your Ghost credentials, configure your payment provider webhook, run a health check, and map products to Ghost tiers.

Stack for the curious

Vue 3 frontend on Cloudflare Pages, Django backend on Railway, Supabase for auth and database, Cloudflare Workers for the webhook proxy layer.

Open source

Once the core is stable and the main integrations are solid, GhostGlue will be fully open source. The goal is that anyone who wants to self-host the whole thing can do so. There will be a hosted version too for people who just want it to work without running infrastructure. A waitlist is already open at ghostglue.io if you want to grab an early spot.

Where it is today

Still early. A small group of independent Ghost blog publishers are running it in beta-production. I’m taking on founding members while I keep building and would love feedback from people who have run into the same wall.

If you’ve ever wanted to use a payment provider that Ghost doesn’t natively support, I’d genuinely like to hear how you’ve been solving it today. And if GhostGlue sounds like something you’ve been looking for, feel free to reach out or join the waitlist at ghostglue.io.

Happy to answer questions about the integration approach, the architecture, or anything else.

[satonotdead]

Please if you go open-source integrate BTCPay (cripto payments that wins over national barriers and integrates us with everyone).

[csgeek]

My issue with a lot of these hosted services is that there is a trust issue. I had the same problem with a hosted SSO solution.

You’re basically saying I’m trusting this 3rd party and either sending my credentials or letting this provider handle my payments. I know there are patterns to minimize risk and mostly you’re not sending user/pass or credit card info, but as someone who self hosts and does not even use ghost.org, I would much rather even have a white paper on how this was done than a yet another provider that promises to be good with my data.

I appreciate what you’re going for and honestly LemonSqueezy is a very appealing for what they do above and beyond what stripe provides. Still, I’m reluctant to integrate no matter the size of my audience.

[Nuenni]

I get the trust concern, and honestly the SSO comparison is fair. Here’s what actually gets stored: the Ghost Admin API key and the payment provider’s webhook secret, both encrypted at rest (AES-256) on Django/Railway, not some custom-rolled crypto, masked in the UI once saved. No user credentials, no payment data, no card info ever touches the system.

What actually happens on each event is narrow: the payment provider sends something like order.created or order.paid via webhook, GhostGlue verifies the HMAC signature of every incoming webhook first, so a request can’t just claim to be from your payment provider, it has to prove it with a secret only that provider and GhostGlue know. That’s actually one thing typical Zapier setups skip, Zapier receives webhook payloads without verifying their origin at all. After the signature check passes, GhostGlue calls the Ghost Admin API to grant or revoke a member. That’s the entire surface area. No access to your Ghost content, no access to funds, no ability to do anything outside that one narrow action.

I won’t pretend that fully solves the third-party trust problem though, you’re still trusting a service with API access, full stop. Which is actually why open sourcing the core is the plan once it’s stable, so people who want to self-host the relay entirely or just verify the code themselves can. Not there yet, but that’s the direction, precisely because “just trust us” isn’t a great answer for self-hosters.

Appreciate you laying out the reasoning either way, that’s exactly the kind of skepticism this space needs more of.

[Nuenni]

@satonotdead

Please if you go open-source integrate BTCPay (cripto payments that wins over national barriers and integrates us with everyone).

Good shout, and it actually fits the whole point of this thing well, no preference for any one provider, just a relay that gets out of the way.

It’s not on the current roadmap (Polar live, LemonSqueezy and Stripe in deployment, PayPal/Paddle/Gumroad planned next), but BTCPay is exactly the kind of provider that makes sense once the core architecture is stable and open source. The integration pattern is the same regardless of provider: verify the incoming event, map it to a Ghost member action. Crypto/self-hosted payment rails are a natural fit for the self-hosting crowd specifically.

No promises on timing, but noted, and appreciated that it’s not just “add Stripe” requests for once.

[muratcorlu]

@Nuenni

Lemon Squeezy and Stripe are in deployment.

Do you mean “Stripe Managed Payments” here? I think Lemon Squeezy doesn’t accept new customers anymore and direct people to Stripe Managed Payments.

[Nuenni]

Good catch worth clarifying. There are two different things here: classic Stripe, where you’re handling the transaction yourself and the tax/VAT obligation stays with you as the seller, and Stripe Managed Payments, the newer MoR product Stripe built where they act as the legal seller and absorb the tax compliance.

What’s in deployment for GhostGlue is classic Stripe, the transaction-only flavor. That’s intentional, since LemonSqueezy already covers the MoR use case in the lineup, and Managed Payments isn’t available there yet anyway, Ghost’s own native Stripe integration only works with classic Stripe too, so that’s not a GhostGlue-specific gap.

Once Managed Payments is actually out and stable, I’ll take a look. For now the focus stays on what’s already in the pipeline, and that’s a longer list than just Polar and LemonSqueezy, PayPal, Paddle, Gumroad, and Mollie (EU-based, which fits the overall infrastructure direction) are all planned too. Plenty to keep busy with before chasing the newest thing.

One more update for anyone following along: a rebrand to PayGlue is happening soon, still on the current ghostglue.io domain for now while that’s in progress, with a redirect once it’s live. Same roadmap, just a different name on it.

[muratcorlu]

Since Ghost already works with Stripe, what is the point of giving Stripe integration in PayGlue?

[Nuenni]

Fair question, and worth being precise about. PayGlue doesn’t actually integrate Stripe itself, Ghost’s native Stripe integration just keeps running exactly as it is, completely untouched.

The point is that PayGlue runs alongside it. So if you’re already on Stripe for subscriptions, you keep that setup as is, and add Polar (or another provider) through PayGlue for whatever Stripe and Ghost can’t do together, one-time purchases, pay-what-you-want, gifted access, that kind of thing. No migration, no replacing what already works, just filling the gap next to it.

Stripe is still listed as in deployment though, not because PayGlue needs to integrate it, but because coexistence needs to be verified properly. Stripe and Polar (or PayPal, once that’s in) both touching the same Ghost member in different ways is exactly the kind of edge case that needs testing before calling it safe, you don’t want two systems racing to grant or revoke the same membership.

That’s actually the whole “Stripe coexistence” idea behind it: most people don’t want to rip out a working Stripe setup, they just hit a wall when they need a purchase flow Ghost’s Stripe integration doesn’t support.

[csgeek]

This is a bit of a tangent but I would be curious on how you are achieving this. Ghost has integrations but it does not really have a plugin system. There’s a few NPM modules that you can install for S3/GCS storage but that whole ecosystem has always felt a bit brittle to me.

How are you managing to inject your own system into the mix (assuming it’s not the secret sauce).

If we could have a solid stable pattern on extending ghost I think the whole ecosystem would benefit from it greatly.

[Cathy_Sarisky]

Ghost has a pretty good API. So, without knowing anything about GhostGlue, I’ll guess they’ve got a service stood up somewhere that takes webhooks, then uses the Ghost API to create the user if needed and to give them complimentary access to the appropriate tier. [You probably actually need Stripe connected in order to have tiers, unless that’s changed recently.]

You don’t need a plugin for that, you just need a cloud function.

Signed, someone who has built way too many integrations that create and log in users.

[Nuenni]

Honestly there’s no secret sauce here, and that’s kind of the answer to your bigger point: there’s no plugin system involved at all, because PayGlue doesn’t touch Ghost’s codebase or runtime in any way. That’s also why open sourcing the core is the plan once it stabilizes, there’s nothing proprietary to protect, and it means people who want their own infrastructure can self-host the relay, while people who don’t want to deal with hosting or coding can just use the hosted PayGlue version.

The flow has two halves. On the front end, the dashboard generates a pricing table, a plain HTML/JS snippet you drop into a Ghost page or post code block, no server-side code needed. Click a price on that table and it goes straight to the provider’s own checkout (PayPal, Polar, whatever’s configured), so no donation-button workarounds or generic checkout hacks. On the back end, you map each payment tier to a Ghost membership tier in the dashboard beforehand, so the system knows that a 5 euro one-time purchase should result in, say, a paid membership tier rather than just logging a transaction with no consequence. Once a purchase completes, the provider fires a webhook (order.created, order.paid, etc.), PayGlue verifies the HMAC signature so it can’t be spoofed, looks up that mapping, then calls the Ghost Admin API to grant the right membership tier or revoke it on cancellation. That webhook step is where the actual membership magic happens, invisibly, after the checkout’s already done.

So no plugin needed anywhere in that chain, just a snippet on the Ghost side, a mapping in the dashboard, and an API call on the backend side, with Ghost itself never aware any of this exists beyond the Admin API calls it receives.

[Nuenni]

@Cathy_Sarisky

Ghost has a pretty good API. So, without knowing anything about GhostGlue, I’ll guess they’ve got a service stood up somewhere that takes webhooks, then uses the Ghost API to create the user if needed and to give them complimentary access to the appropriate tier. [You probably actually need Stripe connected in order to have tiers, unless that’s changed recently.]

You don’t need a plugin for that, you just need a cloud function.

Signed, someone who has built way too many integrations that create and log in users.

Spot on, that’s basically the architecture. A service sitting somewhere taking webhooks and calling the Ghost Admin API to grant or revoke tier access, no plugin required, just a function that listens and reacts.

And good catch on the Stripe detail, that’s still accurate as far as I know: you do need Stripe connected in Ghost to have paid tiers at all, even if you never actually route money through it. PayGlue doesn’t touch that Stripe connection itself, Ghost’s native integration stays exactly as is, PayGlue just uses the Admin API afterward to assign members to whatever tier already exists once a payment event comes in from Polar, PayPal, or whoever.

Also yes, HMAC verification on the webhook side, otherwise anyone could hit the endpoint and grant themselves a free membership, which I assume is a lesson you’ve learned the hard way at least once given the integrations you’ve built.

[Cathy_Sarisky]

@Nuenni

Also yes, HMAC verification on the webhook side, otherwise anyone could hit the endpoint and grant themselves a free membership, which I assume is a lesson you’ve learned the hard way at least once given the integrations you’ve built.

I’ve never had to learn it the hard way, but I definitely do it! :)