Stripe & test mode

How WolfieAuth handles Stripe under the hood, how to test billing end-to-end with fake cards, and the checklist for going live with real money.

Stripe & test mode — testing your billing before going live

TL;DR: WolfieAuth uses Stripe Connect, so money flows to your org’s Stripe account, not to a platform pool. Run your app’s billing flow in Stripe test mode first (test cards work, no real money moves), verify the full lifecycle (checkout → webhook → subscription active → invoice → emails), then switch your Connect account to live keys when you’re confident. This page walks the whole flow.

How money actually flows

When a customer subscribes to your app’s plan:

Customer hits your /pricing page or the @wolfieauth/sdk-paywall picker
     │
     ▼
WolfieAuth creates a Stripe Checkout session against YOUR Connect account
(uses your account's Stripe key, not the platform's)
     │
     ▼
Customer pays with card / SEPA / etc — money lands directly in YOUR Stripe balance
     │
     ▼
Stripe sends webhook to WolfieAuth → subscription row created → wolfieauth_plans claim updated
     │
     ▼
On the customer's next OIDC token mint, your app sees the new plan in the claim
     │
     ▼
Once a month: WolfieAuth issues a small platform-fee invoice to your org separately

You never write Stripe code yourself. WolfieAuth handles checkout, webhooks, subscription state, prorations, retries, refunds — all sitting on top of YOUR Connect account so you keep ownership of the customer relationship and the funds.

Two sides of the test/live coin

WolfieAuth itself runs on Wolfie’s infrastructure with platform-side Stripe keys (the platform fee mechanic). What you control as an app owner is your own Stripe Connect account — and that’s where test mode matters for you.

A Stripe Connect account is either in test mode or live mode. The two are entirely separate worlds — separate balances, separate customers, separate webhooks. You can’t migrate data between them. So: do all your testing on a test-mode Connect account, then onboard a live-mode one when you’re ready for real money.

Test mode: end-to-end walkthrough

1. Connect a test-mode Stripe account

In WolfieAuth admin → /admin/organizations/<your-org> → Stripe tab → Connect Stripe account.

When you click through to Stripe’s onboarding, make sure you’re toggled into test mode in the Stripe dashboard (top-right corner). The account-link Stripe creates inherits the mode you’re currently in. Onboarding in test mode skips KYC verification — you can complete it with junk data in seconds.

When you come back, you’ll see chargesEnabled: true (test) next to the org. From this point on, every checkout WolfieAuth creates against this org goes through Stripe test mode.

2. Create your plans and prices

/admin/clients/<your-app>/plans → + New plan. Name it, give it a slug, optionally tag features:

Name:       Pro
Slug:       pro          (auto-derived from name)
Features:   ["ksef_enabled", "advanced_reports"]

Add a price (one or many — you can have monthly + annual + per-currency):

Amount:     99.00
Currency:   PLN
Interval:   month
Per-seat:   off

Click Sync to Stripe — WolfieAuth provisions the Product + Price on your test Connect account. You should see the Stripe Price ID appear next to the price row.

3. Run a test checkout

Two ways:

The hosted pricing page:

https://auth.wolfieguard.com/billing/<your-app-clientId>

Public URL — no login required. Pick a plan, click “Subscribe.”

Embedded in your app via the paywall SDK:

// hooks.server.ts (SvelteKit) — see /sdks/ for other stacks
import { createWolfieAuthHandle } from '@wolfieauth/sdk-sveltekit/server';

export const handle = createWolfieAuthHandle({
  paywall: {
    enabled: true,
    plans: await fetch(`${ISSUER}/api/billing/${CLIENT_ID}/plans`).then(r => r.json()),
    allowSkip: false,
  },
});

At Stripe’s Checkout page, use a test card:

Full card list: https://stripe.com/docs/testing#cards.

4. Verify the webhook landed

