Payment Test Mode

This page covers Benecaster’s built-in membership system. If you’re using an external membership plugin — MemberPress, WooCommerce Subscriptions, Paid Memberships Pro, or Restrict Content Pro — test mode is configured in that plugin, not in Benecaster. See your membership plugin’s documentation for how to enable its test environment.

Before taking real payments from subscribers, you should test the entire signup flow — from choosing a tier to receiving the welcome email with a working feed URL — using Stripe’s test environment. Benecaster’s built-in membership makes this straightforward with a persistent Test Mode toggle and visible indicators throughout the admin.

How Test Mode Works

Benecaster stores two complete Stripe key sets independently: one for test and one for live. You enter both sets once and then switch between them with a single toggle. Switching never requires re-entering keys and never risks overwriting the wrong set.

Test Mode toggle — in Settings → Membership → Payments, the toggle labeled “Test Mode” switches the active key set:

• On (Test Mode) — Benecaster uses your pk_test_... and sk_test_... keys. No real charges occur. Stripe’s test cards work.
• Off (Live Mode) — Benecaster uses your pk_live_... and sk_live_... keys. Real charges occur.

The toggle defaults to on (Test Mode) until you explicitly switch it off.

This toggle is the DEFAULT, not the answer. A show with its own Stripe account can set its own mode and override it. So “Test Mode is on” here does not guarantee that nothing on the site is charging — see the banner below, which is the surface that answers the question properly.

Test Mode and Per-Show Stripe Accounts

A show with its own Stripe account (Shows → [show] → Settings → Payments) holds two key sets exactly as the site does, and can choose its own test/live mode independently of the site setting. That is what makes it possible to launch a third show against test keys while your first two keep billing real cards.

A show without its own keyset cannot have a mode of its own. It uses the site account, and there the key is the mode — asking the site’s live credential to behave as test is asking Stripe for something it cannot do. Such a show always follows the site default.

The same rule cleans up after itself: if a show had its own keys, set a mode, and later had those keys removed, it returns to the site default rather than continuing to claim a mode it can no longer honour.

Which mode is a show actually in?

The show’s Payments tab labels the key set currently in use, so you can confirm at a glance.

The Listener Support key fields follow the toggle too. They were a single mode-less pair; they now write the test key set when Test Mode is on and the live set when it is off, and their placeholders change to match.

This means pasting live keys into Listener Support while Test Mode is on now produces an error rather than a silent save. The message tells you the key does not match the mode. That is correct behaviour, not a bug — it is the check that stops a live key landing in the test slot, which would mean charging real cards from a test environment.

To clear it, do one of two things:

• Paste the matching key. Test Mode on wants pk_test_ / sk_test_; off wants pk_live_ / sk_live_.
• Switch mode first, at Settings → Membership → Payments, then paste the keys you meant to enter.

Nothing is saved when the check fails, so a rejected paste leaves whatever you had before untouched. If you want to enter both sets in one sitting, use Settings → Membership → Payments instead — it shows both and writes each independently, with no mode-switching in between.

What’s Visible in Test Mode

Benecaster makes test mode impossible to miss:

Payment mode banner — an always-visible banner above every Benecaster admin view, beside the staging banner. It is the one place that answers “is any show on this site taking real money through Stripe right now?”, and it has four states:

Every named show links straight to its own Payments tab.

The banner is about Stripe, not about every payment method. All four states are written in terms of shows and their Stripe keysets, and the headline follows the Stripe install default. A payment gateway add-on running in test mode does not change what this banner says. That is the correct split — the banner names shows, and a show’s mode is a Stripe question — but do not read “No show is taking real money” as a statement about a non-Stripe gateway. The TEST MODE badge is the surface that aggregates gateways, and it is described below.

The first state is the one to read carefully. “Test mode is on site-wide” is exactly the sentence a podcaster reads as “nothing is charging” — and it is not what it means once a show can override itself back to live. That is why this state is a red warning that leads with the exception rather than the setting.

Admin badge — a persistent orange TEST MODE badge appears on all Benecaster admin screens, in the top-right of the Benecaster admin header. It reports whether any payment gateway is in test mode.

It does not know about shows. For Benecaster’s own Stripe gateway it reflects the site default, so a show running in test mode on an otherwise-live install raises the banner above but produces no TEST MODE badge. If you are looking for the badge to confirm that one show is rehearsing, you will not find one — use the banner.

A payment gateway add-on in test mode also raises it, even when your Stripe site default is live. That is why the badge reads “A payment gateway is running in test mode” rather than naming Stripe — it cannot always mean Stripe.

Subscriber account page — when a subscriber views their account page while test mode is active, a prominent banner reads: “Test Mode — payments are not real on this site. Anything you enter here is for testing only.” This prevents confusion when you’re testing the subscriber experience on a development or staging site and a subscriber (or you, logged in as a test subscriber) opens the account page.

This notice follows the same signal as the admin badge, not the banner — so it does not know about shows either. The account page spans every show a subscriber belongs to, so it has no single show to ask about. Two consequences worth knowing before you treat it as confirmation:

