Stripe License Keys

If you sell software and use Stripe, sooner or later you ask: “Where do I get the license key?” You search the Stripe dashboard, the API docs, the product settings — and find nothing. That is not an oversight. Stripe does not do license keys, and understanding why points directly at how to add them.

Why Stripe does not issue license keys

Stripe is a payment processor. Its job is to charge a card, run subscriptions and invoices, handle refunds, and deposit money in your bank account. It does that job extremely well, and it deliberately stops there.

A license key is a different kind of object. It is not a payment record — it is an entitlement: a statement that a particular customer is allowed to run a particular product, on a certain number of devices, until a certain date. Producing and enforcing that entitlement requires cryptographic signing, a key store, device-activation tracking, offline verification logic in your app, and revocation handling. None of that is payment processing, so none of it is in Stripe.

Stripe gives you exactly one thing you need to build licensing: a reliable signal that a payment happened. That signal is the webhook. Everything else is the licensing layer’s job.

The Stripe webhook is the trigger

When a customer completes a purchase, Stripe emits events. The two that matter for licensing are:

• checkout.session.completed — a one-time purchase or the start of a subscription via Stripe Checkout succeeded.
• invoice.paid — a subscription invoice (including renewals) was paid.

And for keeping a license in sync afterwards:

• charge.refunded — the customer was refunded; the license should be revoked.
• customer.subscription.deleted — a subscription ended; a subscription license should stop working.

The licensing flow is: Stripe fires checkout.session.completed → something receives that webhook → it mints a license key → it delivers the key to the customer. To add license keys to Stripe, you need that “something” in the middle.

Option one: build the middle layer yourself

You can write the webhook handler. In outline, it means standing up an endpoint that:

1. Receives the Stripe webhook and verifies the signature (so attackers cannot forge a payment event).
2. Handles idempotency — Stripe retries webhooks, and you must not issue two keys for one purchase.
3. Resolves which product and plan the customer bought.
4. Mints and signs a license — generate an entitlement payload, sign it with an Ed25519 private key, store it.
5. Delivers the key by email and exposes it in a customer-accessible page.
6. Listens for charge.refunded and customer.subscription.deleted to revoke.
7. Serves an activation/revalidation API that your app calls.

It is buildable. It is also a real service with a database, a secret signing key to manage, an email pipeline, and an uptime expectation — code you own and maintain for as long as the app sells. For many small teams that is more infrastructure than the feature is worth.

Option two: a licensing layer connected to Stripe

The alternative is a purpose-built licensing layer that already implements the middle. You connect it to your Stripe account once, and it provides the webhook handling, signing, delivery, and revocation as a managed service.

Keylight works this way. You connect your existing Stripe account and map your Stripe products to Keylight license tiers. From then on:

• Stripe fires checkout.session.completed; Keylight receives it (signature-verified, idempotent) and mints an Ed25519-signed lease.
• The customer is emailed the key and can retrieve it from a customer portal.
• A refund in Stripe (charge.refunded) marks the license revoked automatically.
• For subscriptions, the license tracks the subscription’s lifecycle — issued on the first invoice, revoked when it ends.

You keep your own Stripe account, your prices, and your customer data. Stripe’s processing rate is unchanged; the licensing layer adds only a small fraction of a percent for the licensing itself.

A Keylight signed key carries its entitlement and a signature:

{
  "id": "lk_01hx9z4bqncktjvx6a2r3p8wy",
  "customerId": "cus_Qk3mN9vTpLx2Zr",
  "productId": "prod_myapp_pro",
  "plan": "pro",
  "activationLimit": 3,
  "issuedAt": "2026-05-15T09:12:00Z",
  "expiresAt": null,
  "revoked": false,
  "sig": "base64url(ed25519_signature)"
}

Because the key is signed, your app verifies it locally — no call back to a server on launch. See offline license validation for why that matters and software license keys explained for the deeper model.

Reading the key in your app

The other half of “Stripe license keys” is the app side. Once a key exists, your app has to check it. Keylight’s Swift SDK reduces that to a manager and a state switch:

import KeylightSDK

let licensing = try! Keylight.manager(
    sdkKey: "sdk_live_...",
    tenantId: "acme",
    productId: "myapp",
    keyPrefix: "ACME",
    trustedPublicKeyBase64: "<your-public-key>",
    trialDurationDays: 14,
    branding: .init(appName: "My App", purchaseURL: URL(string: "https://acme.example.com/buy")!, supportEmail: "[email protected]", tintColor: .blue)
)

await licensing.checkOnLaunch()

switch licensing.state {
case .licensed:
    enablePaidFeatures()
case .trial(let daysLeft):
    showTrialBanner(daysLeft: daysLeft)
case .expired:
    showRenewalPrompt()
case .invalid:
    showActivationSheet()
}

When a customer pastes a key into your activation UI, you call activate(key:); the SDK verifies the signature, registers the device against the key’s activation limit, and updates licensing.state.

The summary is simple: Stripe handles the money, a licensing layer handles the keys, and a Stripe webhook is the seam between them. If you would rather not build and maintain that seam, Keylight provides it — plans start at $19/month with a free tier to test end to end. See Pricing, and the Stripe vs Paddle comparison if you are still choosing how to take payment at all.