Square payments on WordPress require an eligible Square merchant account and a supported integration, not just a payment button plugin. For WooCommerce Square, the official requirements include a supported shop location, matching account and site currency, and an SSL certificate. Zambia is not included in the supported-country list on the opened WooCommerce payment-settings page.
If your business does not meet the merchant requirements, installing another WordPress plugin does not establish a legitimate Square payment route. Compare another eligible gateway or a clearly operated manual method instead. If the account is eligible, evaluate payment configuration separately from product inventory synchronisation. WooCommerce Square payment requirements.
Which WordPress payment route are you actually considering?
Distinguish a simple payment form from a WooCommerce checkout. They can have different order records, refund tools and integration support. This guide’s verified configuration evidence concerns the official WooCommerce Square extension; it does not establish the behaviour of every plugin using Square’s name.
For a store already using WooCommerce, inspect how the extension attaches payment information to an order and which payment methods are enabled for the account. For a basic payment form, request its own official documentation and establish how the business will identify the customer request and resulting transaction.
Do not assume inventory sync and payment eligibility are the same feature. WooCommerce describes Square’s inventory and payment functions as independently usable. A connector can therefore be relevant to product data without proving that a Zambia-based merchant can activate Square checkout.
How should the available approaches be compared?
| Approach | Evidence established here | Decision still required |
|---|---|---|
| WooCommerce Square checkout | Official payment settings and requirements | Supported merchant location and account acceptance |
| Square inventory connection | Payment and sync features can be used independently | Applicable product-data workflow and permissions |
| Another WordPress payment form | Not evaluated by these sources | Primary documentation and merchant eligibility |
| Another eligible online gateway | An alternative to investigate | Its own account, checkout and settlement evidence |
| Manual payment instructions | An operating alternative, not Square processing | Receipt checks and honest unpaid-order handling |
The comparison avoids treating a plugin catalogue as an eligibility list. A product can appear in WordPress search while its underlying payment service is unavailable to the business trying to install it.
What do charge and authorisation settings change?
WooCommerce Square distinguishes Charge from Authorization. Charge takes payment immediately in the documented workflow. Authorization requires later capture, and the guide says an authorised but uncompleted payment does not yet appear in the Square transaction list it describes.
This distinction should be reflected in fulfilment rules. An order on hold after authorisation is not automatically ready to dispatch as a fully captured payment. Identify who captures the payment and what evidence confirms the capture before goods or services are released.
The documentation also describes settings that automatically capture certain paid orders or virtual-only orders. Do not enable those without testing the intended order type. A setting suitable for a downloadable item may not match a service whose final availability requires confirmation. Square transaction settings.
For this WooCommerce extension, the documentation states that Square authorisations expire after six days. If capture has not happened within six days, that authorisation cannot be captured and a new authorisation must be obtained from the customer. Record the authorisation time, capture deadline and actual capture result in the test sheet; include an expired case rather than treating an old on-hold order as collectable. WooCommerce capture deadline.
Square’s underlying Payments API documentation separately describes seven days as the default for online card-not-present delayed capture. That API default does not extend the extension’s documented six-day window. The API also distinguishes completing an approved payment from cancelling it; neither an authorisation nor an order status alone proves capture. Square delayed-capture API.
Which checkout details are easy to misinterpret?
Accepted-card logos are presentation settings. WooCommerce explicitly says changing the logos does not change which cards can be accepted. Therefore a row of familiar card marks is not evidence of customer-method availability.
Saved customer profiles are another separate capability. The documentation links them to tokenised future charges for relevant subscription and preorder workflows. It also identifies limitations for methods such as gift cards and Cash App in future-charge cases. Do not assume a successful one-off order proves recurring collection works.
Match the website’s currency to the Square account currency as required by the gateway documentation. This is a configuration constraint, not a statement that changing the displayed currency makes an otherwise unsupported merchant eligible. Account location and account acceptance remain separate checks.
An original authorisation-to-capture checklist
For an eligible account in an authorised test environment, record:
- The order reference and selected transaction mode.
- The provider reference for the authorisation or charge.
- The order state immediately after checkout.
- The role permitted to capture an authorised payment.
- The capture action and resulting payment evidence.
- Whether the expected order note and status change occurred.
- What happens when capture is not completed.
- Whether a repeated notification triggers a duplicate action.
- The refund route and its own completion evidence.
The checklist is a proposed acceptance artefact, not a report that Spout has run these cases. Keep the actual observed result beside each expected result. If a payment remains authorised, do not describe it as captured merely to complete the test record.
What if Square is unsuitable for this business?
Keep the unsupported route disabled and evaluate alternatives using the real merchant details. Do not borrow an overseas account or enter a false address to obtain activation. The aim is a durable payment arrangement the business can operate and reconcile.
An alternative gateway should be assessed for the required customer methods, account eligibility, order updates, refunds and settlement. A manual method may suit a deliberate staff-led process, but customer wording must explain that order submission is not immediate payment confirmation.
Prepare the fallback before launch. Staff should know where to find unpaid orders and what evidence is needed before changing a state. A shopper who cannot use the preferred method should see a clear supported next step rather than an unfinished payment form.
For an existing store, preserve current order and transaction evidence before changing gateways. Replacing a plugin should not remove the history needed to investigate previous payments or refunds. Establish how those records remain accessible.
Discuss the appropriate route through Spout’s online payments service or get started with the merchant location, existing checkout and unresolved requirements.
Keep a separate record for subscriptions and other future-charge products. A one-off test cannot establish that a stored payment method is suitable for the later transaction or that the renewal workflow is enabled.
Add a mixed test cart containing an ordinary item and a product requiring future charges if that combination is relevant. Inspect which methods are actually offered and why. Keep an unavailable method hidden rather than describing a logo selection or saved profile as evidence that the future transaction is supported.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.