Native Stripe integration

Bring your own Stripe account

Keylight does not replace Stripe and does not sit between you and your money. It connects to the Stripe account you already have. Stripe charges the card and deposits the funds; Keylight watches for the result and turns it into a license.

That means you keep everything that matters about owning Stripe directly: your customer records, your prices and products, your payout schedule, and Stripe’s standard processing rate of about 2.9% + $0.30 (US card pricing; rates vary by country, card type, and Stripe products used). Keylight adds only the licensing layer, at a small fraction of a percent. If you ever stop using Keylight, your Stripe account is untouched — there is no platform to migrate off, because Keylight was never the platform.

How a payment becomes a license

Once your Stripe account is connected and your Stripe products are mapped to Keylight license tiers, the issuance pipeline runs on its own:

1. A customer completes Stripe Checkout for your product.
2. Stripe emits checkout.session.completed.
3. Keylight receives the webhook, verifies its signature, and resolves which product and tier was bought.
4. Keylight mints an Ed25519-signed license lease and records it.
5. The customer is emailed the key and can retrieve it from the customer portal.

All of that happens within seconds of the payment, and none of it is code you write. There is no webhook endpoint to stand up, no signature verification to implement, no license database to host. You connect the account and map products; the pipeline does the rest.

Idempotent by design

Stripe retries webhooks — if your endpoint is briefly slow or unreachable, the same event arrives again. A naive handler that mints a license per event would issue a customer two or three keys for one purchase.

Keylight is idempotent: a given Stripe checkout session always resolves to the same license. If Stripe delivers checkout.session.completed twice, the customer still has exactly one license. This is the kind of detail that is easy to get wrong in a hand-built handler and is simply handled here.

Keeping the lifecycle in sync

Issuance is only the first event. Keylight listens for the rest of the Stripe lifecycle so the license always reflects the payment:

• charge.refunded — the license is marked revoked. See refund revocation for how that propagates to the app.
• Disputes / chargebacks — the license is revoked when the dispute is filed.
• invoice.paid — for subscription products, renewals keep the license active.
• customer.subscription.deleted — a cancelled subscription’s license stops working.

The license state and the payment state never drift apart, because the same Stripe events drive both. You do not run a reconciliation job or remember a manual step.

What this looks like end to end

For a customer buying your app, the experience is: pay through Stripe, receive a license key by email, paste it into the app (or have it activate directly), and the app unlocks. For you, the experience is: connect Stripe once, map your products, ship the SDK. The seam between payment and licensing — historically the part developers build and maintain themselves — is the part Keylight provides.

For the broader picture of why Stripe does not issue keys and what the licensing layer adds, see Stripe license keys. For how the issued key is signed, see license keys. Keylight plans start at $19/month with a free tier to test the whole Stripe-to-app flow — see Pricing.