Resources · Getting started

Switching Stripe from test to live mode

Take real payments without breaking what you've already built in the Stripe sandbox. The single most important rule: live mode is a separate environment — nothing carries over automatically.

Why test-to-live trips everyone up

Stripe runs two completely isolated environments accessed through the same dashboard. You toggle between them with a single switch in the top of the screen, but everything you create — API keys, webhook destinations, products, prices, customers — exists only in the environment you created it in.

When you flip from test mode to live mode, none of your sandbox work follows you. The webhook destination that worked perfectly during testing? Live mode has no webhook at all. The publishable and secret keys you pasted into Site Calendar Pro? Those are test keys; live keys start with pk_live_ and sk_live_. The webhook signing secret? Different value entirely.

This catches everyone out, including us. The first time we switched our own getsitecalendar.com store to live, customers were charged successfully but the welcome email never arrived and the auto-login redirect failed — because there was no live webhook, so Site Calendar Pro never got told the payment had completed. This guide walks through every step so it doesn't happen to you.

Important — verify the sandbox works end-to-end first. Before switching to live, make sure your test mode actually completes a full ticket purchase: payment succeeds, webhook returns 200, attendee record is created, welcome email arrives. If any of those fail in test mode, they will fail in live mode too — fix them in the sandbox first. See Setting up Stripe payments for the sandbox setup walkthrough.

Pre-flight checklist

Before flipping the switch, confirm all of the following:

  • Your Stripe account is fully verified (business details, identity check, bank account linked). Stripe blocks live charges until verification is complete.
  • Your sandbox test purchase completes successfully: card 4242 4242 4242 4242 reaches the success page, webhook returns 200, attendee record appears, welcome email arrives.
  • WP Mail SMTP (or your equivalent) is configured to send transactional emails from your domain. Without this, customers won't receive ticket confirmations even when payment succeeds.
  • Your tax settings in Site Calendar → Settings → Tickets are correct for the currency and jurisdiction you'll be charging in.
  • You have a refund plan: a test purchase you can refund yourself after verification, or a willing colleague who can.

Step 1 — Toggle Stripe to live mode

Open the Stripe dashboard. Look at the top of the screen for the Test mode toggle (a small switch usually near the top-right or top-left depending on dashboard version). Click it to switch to Live mode.

The dashboard reloads. The orange "Test mode" banner across the top disappears. You're now in live mode — anything you do here uses real money.

The Test mode toggle. Off = live mode, on = sandbox. Everything below this point in the guide assumes live mode is active.
If the toggle is greyed out or shows "Activate payments to use live mode," your Stripe account hasn't completed verification. Click the prompt, fill in any outstanding business details and bank information, and try again once Stripe confirms your account is active.

Step 2 — Copy your live API keys

