Automatic revocation on refund

Why revocation has to be automatic

Issuing a license when a customer pays is the easy half of licensing. The other half is taking it back when the payment is reversed — and if that half is manual, it gets skipped. A developer who has to remember to log in and revoke a key every time they process a refund will, eventually, forget. The result is a paid-feature key in the wild that was never paid for.

Keylight makes revocation automatic so it cannot be forgotten. The same Stripe events that move money are the events that move license state.

Refunds and chargebacks

Two Stripe events trigger revocation.

Refunds. When you refund a customer in Stripe, Stripe emits a charge.refunded event. Keylight receives it, finds the license tied to that payment, and sets its revoked flag. The customer’s key is now invalid. You did nothing beyond clicking refund in Stripe.

Chargebacks. When a customer disputes a charge with their bank, Keylight revokes the associated license as soon as the dispute is filed — not after it resolves — because a filed chargeback is already an adverse signal and the outcome is frequently against the merchant.

In both cases the license state stays in lockstep with the payment state. A reversed payment always means a revoked license, with no window where the two disagree because someone forgot a step.

The revoked flag is signed

Revocation in Keylight is not a row in a database the app has to query. The revoked field is part of the signed lease — the same Ed25519-signed document that carries the entitlement.

{
  "id": "lk_01hx9z4bqncktjvx6a2r3p8wy",
  "productId": "prod_myapp_pro",
  "plan": "pro",
  "revoked": true,
  "issuedAt": "2026-05-15T09:12:00Z",
  "sig": "base64url(ed25519_signature)"
}

Because the signature covers revoked, a customer cannot flip it back to false to keep using the app — editing the field invalidates the signature and the app rejects the lease outright. When Keylight revokes a license, it reissues the lease with revoked: true and signs it. The app trusts that flag the same way it trusts every other field: by verifying the signature locally.

How revocation reaches the app

Keylight is offline-first: your app verifies the signed lease locally on every launch, with no server call. That is what lets the app launch on a plane. The consequence is that revocation is not instantaneous — the app cannot learn about a server-side change while it is offline.

The app revalidates online periodically — typically every few days, in the background, when a connection is available. On that revalidation it receives the updated lease with revoked: true, and transitions to an unlicensed state:

await licensing.checkOnLaunch()

switch licensing.state {
case .licensed:
    enablePaidFeatures()
case .expired, .invalid:
    // A revoked license resolves here after the next online revalidation
    showRenewalPrompt()
default:
    break
}

A refunded customer who stays offline keeps a working app until that next online check. In practice almost everyone reconnects within hours, so revocation propagates within days. This is the deliberate tradeoff of offline-first licensing — instantaneous revocation would require a server call on every launch, which would break offline use for every honest customer. Offline license validation covers that balance in full.

Refund revocation is part of the Stripe integration that runs with no code from you — see Stripe integration for the full event pipeline, and license keys for how leases are signed. Keylight plans start at $19/month; see Pricing.