Lemon Squeezy Is Becoming Stripe Managed Payments: What It Means If You Sell GitHub Repo Access

When Stripe bought Lemon Squeezy in July 2024, nothing broke. When the January 2026 update pointed everyone at Stripe Managed Payments, nothing broke either. That is how platform migrations always feel from inside: nothing breaks until the day something does - and the sellers who get hurt are the ones whose delivery, the part that grants a buyer their GitHub repo, is welded to the rail that moved.

What Stripe Managed Payments means for Lemon Squeezy sellers

The facts, from both sides. Lemon Squeezy’s 2026 update names the direction: the goal is “an easy way to migrate to Stripe Managed Payments”, Stripe’s own Merchant-of-Record product. There is no shutdown date and no forced deadline. The sign-up form is live, the API works, webhooks fire.

Since that post, the destination has opened. Stripe made Managed Payments generally available in April 2026, at 3.5% per transaction on top of its payment fees. Access still runs through an eligibility review of your business type and your country.

So this is not a fire alarm, and I am not going to write one. It is something quieter and more useful: a dated, public confirmation that the platform under your checkout is in managed motion. The question worth asking is not “when do I have to leave” - nobody knows. It is “which parts of my setup move when the platform moves, and which parts are mine”.

TL;DR

• Lemon Squeezy still works and has no shutdown date; the stated direction is a managed migration to Stripe Managed Payments
• The risk is not the payment rail changing - it is delivery welded to the rail, moving on someone else’s schedule
• The durable fix is architectural: split delivery from payments, so the provider becomes a swappable adapter under a delivery layer you own
• An open-source engine for exactly that split exists, and its Stripe half is free - holding the migration path open costs nothing

Stripe Managed Payments supported countries: 37, against Lemon Squeezy’s 119

That review starts with a list. Managed Payments accepts sellers based in 37 business locations: the United States, Canada, 31 European countries, Australia, Hong Kong, Japan and Singapore. Lemon Squeezy pays out to bank accounts in 119 countries, and all 37 are among them. Those payouts run twice a month, in your local currency or by PayPal in USD.

The other 82 are not on Stripe’s list. Turkey, Pakistan, Nigeria, Bangladesh, Egypt and India are among them. Neither company has said what happens to those sellers when the migration starts, so I will not guess.

If you sell from one of those countries, the documented migration path does not include you today. The rail you would move to is another Merchant of Record, not Stripe. That is one more reason to keep delivery off the rail: the adapter changes, the buyers’ access does not.

What actually breaks when a payment platform migrates under you

Not the checkout. Stripe migrates checkouts for a living, and the money path will be the most rehearsed part of the whole move. What breaks is the glue - everything downstream of the payment that is keyed to Lemon Squeezy’s specific shape: webhook payloads, event names, signature scheme, API endpoints.

For repo sellers that glue is the delivery itself, because Lemon Squeezy has no first-party “invite the buyer to a GitHub repo” feature. Sellers assemble it: a Zapier automation, a DIY script along the lines of the MakerKit tutorial, or Lemonrepo - an open-source Nuxt app that grants repo access on a Lemon Squeezy order. All three speak Lemon Squeezy’s API specifically. One of them is named after it.

Move the rail to Stripe Managed Payments, and the payment events become Stripe’s events: different payloads, different signatures, different names. The Zapier trigger goes quiet, the script needs a rewrite, and Lemonrepo would need to become a different product. Nobody did anything wrong - the delivery was simply welded to the rail, and the rail moved.

The failure mode is the part worth taking seriously, because it is asymmetric. A broken checkout is loud: no money arrives and you notice within hours. Broken delivery glue is quiet: money keeps arriving, buyers stop getting invited, refunds stop revoking - and you find out from angry support tickets, one at a time.

Own the access layer, keep the payment rail swappable

The durable fix is to make the payment provider a detail. This is what I built RepoAccess around: a single Cloudflare Worker that owns delivery - grant on payment, revoke on refund or chargeback, a claim page for recovery - and treats every provider as an adapter that translates its webhooks into one internal shape:

export interface NormalizedEvent {
  event_type: 'payment_success' | 'refund' | 'chargeback'
  product_id: string
  transaction_id: string
  buyer_email: string | null
  github_username: string | null
  is_full_refund: boolean | null
}

Everything downstream of this interface - the GitHub team grants, the refund-driven revokes, the idempotency, the event log - has no idea which rail fired. The Lemon Squeezy adapter fills it from a Lemon Squeezy webhook; the Stripe adapter fills it from a Stripe one. Swapping rails means swapping the adapter and walking the new provider’s dashboard setup, and nothing else: your product-to-team mapping, your policies and your buyers’ access records stay put. The full architecture walk is in the launch write-up.

