Testing WooCommerce Payments: Sandbox Mode Before You Go Live
Catch checkout breakage early with a repeatable script for WooCommerce test payments: sandbox mode, 3D Secure, refunds, subscriptions and staging sites.
Photo: Pixabay
On this page 6 sections
- Test Mode, Sandbox and Staging: What Each Is For
- Turning on WooPayments Test Mode, Stripe and PayPal Sandboxes
- Run WooCommerce Test Payments With a Repeatable Checkout Script
- Testing Subscriptions Without Renewing Real Customers
- WooCommerce Staging Site Payments: Duplicate Webhooks and Live Keys
- A Pre-Update Checklist for Plugins, Themes and WooCommerce Core
Key takeaways
- Run test payments on a staging copy in test mode. Live keys never belong on staging, and test mode never belongs on a store real customers can reach.
- A complete checkout test has two halves. The WooCommerce order status and the gateway's test dashboard both have to show the right result, or the test failed.
- Subscription renewals are the riskiest thing a staging copy can do. Confirm automatic payments are paused there before you touch anything else.
- After launch, one small live order on your own card confirms deposits work. Repeated live test charges can look like card testing to your processor.
WooCommerce test payments let you run a full checkout without moving real money, including approvals, declines, 3D Secure challenges and refunds. To do it, turn on your gateway's test or sandbox mode and use the test card numbers that gateway publishes. Then run the same short script every time you add a gateway, update a plugin or copy the store to staging. One rule prevents most disasters: a staging copy should never hold live keys, and a live store should never sit in test mode where customers can reach it.
The rest of this piece is that script, plus the staging and subscription traps that catch store owners who already know how to flip the test toggle.
Test Mode, Sandbox and Staging: What Each Is For
These three terms get used interchangeably, but each controls something different.
Test mode is a setting inside your payment plugin. It swaps your live API keys for test keys, so transactions go to the processor's test environment instead of the card networks. No card is charged and no money settles.
A sandbox is the processor's separate test environment. Some gateways keep test and live data in the same account behind a toggle. Stripe works this way, and you switch its dashboard between test and live data. Others, like PayPal and Authorize.net, give you a separate sandbox account with its own login and credentials. Either way, the plugin needs the matching test credentials.
A staging site is a copy of your WordPress store where you can break things. Most managed WordPress hosts offer one-click staging. Staging protects your code and your live orders. Test mode protects the money. You want both at once: a staging copy running in test mode.
Test mode on your production store is fine for one case: a brand-new store before launch, with no customers. On a store that's already selling, test mode is dangerous. A real customer who checks out during that window can get an order marked as paid when no payment was taken. Fulfillment ships it, and you find out at reconciliation.
Turning on WooPayments Test Mode, Stripe and PayPal Sandboxes
Menu names move between plugin releases, so check each plugin's current documentation for the exact path. The logic stays the same.
WooPayments
WooPayments test mode lives in the plugin's payment settings. Depending on your version and how the account was set up, you may be asked to create a separate test or sandbox account instead of toggling a single switch. Once it's on, WooPayments shows a test mode notice in the admin. Look for that notice before every test session. If it's missing, you're about to charge a real card.
WooCommerce Stripe Test Mode
The Stripe plugin for WooCommerce stores a test key pair and a live key pair separately. Stripe labels test keys with "test" in the key prefix, which makes a misplaced key easy to spot. Turn on test mode, paste the test keys, and register a test-mode webhook (more on webhooks below). In the Stripe dashboard, switch to test data, or your test orders will look like they vanished.
PayPal
The WooCommerce PayPal Payments plugin has a sandbox setting that connects to a PayPal developer sandbox account. You'll create sandbox buyer and seller accounts, then log in as the sandbox buyer at checkout. Our WooCommerce PayPal Payments plugin guide covers the live setup.
Authorize.net and NMI
Both Authorize.net and NMI offer test environments for developers and merchants. Test credentials come from the gateway or from the provider that set up your account.
Where to Find Test Credit Card Numbers for WooCommerce
Every gateway publishes its own test card list in its developer or testing documentation. Use the list for the gateway you're actually testing, because cards from one gateway won't behave the same way on another. A good list includes:
- a card that always approves
- cards that decline for specific reasons, such as insufficient funds, expired card or incorrect CVC
- a card that triggers a 3D Secure challenge, and one that fails it
- a card that can be saved but declines on later charges, which is useful for subscriptions
Never type a real card number into a store in test mode. It won't work, and real card data has no business on a staging server.
Run WooCommerce Test Payments With a Repeatable Checkout Script
A test passes only when both sides agree. The WooCommerce order has the right status, notes and emails, and the gateway's test dashboard shows a matching transaction for the same amount, tax and shipping included.
| Test | What to do | A pass looks like |
|---|---|---|
| 1. Approved card | Guest checkout, physical product with shipping | Order goes to Processing, customer and admin emails send, gateway shows matching amount |
| 2. Decline | Use a decline test card | Clear error on checkout page, order not marked Processing, no fulfillment email |
| 3. 3D Secure, completed | Use the challenge card, finish the challenge | Challenge window appears on desktop and phone, order goes to Processing |
| 4. 3D Secure, failed | Use the challenge card, fail or close it | Order stays unpaid, customer can retry with another card |
| 5. Saved card | Log in, save a card, buy again | Second order charges the saved card without re-entry |
| 6. Full refund | Refund order 1 from WooCommerce admin | Gateway shows the refund, order status changes to Refunded |
| 7. Partial refund | Refund one line item | Refunded amount matches in both places, order note records it |
| 8. Digital wallets | Check Apple Pay and Google Pay on supported devices | Buttons appear and complete a payment |
Run the script on the checkout your customers actually see. If you use the block-based checkout, test that, not the classic shortcode page. Payment plugins don't always behave the same way on both, as our article on checkout block compatibility for payment plugins explains. Test on a phone too, because 3D Secure windows and wallet buttons fail on mobile more often than on desktop. For row 3, our page on 3D Secure authentication explains what the challenge does and why issuers ask for it.
Watch for one result in particular. If the gateway dashboard shows an approved payment but the order sits in Pending payment, the payment worked and the webhook that tells WooCommerce about it didn't arrive. That's almost always a configuration problem, and it's the subject of our guide to orders stuck on pending payment. Refund behavior varies by gateway too. If row 6 fails, check whether your plugin supports automatic refunds through the gateway or expects you to refund manually.
One live order, not ten. After go-live, place one small order with your own card, confirm it lands in your deposit, then refund it. Whether you get the original processing fee back on a refund depends on your processor's pricing, so expect it may cost a few cents. Don't run a string of small live charges. Processors watch for that pattern because it looks like card testing attacks.
Testing Subscriptions Without Renewing Real Customers
Recurring billing adds tests that a one-time checkout never exercises. In test mode on staging, create a subscription product with the shortest billing interval your subscription plugin allows. Then work through these four checks:
- Sign up with an approving test card and confirm the parent order and the subscription both activate.
- Trigger a renewal by hand from the subscription's edit screen. WooCommerce Subscriptions includes a renewal action in its admin actions menu, so you don't have to wait a day. Confirm a renewal order is created and paid in the gateway's test dashboard.
- Switch the customer to a card that saves but declines on later charges. Run the renewal again and confirm the failed-payment email goes out and the subscription moves to on-hold.
- Change the payment method from the customer's My Account page, renew again, and confirm the new card is charged.
The real danger is a staging copy that still has live keys and live subscriber tokens. If renewals fire there, your actual subscribers get charged, sometimes twice: once by production and once by the copy. WooCommerce Subscriptions tries to prevent this. When it detects the site URL has changed, it pauses automatic renewal payments on the copy and shows an admin notice about a duplicate site. On staging, leave that pause in place. The reverse matters after a migration or a staging push. If production ends up in that paused state, renewals stop without warning, and you only notice when recurring revenue drops. Check the notice after every move.
If you're testing because you're changing processors, read switching WooCommerce subscriptions to a new payment gateway first. Saved card tokens don't automatically move between gateways.
WooCommerce Staging Site Payments: Duplicate Webhooks and Live Keys
A staging copy clones your database, which means it clones your live gateway keys, saved payment tokens, customer emails and webhook settings. Make these changes on staging before you do anything else:
- Switch every gateway to test mode and confirm the test notice appears.
- Block outgoing email with a mail-catching plugin, so test orders and renewal notices don't reach real customers.
- Keep webhooks separate. Live webhooks should point only at your production URL. Never add your staging URL as an endpoint in your live gateway account. If you do, staging receives real payment events and can update or duplicate order data. Register staging's webhook in test mode only.
- Watch password protection. Many hosts protect staging with a basic login prompt. Gateway webhooks can't get past it, so every test order sticks in pending. Ask your host to exempt the webhook URL, or turn the prompt off while you test.
- Expect wallet setup to differ. Apple Pay requires domain verification, so a staging domain may not show the button at all. See our fixes for Apple Pay not showing on WooCommerce.
- Push files, not the database. Pushing a full staging database to production overwrites any orders placed on the live site since you made the copy. Use your host's selective push, or reapply settings by hand.
A Pre-Update Checklist for Plugins, Themes and WooCommerce Core
Not every update needs the full script. Use the full eight rows for a gateway plugin update, a major WooCommerce version, a Subscriptions update, a checkout or theme change, or a new gateway. For minor updates to unrelated plugins, rows 1, 2, 3 and 6 are enough.
- Read the changelogs for WooCommerce, your gateway plugin and Subscriptions, and note anything that touches checkout, payments or minimum versions.
- Back up files and the database, and confirm you know how to restore them.
- Refresh staging from production so you're testing current data.
- Put staging in test mode and confirm its test webhook is registered.
- Apply updates on staging in the same order you'll apply them on production.
- Run the script and check both the order status and the gateway dashboard for each row.
- Open the Scheduled Actions screen in WooCommerce's status tools and look for failed payment or renewal actions.
- Update production during a quiet window, and avoid the hours when your subscription renewals cluster.
- Place your one live order, then watch the first real orders and the gateway dashboard for the next hour.
If the update you're planning is a new gateway rather than a new version of the old one, start by settling which processor and gateway will sit behind your checkout. Our WooCommerce payment processing options cover the integrations MannyPay supports, including Authorize.net and NMI. You can request a free quote, and a MannyPay specialist will respond within one business day so you can set up test credentials before your next update.
This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.