After paying, Stripe fires checkout.session.completed and (a few seconds later) customer.subscription.created to WolfieAuth. The customer’s subscription should appear in /admin/clients/<your-app>/users with status ACTIVE.

To inspect what Stripe actually sent:

• Stripe dashboard → Developers → Events (test mode) — full payload + delivery log.
• WolfieAuth admin → /admin/clients/<your-app> → recent activity panel.

If the webhook didn’t arrive, the most common cause is that the customer’s currentPlanSlug in OrgCustomer is still empty after 30 seconds. Check Stripe’s “Events” log for delivery errors and compare to the WolfieAuth webhook URL registered in your Connect account’s settings.

5. Simulate the rest of the lifecycle

Stripe’s CLI lets you fire any webhook event without waiting for a real billing cycle:

stripe login                                          # one-time, opens browser
stripe trigger invoice.payment_succeeded              # mints a paid invoice
stripe trigger invoice.payment_failed                 # → subscription goes PAST_DUE
stripe trigger customer.subscription.deleted         # → cancellation cascade
stripe trigger customer.subscription.updated \
  --override "items[0].price=<your-test-price-id>"   # plan switch / upgrade

Each one fires against your test-mode account and exercises WolfieAuth’s webhook handler. You can verify the resulting state in /admin/clients/<your-app> or by reading the user’s OIDC claims:

curl -H "Authorization: Bearer <user-access-token>" \
     https://auth.wolfieguard.com/me | jq .wolfieauth_plans

6. Test the email + invoice path

When invoice.payment_succeeded fires, WolfieAuth calls into your CRM tooling (if you’ve wired it up) to issue a customer-facing invoice. In test mode:

• If your CRM is also in test mode, you get test invoices. Numbers may use a separate sequence (TEST/2026/…) so they don’t pollute your live invoice numbering.
• If your CRM is in live mode, you’ll get a warning in WolfieAuth logs and the invoice step is skipped — best-effort, doesn’t break payment processing.

Email notifications follow the same rule: in a test deployment, point your SMTP host at a sink (Mailpit, MailHog) and watch what would have been sent without delivering anything to real inboxes.

Going live — checklist

Once test-mode end-to-end works, switching to live is mechanical:

1. Re-do Stripe Connect onboarding in live mode. Toggle Stripe’s dashboard into live mode and click Connect again from WolfieAuth admin. This creates a brand-new live Connect account — your test account stays untouched and usable for ongoing testing.
2. Re-create your plans and prices on the live account. WolfieAuth’s “Sync to Stripe” button creates Stripe Products + Prices on whichever Connect account is currently linked. Run it again on the live one. Slugs and feature tags carry over automatically (they live in WolfieAuth’s DB, not Stripe).
3. Verify webhook URL. Connect accounts inherit WolfieAuth’s webhook config — there’s nothing to register manually on your side. Just confirm the org now shows chargesEnabled: true (live) in the admin panel.
4. Test with a real card for €1. Issue yourself a refund right after — proves end-to-end without real exposure.
5. Update your app to point at the live pricing page. If you hardcoded https://auth.wolfieguard.com/billing/<your-app>?mode=test anywhere, drop the param.

You can leave the test Connect account in place forever — it’s the right home for exploratory work, demo data for sales calls, and pre-production validation of new plans before you sync them live.

Things that DON’T change between test and live

You shouldn’t have to touch any of these:

• Your OidcClient client_id and client_secret — same in both modes. WolfieAuth itself doesn’t have separate test/live modes per-app.
• OIDC scopes, redirect URIs, claim shapes — identical.
• Plan slugs, feature flags, role mappings — these live in WolfieAuth’s DB, not Stripe.
• Your app’s code — no if (testMode) branches needed; the SDK doesn’t know or care.

When something looks wrong

Continue reading

• Plans & Billing overview — pricing models, per-seat, comp overrides
• SDKs — paywall — embedding checkout in your app
• SSO & Sessions — how the plan claim flows back into the user’s token

Last updated: 2026-05-03