To use Stripe in WooCommerce, first establish that the business qualifies for the account and extension, then install the official gateway, connect the account, configure webhooks and test the checkout you actually use. A visible card form is not proof of a working payment lifecycle. Merchant eligibility, payment confirmation and refund handling need separate evidence.
WooCommerce’s setup guide requires a business in a supported Stripe country, recent platform versions and HTTPS. It specifically excludes preview countries from the extension’s stated requirements. A Zambia-facing website does not by itself establish whether its merchant entity meets those conditions. WooCommerce Stripe setup, Stripe global availability.
As checked on 24 October 2026, Zambia is absent from Stripe’s published supported merchant-country list. A business established only in Zambia therefore has no listed direct Stripe Payments merchant-country route on that page. This concerns the merchant entity, not where customers live. A genuinely established entity in a supported country needs its own eligibility assessment; changing a store setting or using a foreign customer’s card does not establish one. Preview and extended-network labels are separate qualifications, not identical direct availability. Stripe global availability.
What should you check before installing Stripe?
Record the legal entity, its operating jurisdiction and the account that will receive payments. Check the provider’s current account requirements for that entity. Do not change business details or treat an overseas customer’s card as evidence of merchant eligibility.
Next, inspect the software environment: WordPress, WooCommerce, PHP, checkout type and other payment extensions. WooCommerce’s documentation says these components must be on recent versions and the site must use HTTPS. This article does not invent a different minimum version or claim that satisfying those prerequisites guarantees every extension combination will work.
Keep a record of the versions selected for testing. If a checkout plugin, caching rule or order automation changes later, the original test no longer describes the entire current configuration. That is a reason to repeat affected cases, not a reason to promise permanent compatibility.
How do the setup layers differ?
| Layer | What it establishes | What it does not establish |
|---|---|---|
| Merchant account | The intended business and provider relationship | That the website receives payment events correctly |
| Installed extension | A gateway is present in WordPress | That account setup or checkout testing is complete |
| Account connection | Store and account are linked | That every optional method is enabled |
| Webhooks | A route for relevant provider events | That an individual order has been paid |
| Checkout configuration | Customer-facing payment presentation | Successful capture, refund or settlement |
These layers come from the documented setup responsibilities and an editorial acceptance model. They should remain separate in the handover so a completed installation is not mistaken for a completed commercial process.
Why must webhooks be part of the acceptance test?
WooCommerce explicitly includes connecting a Stripe account and setting up webhooks in the configuration process. The order system needs the appropriate provider information after checkout, including situations where the customer does not return neatly to the store.
A test should therefore inspect the payment event and the resulting local order state, not only the browser screen. Record the order reference, provider transaction reference, observed event and resulting action. Where an event is absent or rejected, preserve the error evidence and investigate the route rather than manually marking every affected order paid.
This article does not prescribe an undocumented webhook signature algorithm or assume all plugin versions use identical endpoint settings. Use the current instructions applicable to the installed extension. Treat secret values as credentials and keep them out of public logs, screenshots and support posts.
What does the multisite qualification mean?
For WordPress multisite, WooCommerce recommends installing the extension on each sub-site individually. It also qualifies its testing coverage rather than promising that every feature works in every multisite setup.
If multisite applies, identify the sub-site, connected account and checkout configuration in each test record. A successful payment on one sub-site does not demonstrate that another sub-site uses the right account or receives its events. Inspect the actual connection instead of assuming network-level installation supplies a complete configuration everywhere.
For a single site, do not add multisite complexity unnecessarily. The useful principle is that the tested store, account and environment must be identifiable. A handover saying only “Stripe connected” leaves the next operator unable to tell which configuration the evidence describes. Official setup qualifications.
An original payment test handover
Prepare a test sheet with a row for each required checkout route. Include ordinary card payment, any enabled express checkout and any additional method the business intends to advertise. Optional methods are separate configuration choices in the WooCommerce guide; do not mark them tested because the base gateway works.
For each route, record:
- Store and environment, with no secret values.
- Extension and checkout versions used.
- Local order reference and provider reference.
- Customer-facing result and next action.
- Payment event received and order transition observed.
- Whether fulfilment or email actions ran.
- Refund or cancellation evidence where applicable.
- Unresolved difference and investigation owner.
Use the provider’s authorised test arrangement. Keep live fulfilment, genuine customer messages and other external effects disabled or sandboxed during rehearsal. The sheet is a proposed acceptance artefact, not a claim that Spout has run these tests.
How should an unsuccessful checkout be investigated?
Separate the customer attempt, provider payment result and local order state. A customer leaving checkout is not the same as a declined transaction. A provider payment with an unresolved local order is another distinct case.
Start with existing references before asking the customer to try again. If the payment outcome is unclear, a second attempt can produce an additional transaction that needs reconciliation. Retain the event history and identify the exact mismatch rather than summarising everything as “Stripe failed”.
If somebody changes an order manually, record the evidence and reason. A manual correction should not hide an endpoint or configuration defect affecting subsequent orders. Repeat the relevant test after the underlying cause is corrected.
What should be agreed before live checkout?
Confirm the actual account identity, applicable country requirements, active methods and support ownership. Keep unsupported or unfinished methods hidden. Define who checks unmatched payments and how previous transactions remain accessible if the gateway configuration changes.
A passed rehearsal supports the tested configuration. It is not a guarantee of future uptime, security or account acceptance. Keep those claims out of customer-facing launch copy.
Discuss the requirements through Spout’s online payments service or start an enquiry with your current store and merchant-account questions.
When reviewing a failed case, retain the checkout type as well as the gateway version. A classic form and a block checkout can present different integration surfaces. Establish the applicable documentation and actual test result instead of carrying a successful result from one presentation into another without checking it.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.