PayGlue: 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

PayGlue sits between your payment provider and Ghost. When a purchase event comes in from a provider like Polar, Pa<GLue 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.

Open source

Once the core is stable and the main integrations are solid, PayGlue.io 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 PayGlue.io if you want to grab an early spot.

GitHub - PayGlue/PayGlue-OS: PayGlue connects Ghost CMS to any payment...

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, And you have no interest in maintain your own infrastructure. I’d genuinely like to hear how you’ve been solving it today. And if PayGlue sounds like something you’ve been looking for, feel free to reach out or join the waitlist at PayGlue.io .

Wanna see it in live action for testing?

What a Full Pricing Table Looks Like When It Talks to Ghost

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

[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! :)

[csgeek]

@Nuenni

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.

Most of that makes sense but does Ghost not by default generate a Stripe link for subs etc? Once you setup tiers and Stripe when the end user hits Subscribe he gets the tiers selection and the stripe link.

Are you inject code (your snippet) to swap that out with your own code? Sorry, if some of this is really dumb but JS/frontend is not really my area. If that’s the case that could open up the door to all kind of patterns.

[Nuenni]

Good question, and no, nothing gets swapped or injected into Ghost’s own flow. Ghost’s default Subscribe button, the one that triggers the native Stripe checkout for tiers, keeps working exactly as it always has. PayGlue doesn’t touch that button, that flow, or any of Ghost’s existing JS.

The pricing table snippet is something separate you place wherever you want. Practically speaking, you drop the generated HTML and a small JS snippet (for signature/verification handling) into the same code injection area you’d normally use for something like a cookie banner, not a swap-out of the existing Subscribe button. It’s there specifically for things Ghost’s native flow doesn’t cover: one-time purchases, pay-what-you-want, or a tier mapped to a non-Stripe provider. So a site could easily have both side by side, the normal “Subscribe” button going through Stripe as usual, and a separate pricing table elsewhere for, say, a one-time supporter tier through Polar.

No code injection into Ghost’s theme or checkout flow needed, which is also why there’s no real “door” opened here in the security sense you’re worried about, it’s an independent embed in the same place you’d already put a cookie banner, not a modification of something Ghost already renders.

[Abhishek_Prakash]

Interesting concept and definitely need of the hour.\

Does this work natively with Ghost portal? Can it also support lifetime membership?

[Nuenni]

Thanks, glad it resonates.

To answer both: PayGlue doesn’t touch Ghost’s own customer portal, the widget where members sign up, log in, and where Stripe/tiers get configured natively. That stays exactly as is. What PayGlue adds is a separate dashboard where you set everything up, then you drop in one JS snippet in the header and a button or pricing table snippet on a Ghost page. Your customer pays through whatever provider you’ve connected, Polar, PayPal, etc., and PayGlue matches that to the right Ghost member in the background via webhooks. On the Ghost side, the member gets created with complimentary access, essentially a synthetic subscription for paid content. If they cancel or change their plan, the same webhook flow downgrades them back to free.

Lifetime membership is straightforward with this setup, actually. Since it’s just a one-time purchase mapped to a tier with no expiration logic attached, granting permanent access instead of a recurring one is easy to support, no different mechanism needed.

One-time payments are great when you’re just starting out with your blog, no commitment pressure for either side while you’re still figuring out your audience.

Feel free to take a look around the site, there’s a How it Works breakdown and a Security writeup that go into more detail than I can fit in a comment.

[Abhishek_Prakash]

Thanks for answering that.

Since the members will be added as complimentary, some of them will complain when they see that notice in email newsletters. I get those complains every now and then from my lifetime readers.

But again, this is way better than my manual setup where I have individual links to various Payment options (for lifetime members).

I will surely check it out.

[Nuenni]

Yeah, that’s a real downside and a fair thing to flag, that “complimentary” label is Ghost’s own wording for that member status, not something PayGlue controls or can rename. I haven’t run into many complaints myself yet, but I get why it bugs people, they paid real money and the label makes it sound like a freebie, even though the access itself is exactly the same as any paying tier.

Small silver lining, it does sometimes turn into a useful moment, gives you a reason to actually talk to your most invested readers when they bring it up. But yeah, no argument that it’s a cosmetic annoyance some people will notice and care about.

And appreciate the honesty either way, manual payment links per provider is exactly the kind of fragile setup this is meant to replace, even with that wrinkle.