In the dashboard navigation, click Developers → API keys (or Workbench → API keys in newer dashboard versions). You'll see two values, both starting with _live_ instead of the _test_ prefix from your sandbox:

  • Publishable key — starts with pk_live_. Safe to expose; used by Stripe's checkout form.
  • Secret key — starts with sk_live_. Treat as a password. Never commit to public Git, never paste into a public chat, store in a real password manager (1Password, Bitwarden, your browser's vault).

Click Reveal on the secret key, copy both values somewhere you can paste them in a moment.

Both live keys live on the same page. The prefix pk_live_ / sk_live_ confirms you're looking at live values, not sandbox.

Step 3 — Create the live webhook destination

This is the step that catches everyone. In Stripe, go to Developers → Webhooks (or Workbench → Webhooks). Look at the webhook list — it's empty in live mode, even though your test-mode list has the destination you configured during sandbox setup.

Click + Add destination. Configure as follows:

  • Events from: Your account
  • Payload style: Snapshot
  • API version: leave as the default Stripe pre-selects
  • Events to listen for: select the same five events you configured in test mode

The five events Site Calendar Pro needs:

  1. checkout.session.completed
  2. customer.subscription.updated
  3. customer.subscription.deleted
  4. invoice.payment_succeeded
  5. invoice.payment_failed

Click Continue. On the destination configuration screen:

  • Destination name: Site Calendar Pro — Live (different from your test destination so you can tell them apart at a glance)
  • Endpoint URL: the same Webhook URL Site Calendar Pro shows in Settings → Tickets — usually https://yoursite.com/wp-json/pcal/v1/stripe-webhook
Same five events, same endpoint URL as your test destination — but in live mode, so it generates a fresh signing secret.

Click Create destination. Stripe opens the destination detail page. The most important field is the Signing secret — starts with whsec_ and is completely different from your test-mode signing secret.

Click the eye icon (or "Click to view") and copy the entire whsec_… string.


Step 4 — Update Site Calendar Pro with live credentials

In WordPress admin, go to Site Calendar → Settings → Tickets. You should already have your test keys saved here. Replace them with the live versions:

  • Test mode toggle: untick this
  • Publishable key: paste your pk_live_ value (overwriting the pk_test_ value)
  • Secret key: paste your sk_live_ value (overwriting the sk_test_ value)
  • Webhook signing secret: paste the new whsec_ value from Step 3 (overwriting the test-mode signing secret)

Click Save Settings.

All four credential fields swapped from test values to live values. Save Settings at the bottom of the page.
Don't forget the signing secret. The most common live-switch failure is updating the API keys but leaving the test-mode signing secret in place. Live webhooks then arrive at your site signed with the live secret, your site validates them against the test secret, the signatures don't match, and every webhook returns a 401. Symptom: customers get charged successfully, but no attendee record is created and no welcome email arrives.

Step 5 — Send a test webhook to verify

Before risking a real customer's first purchase, fire a test webhook from Stripe directly to confirm the signing secret matches and the endpoint accepts the event.

In Stripe → Developers → Webhooks, click into the "Site Calendar Pro — Live" destination you just created. Look for either a three-dot menu next to the destination header or a Send test event button. Send a checkout.session.completed test event.

Stripe shows the response in the destination's Recent deliveries section. Expected result: HTTP 200 in green, with no error body.

If the test webhook returns 401 the signing secret is wrong. Double-check you copied the live whsec_… value, not the test one. The two are similar in format and easy to mix up. If you re-paste and re-save, then re-send the test event, the next attempt should return 200.

Step 6 — Do a real test purchase

With the test webhook returning 200, run one real low-value purchase to verify the full pipeline end-to-end. Pick an event with a £1 (or your-currency equivalent) ticket, open it in an incognito browser, and complete the checkout using a real card you have access to.

Note the exact time you click Pay. Then within 30–60 seconds verify all five of:

  1. You're redirected from Stripe back to your site (the post-checkout success URL)
  2. If your setup includes auto-login (e.g., for licence purchases), the redirect drops you into the logged-in account dashboard rather than a generic thank-you page
  3. An attendee record (or licence record, depending on what was bought) appears in WordPress admin
  4. The customer (your real email address) receives the Site Calendar branded confirmation email with QR-coded PDF ticket attached, OR the welcome email with licence key, depending on which product you bought
  5. Stripe Developers → Webhooks → Site Calendar Pro — Live → Recent deliveries shows the checkout.session.completed event with HTTP 200
If all five checks pass, you're live. Refund the test purchase from Stripe → Payments → click the charge → Refund. Stripe will return the funds to your card within 5–10 business days. The attendee record will be marked refunded automatically if you've set up the refund hook (default in Pro 1.1.0+).

Step 7 — Announce or monitor as appropriate

You're now accepting real money. Two things worth doing in the first 24–48 hours:

  • Watch the first few real purchases. Check Stripe → Payments and your Site Calendar → Attendees screen periodically. Confirm webhooks return 200, emails arrive, no error logs appear in wp-content/debug.log.
  • Keep the test sandbox configured — don't delete the test-mode webhook destination or wipe the test keys from a notepad. You'll want test mode available again when you next make changes to ticketing logic, ticket prices, or webhook handlers, and recreating the sandbox from scratch is annoying.

Troubleshooting

"Customer was charged but no attendee record was created"

Almost always means the live webhook is missing or its signing secret is wrong. Check Stripe → Webhooks → Live mode. If the list is empty, you forgot Step 3. If a destination exists but Recent deliveries show 401, the signing secret in Site Calendar Settings doesn't match. Re-copy the secret from Stripe, re-save in WordPress, retest with Stripe's Send test event button.

"Customer was charged AND attendee record was created, but no email arrived"

The attendee record means the webhook fired correctly. The email failure is downstream. Check WP Mail SMTP → Email Log for the missing email — if Sent, the customer's spam folder is the next place to look. If Failed, the error message identifies the cause, usually a missing SPF/DKIM record on your sending domain.

"Test card 4242 4242 4242 4242 is declined"

You're using live keys with a test card number. Stripe live mode only accepts real cards. Either switch back to test mode for testing or use a real card for live testing.

"Stripe says my live keys are invalid"

You've pasted test keys into a field expecting live keys, or vice versa. Check the prefix: live publishable keys start with pk_live_, live secrets with sk_live_. Test keys start with pk_test_ and sk_test_.

"I switched to live mode and now my test purchases stopped working"

Expected — you can't have both modes active simultaneously on the same site. To test again, either switch Site Calendar back to test mode temporarily (untick the Live keys, paste test keys, save), or set up a staging copy of your site to keep test mode running independently of production.

"Auto-login redirect dropped me on a generic /account/ page instead of logging me in"

The webhook may have arrived after the redirect — race condition. Wait 5–10 seconds and refresh; the auto-login token should be valid for 30 minutes. If it still fails, check the webhook signing secret again. Auto-login depends on the webhook firing successfully to mint the token.

"The Test mode toggle is greyed out / Stripe says 'Activate payments to use live mode'"

Your Stripe account hasn't been verified yet. Click the prompt, complete the outstanding business and identity verification, link a bank account if you haven't. Stripe will release live mode once verification is approved (usually instant, occasionally up to 48 hours for additional review).


What's next

Stuck? Email support@getsitecalendar.com and we'll help directly. Pro licence holders get priority response.