Migrating from Paddle to Keylight

This page is for developers currently selling through Paddle who are considering a move to Stripe plus Keylight. The usual reasons are lower fees and wanting to hold the customer relationship directly rather than through a platform intermediary. This guide walks the migration honestly — what gets better, where it adds responsibility, and how to carry existing customers across without disrupting them.

Why developers move off Paddle

Paddle is a merchant of record. It charges a margin on top of underlying payment processing to cover VAT and sales tax remittance, fraud handling, and the checkout it provides. For early-stage apps that benefit from not thinking about compliance, that bundle is useful. For apps generating consistent revenue, the merchant-of-record fee becomes a meaningful cost per transaction — and it compounds at scale.

Beyond fees, the customer and payment data sits inside Paddle’s platform. Purchase history, customer email addresses, and payment methods live in their systems, accessible only through their export tools and APIs. If you later want to switch platforms, re-engage customers, or get a direct view of your revenue, you work within what Paddle lets you access. See the Paddle alternative comparison for a fuller breakdown of the model differences, and Stripe vs Paddle for how a direct payment processor compares to a merchant-of-record bundle.

The common push factors are fees that feel disproportionate to the value, wanting direct access to customer data, and not wanting a third party with leverage over infrastructure your revenue depends on.

What changes when you switch

The upside is real: lower fees, customer data sitting in your own Stripe account, and no platform intermediary that can alter terms or pricing on infrastructure you depend on. But this move comes with a genuine tradeoff, and it is in tax handling.

Paddle remits VAT and sales tax for you as a merchant of record — that is a core part of what the fee pays for. When you switch to your own Stripe account, that responsibility transfers to you entirely. You will need to understand where you have tax nexus, register in the relevant jurisdictions, and either configure Stripe Tax to collect and calculate correctly or engage an accountant to handle remittance and filing.

This is real operational work, not a footnote. For developers selling to customers in the EU, VAT registration and the One Stop Shop scheme are non-trivial to set up correctly. Stripe Tax reduces the calculation burden significantly, but compliance remains yours. If your current Paddle arrangement mainly appealed because you never had to think about tax, that factor belongs in your decision. For developers who are already handling tax registration, or who sell primarily in a single jurisdiction, the overhead is much more manageable.

The other changes are straightforwardly positive: you set your own checkout, you own the customer record, and no platform can modify your pricing model unilaterally.

Migrating your customers and licenses

Paddle allows you to export your customer and order data. That export is the starting point for the migration. Each customer who purchased your app needs a Keylight license key — a cryptographically signed key your app verifies offline, issued with the same activation limit the customer originally purchased.

The migration flow for existing customers is one upload: export the list from Paddle, 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; no one is asked to repurchase. See the full migration guide.

New purchases after you switch go through Stripe checkout with Keylight handling key issuance automatically — a completed payment mints a signed key and delivers it to the customer without any manual step. Existing customers are a one-time import. Once each customer has activated with their new key, the migration is complete from their perspective.

The migration process, step by step

1. Connect your Stripe account to Keylight via Stripe integration. Keylight uses your account to receive payments and trigger key issuance — this step must be completed before any others.
2. Recreate your products and prices in Stripe. Mirror the tiers you sold through Paddle: personal license, team license, any volume variants. Set the activation limits in Keylight to match what customers originally purchased.
3. Import existing customers into Keylight using the export from Paddle. Map each order to the appropriate license tier and activation limit.
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 point at your new Stripe-powered checkout. Update your website, any app store pages, and all purchase confirmation flows.
6. Keep Paddle live briefly for in-flight orders and any refund requests while you complete the transition, then close it once that queue is clear.

The steps are sequential — Stripe must be connected before you can issue keys or accept new payments. The customer import can run alongside product creation once Stripe is connected.

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 automatically and delivers it to the customer — nothing to trigger manually. For customers imported from Paddle during migration, you issue keys through the Keylight dashboard and send them in bulk.

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 — no server call 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 license.

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