Moving Your App's Licensing Off Gumroad

Gumroad is a fast way to start selling an app — checkout, hosting, and a basic license-key endpoint in an afternoon. The trouble shows up later, when licensing becomes a real surface: customers on planes, device limits, refunds, tiers. Gumroad’s keys were never built for that depth. This is a how-to for moving your licensing to a dedicated layer — Stripe for payments, Keylight for licensing — without breaking a single existing customer.

Why move licensing off Gumroad

To be fair to Gumroad: it is a genuinely good way to get a first version selling, and for some products it is enough forever. The case for moving is specific, not a dunk.

Merchant-of-record fees add up. Gumroad is a merchant of record, which is convenient — they handle tax — but you pay for it, and at volume that cut is meaningfully larger than processing your own payments through Stripe. The hidden cost of “free” licensing covers that math.

The license keys are thin. Gumroad can issue and verify a key, but it is a server lookup, not a signed offline-verifiable lease. There is no real device-activation model, no offline verification, limited control over entitlements and tiers, and coarse revocation. The moment your app needs to work offline or enforce a per-device limit, you are building that layer yourself on top of a key endpoint that was not designed for it.

Your licensing is coupled to your store. With Gumroad, where you sell and how you license are the same system. Decoupling them — payments in one place, a licensing control plane in another — means you can change either without touching the other.

None of this requires abandoning Gumroad’s checkout if you like it. The point is to stop using it as your licensing system.

The rule that makes migration safe

There is exactly one rule, and the whole migration is organized around it: no existing customer should have to do anything beyond a normal activation. No re-purchase, no support email, no “sorry, enter this new key.” If a current customer relaunches your app after the switch and it just works, you migrated correctly. If they get locked out, you did not.

That rule is achievable because a Keylight license is a self-contained signed lease, and you can mint leases for customers who already exist before they ever touch the new system. The migration is three steps, in order: get the existing customers in, point new sales at the new path, and let existing apps bootstrap themselves onto Keylight quietly. The same approach is covered from the customer-data angle in importing an existing customer base.

Step 1 — import your existing customers

Export your customers and their license keys from Gumroad. Then bulk-import them into Keylight so each existing customer becomes a license record with a real signed lease behind it. You can preserve the original key strings, so the key a customer already has on file keeps working — they do not get a new one.

Imported licenses are tagged with a provenance flag (think of it as “Migrated”) so you can always tell a migrated customer from a native Stripe sale. That flag is a label, not a lesser status — a migrated license is a full license. It just records where the customer came from, which is useful later for analytics and for reasoning about edge cases.

After this step, every paying Gumroad customer exists in Keylight with a valid lease, even though their app has not connected to Keylight yet. That gap is closed in step three.

Step 2 — point new sales at Stripe and Keylight

For sales going forward, set up the path you actually want: Stripe checkout for payment, with Keylight minting the signed key on the purchase webhook. When a new customer buys, Stripe fires the webhook, Keylight mints and emails the key, and the customer activates — no Gumroad in the loop.

If you would rather keep Gumroad’s checkout for now, you can: forward Gumroad’s purchase webhook to Keylight so it mints a Keylight key on each Gumroad sale. Either way, the outcome is the same — new customers get a proper Keylight lease from day one. Switching the storefront is a payments decision you can make on your own timeline; the licensing layer does not care where the sale happened.

Step 3 — bootstrap existing customers’ devices

This is the step that honors the rule. Your migrated customers exist in Keylight now, but their installed app has never spoken to Keylight — it has no on-device lease yet. It needs to claim one, once.

There is no magic auto-migration inside the app; the device bootstraps by calling activate(key) with the key the customer already has, which exchanges it for a signed Keylight lease and stores it. The cleanest way to trigger that is in your next app update: on launch, if there is no Keylight lease but the app finds the customer’s existing key (in your old storage, or entered once), call activate to claim the lease silently. From then on the app is fully on Keylight and verifies offline like any native customer. The mechanics of that one-time bootstrap — and the three patterns for triggering it — are covered in migrating to Keylight.

Once your installed base has updated and bootstrapped, every customer is on Keylight, old and new, and you can wind down Gumroad’s licensing role entirely.

---

Moving licensing off Gumroad is not a risky rip-and-replace if you sequence it right: import first so every customer exists, switch new sales, then let installed apps bootstrap themselves with the keys customers already hold. Payments stay simple — Stripe, or even Gumroad’s checkout if you like it — and licensing moves to a layer built for offline keys, device limits, and clean revocation. There is a storefront-specific overview on the migrate from Gumroad page. If your Gumroad setup has a wrinkle this post does not cover, send us your feedback and we’ll map the migration with you.