• A show rehearsing on its own test keys shows its subscribers nothing. The site default is still live, so no notice appears. Your rehearsal is still safe — no card is charged — but do not use this notice as the check that you are in test mode. Use the banner.
• A payment gateway add-on in test mode shows the notice to everyone, including subscribers of shows that are charging real cards. The wording says “on this site”, which on a multi-show install is broader than it sounds.

Staging site warning — if Benecaster detects that the current site is a staging environment and anything on it is configured with live keys, a warning notice appears in the admin: “Live payment keys detected on a staging site.” This is a safety check — it fires independently of the Test Mode toggle, so misconfigured clones of production sites are caught even if test mode was not enabled. It now checks each show as well as the site account and names the shows at fault — see Setting Up a Staging Site.

Entering Your Keys

Go to Settings → Membership → Payments.

The form has two sections — Test and Live — each accepting a publishable key and a secret key:

Benecaster validates key prefixes at save time. Saving a pk_live_... key into the Test section, or a pk_test_... key into the Live section, is rejected with an error — this prevents silent cross-environment charges.

You don’t need to enter both sections before testing. Enter only the test keys to begin testing immediately. Add the live keys when you’re ready to go live.

Running a Test Subscription

1. Confirm you are actually in test mode for the show you are testing. If the show uses the site Stripe account, the Test Mode toggle in Settings → Membership → Payments is what decides it. If the show has its own Stripe account, check that show’s own Payments tab instead — the site toggle does not apply to it. The payment mode banner answers this without opening anything.
2. Open your subscription page (using [benecaster_subscribe]).
3. Choose a tier and proceed to checkout.
4. Use a Stripe test card — for example, 4242 4242 4242 4242 with any future expiry date and any CVC.
5. Complete the payment.
6. Verify: welcome email received, feed URL works, subscriber appears in Benecaster → Subscribers.

All activity in test mode is completely isolated from live mode. Test subscribers, test invoices, and test payment intents are not visible in your live Stripe dashboard and do not affect your live subscriber count.

Going Live

When you’re ready to accept real payments:

1. Confirm your live keys are saved in the Live section of Settings → Membership → Payments.
2. Switch the toggle off (Live Mode).
3. The orange TEST MODE badge disappears. The subscriber-facing test mode notice is gone.
4. New subscriptions will be charged via your live Stripe keys.

Switching the toggle does NOT move a show that has its own Stripe account and its own mode set. That show keeps rehearsing, and the payment mode banner will say so. This is the point of per-show mode rather than a bug — but if you meant to take everything live, go to each named show’s Payments tab and set its mode to Follow the site default, or to Live.

The badge will also stay up if a payment gateway add-on is still in test mode, which has nothing to do with Stripe. Check the badge’s wording: it names a gateway, not a mode.

Existing test subscriptions created in Test Mode are not transferred to live mode — they exist only in the Stripe test environment. Real subscribers will need to sign up fresh once you go live.

Staging Sites

If you run a staging copy of your production site, there are two separate protections and one thing you still have to do yourself.

🔴 On a site cloned from production, Benecaster refuses every billing operation outright — whatever mode the keys are in. New subscriptions, cancellations, resumes, renewal retries, buy-ups and donation intents all fail with “Billing changes are temporarily unavailable on this site.” This is not about key sets at all: a clone carries production’s real Stripe subscription IDs, which stay real whichever keys are loaded, so a cron run or replayed webhook could cancel or re-tier a paying subscriber without a penny moving. Test keys do not lift this, and that is the point.

So how do you rehearse a real purchase? Use a staging site that was installed separately — its own database, its own address, never cloned from production. Benecaster treats that as an ordinary install, so test keys behave normally and you can run the whole flow with a Stripe test card. On a clone, use the admin tools instead: creating a test subscriber from the admin does not go through billing at all. BENECASTER_IS_PRODUCTION is not the answer here — putting it on a copy disarms every protection on the one install they exist to watch. Setting Up a Staging Site covers both routes.

With that established, the key-set rules:

• You cannot use live keys on a staging site — Benecaster refuses to save them. Pasting live Stripe keys into an install detected as staging, or into one detected as a copy of another install, is rejected outright: nothing is written and the error explains why. Test keys always save, and clearing a keyset always works. If a genuine production site trips a detector, define( 'BENECASTER_IS_PRODUCTION', true ); in wp-config.php is the only way to override it — see Setting Up a Staging Site.

• The live-key warning still matters. The refusal only fires when someone saves keys. A staging copy inherited its live keys from the production database, so no save ever happened — the warning is what catches those.

• The Test Mode toggle is the site default, not a per-key-set switch and not a guarantee about every show. A live site accidentally cloned to staging retains whatever toggle state was exported with the database — and retains every per-show mode override with it. The clone guard above now stops those inherited live settings actually charging anyone from the copy, but the settings themselves are still wrong, and they will be wrong on the day you promote that database or lift its configuration back to production. Benecaster’s staging detection names the shows at fault; always verify the toggle and each show’s mode manually after a database clone.

• A separately-installed staging site has no clone protection at all. The refusal above depends on the install having recorded a different address — a staging site built fresh, with its own database, never did. It is an ordinary install as far as Benecaster is concerned, so live keys there would bill real cards normally. On that kind of site the key-set rules are the only thing protecting you.

See Setting Up a Staging Site for Benecaster’s full staging site guidance.