The delivery model is also built for a catalog rather than a single product. Where a tool like Lemonrepo maps one deployment to one repository through direct collaborator invites - a clean solution to a smaller problem - RepoAccess maps products to GitHub teams: one worker, many products, team-level policies, and revocation that works by reconciling against live GitHub state.

That split is what turns a platform migration from a rewrite into a configuration change. The rail is the part you should be able to change your mind about - next year, or next week, whichever way the numbers point.

Lemon Squeezy to GitHub repo access: the sale, the refund and the chargeback gap

Lemon Squeezy’s checkout has no field a buyer can type a GitHub username into; custom data there is passed by the seller. So the normal route is the claim page: the buyer pays, lands on a page the worker serves, types the username once, and gets the GitHub team invitation by email.

A refund webhook revokes that access. Whether the refund was full or partial is computed from Lemon Squeezy’s own payload, so a policy of revoking only on full refunds can be trusted.

Chargebacks are the one gap. Lemon Squeezy emits dispute events but leaves them out of its published event types, and a dispute cannot be triggered in test mode, so there is no payload to build against. In this version a Lemon Squeezy chargeback is revoked by hand.

If you stay on Lemon Squeezy

Staying is a legitimate choice, and nothing in this article argues otherwise: there is no deadline, the platform works, and as a Merchant of Record it still carries your tax and disputes. The RepoAccess Lemon Squeezy adapter is live-verified against the real platform - including the refund case that matters most under a Merchant of Record: whether a refund is full or partial is computed authoritatively from the provider’s own payload, because a partial refund that revokes access, or a full one that fails to, is money and trust lost in one event. What the adapter does with a refund and a chargeback, and how the buyer gives their GitHub username, are on the Lemon Squeezy integration page.

What staying should not mean is staying welded. Put the delivery layer in place now, while nothing is on fire, and the LS adapter becomes one plug among six. If Lemon Squeezy’s webhooks change shape mid-transition, tracking that is the maintenance job the paid tier exists to carry - not a surprise you debug during a launch week.

If the choice in front of you is staying or moving to Paddle, the Paddle vs Lemon Squeezy comparison for code sellers puts the two bills, the country lists and the refund events side by side.

If you move: the Stripe adapter is free

The other direction costs nothing to hold open. The AGPL core on npm ships the complete Stripe adapter - signature verification, grant and revoke, the claim page, the agent-run setup wizard that walks you to a live-tested deployment in about an hour.

One thing I will not promise, because I have not run it: a sale through Stripe Managed Payments. Stripe’s set-up guide turns it on with one flag on a Checkout Session and names the same payment events the core adapter already handles. That is a match on paper, not a live-verified path.

The guide also leaves one thing open: it names no refund or dispute events. Under Managed Payments that matters more than usual, because Stripe can refund a buyer itself within 60 days. Until a sandbox run confirms the revoke fires on those refunds, treat this route as likely, not proven.

What nobody knows yet, including me

The timing is still open, only on a different question. Managed Payments is public, so the unknown is no longer when it opens. It is when, or whether, Lemon Squeezy accounts get a nudge stronger than an invitation, and what that nudge says to sellers outside Stripe’s 37 countries.

Planning around an unannounced date is guessing. The point of owning your delivery layer is that you do not have to guess.

The Merchant-of-Record question is the real fork, and it deserves plain words. Moving to plain Stripe means giving up the MoR: tax registration and remittance become yours. Managed Payments keeps the MoR model, at 3.5% on top of Stripe’s fees, if your country is on its list. If it is not, the like-for-like move is to another Merchant of Record, such as Paddle, and the delivery layer serves all three routes identically.

And owning a layer is owning it. The worker runs on your Cloudflare account against your GitHub org; setup is about an hour with the wizard, and the pager for that hour and after is yours. That is the standing trade of self-hosting, and it buys the independence this whole article is about.

Where this leaves you

If your paid repos ship through Lemon Squeezy glue today, the calm move is to put the delivery layer in place before anything forces it: the RepoAccess product page carries the paid tier with the live-verified Lemon Squeezy adapter and five others. If you are heading to plain Stripe, the AGPL core is free and complete for that path. Either way, the migration stops being a rewrite of your delivery and becomes a decision about rails - which is all it ever should have been. If the rail itself is still open, every option compared lays out what each one costs and what it does when a buyer asks for their money back.