Migrating from Gumroad to Keylight

This page is for developers who started selling their app on Gumroad and have outgrown what its license key system offers. Gumroad works well for an early launch, but its keys are basic — a plain string verified by calling Gumroad’s API, with no offline verification, no device limits, and no automatic revocation on refund. This guide walks through what changes when you move to Keylight on your own Stripe, including the responsibilities that come with it.

Why developers move off Gumroad

Gumroad suits a first product launch. It is quick to set up, handles payments, and gives you a storefront with minimal friction. Its license key feature ships with it: after a purchase, Gumroad generates a key string the customer can enter in your app. To validate it, the app calls Gumroad’s API and receives a yes or no.

That model works at the beginning, but it has real limits. The key is a plain string with no cryptographic structure — verification requires an active connection to Gumroad’s server. There is no mechanism for device activation limits, so one key can run on any number of machines. There is no automatic revocation when a customer requests a refund — handling that requires a manual step. The customer relationship also sits with Gumroad: purchase history and email addresses are in Gumroad’s system, not yours.

For an app that is growing, these gaps become tangible: customers can share keys freely, offline validation is not possible, and switching platforms later means working with whatever Gumroad lets you export.

What changes when you switch

The shift to Keylight on your own Stripe changes the licensing model substantially. Keys become cryptographically signed documents the app verifies locally — no server call needed on each launch. See software license keys for a detailed explanation of how signed keys work. Device activation limits become enforceable, with a server-side activation record and automatic refund-driven revocation when a customer is issued a refund in Stripe. You own the customer data directly in your Stripe account.

The tax tradeoff is real and worth stating plainly. Gumroad acts as a merchant of record: it collects and remits VAT and sales tax on its sales, and that service is part of what its fee covers. When you switch to your own Stripe account, that responsibility transfers to you. You will need to understand where you have tax nexus, register in the relevant jurisdictions, and configure Stripe Tax to calculate and collect correctly — or work with an accountant to handle remittance. For EU-based developers selling to EU customers, VAT rules are non-trivial. This is not a footnote; it is a genuine operational responsibility. If not having to think about tax is the primary reason Gumroad has worked for you, factor that into your decision.

The other changes are straightforwardly positive: you set your own checkout experience, own the customer relationship, and no platform intermediary can alter your terms or pricing model.

Migrating your customers and licenses

Gumroad allows you to export your customer and purchase data. That export is the starting point for migrating existing customers. Each person who purchased your app needs a Keylight license key — a cryptographically signed key tied to the same activation limit they originally purchased.

The migration flow for existing customers is one upload: export the list from Gumroad, then use Licenses → Import in Keylight. Include each customer’s existing key to preserve it — they keep the key they have — or leave it blank and Keylight generates one. Every imported license is tagged Migrated. Only customers whose key was generated need an email with their new key; no one is asked to repurchase. See the full migration guide.

New purchases after you switch flow automatically: a completed Stripe payment triggers Keylight to mint a signed key and deliver it to the customer without manual steps. Existing customers are a one-time import. Once a customer has activated with their new key, the migration is complete from their side.

The migration process, step by step

1. Connect your Stripe account to Keylight via the Stripe integration. Keylight uses your account to receive payments and trigger key issuance — this must be in place before any other step.
2. Recreate your products and prices in Stripe. Mirror the tiers you sold on Gumroad — single-user license, multi-seat, any variants — and set the corresponding activation limits in Keylight for each tier.
3. Export your customer list from Gumroad and import it into Keylight. Map each order to the appropriate license tier, matching the activation limit each customer originally purchased.
4. Import your existing customers from Licenses → Import — include each customer’s current key to preserve it, or leave it blank to generate one. Customers who kept their key need no email.
5. Switch your checkout and download links to your new Stripe-powered checkout. Update your website, your app’s purchase flow, and any transactional emails that reference Gumroad links.
6. Keep Gumroad live briefly for any in-flight orders or pending refund requests, then close it once the queue is clear. There is no urgency to close immediately — an orderly wind-down prevents edge cases.

The steps are sequential in the first three: Stripe must be connected before you can issue keys, and importing customers requires the product tiers to already exist in Keylight. Sending emails to existing customers can overlap with updating your public checkout links.

Doing it with Keylight

Keylight connects to your own Stripe account and listens for successful payments. When a payment completes, Keylight mints a signed key and delivers it to the customer automatically — nothing to trigger manually. For the existing customers imported during migration, you issue keys through the Keylight dashboard and send them in a batch.

On the app side, the Swift SDK activates a customer-entered key with a single call:

import KeylightSDK

// Activate a customer-entered key on this device
await licensing.activate(key: enteredKey)

switch licensing.state {
case .licensed:
    enablePaidFeatures()
case .invalid:
    // activationError carries the reason — e.g. activation limit reached
    showActivationError(licensing.activationError)
default:
    break
}

After activation, the SDK holds a signed lease the app verifies locally on every subsequent launch — see offline license validation for how that works. No server call is needed for day-to-day validation. If a customer hits their activation limit, the server rejects the request and the SDK surfaces the reason through activationError, so the app can prompt them to deactivate an old device or upgrade their plan.

Pricing starts at $19/month with a free tier that lets you test the complete flow — key issuance, activation, and offline verification — before going live.