Use the WooCommerce PayPal Payments extension to connect an eligible PayPal account, test checkout in sandbox and verify the resulting order and payment records before enabling live payments. Installing the extension does not establish that your business can receive or withdraw funds through PayPal. Confirm those account capabilities separately for the actual merchant entity.
The official documentation distinguishes account onboarding, sandbox testing, manual app credentials and connection reset options. That makes it possible to investigate a connection problem without immediately clearing every setting. For a Zambia-based store, begin with what the merchant account is permitted to do, then evaluate the plugin workflow. PayPal Payments account setup.
As checked on 24 October 2026, PayPal’s seller-onboarding country table labels Zambia “Send only” for the documented platform integration. This is a concrete limit on treating a Zambia account as a receiving merchant through that route. It is not a claim that every consumer PayPal function is unavailable. The setup below is conditional on a genuinely eligible merchant entity; manual credentials and successful sandbox payments do not remove country restrictions. PayPal seller-onboarding country eligibility.
What must be established before the PayPal button is useful?
Identify the account owner, business registration jurisdiction, intended receiving capability and withdrawal destination. Ask PayPal to confirm any point that the account interface or current country documentation leaves unclear. The presence of a PayPal login or a customer payment option elsewhere does not prove your merchant account can receive this store’s transactions.
The WooCommerce guide describes onboarding choices for physical goods, virtual products and subscriptions. Treat those choices as statements about what the business sells. Do not select an unrelated product category to make an application progress. The documented subscription route also depends on WooCommerce Subscriptions; ordinary one-off checkout is not evidence that recurring billing is configured.
Keep optional payment features separate from the base connection. The guide notes that Expanded Checkout features require an additional application. Do not promise all displayed wallets or card options merely because the plugin supports them in some configurations.
How do automatic onboarding and manual connection compare?
Automatic onboarding takes the authorised account holder through PayPal’s connection flow. Manual connection uses the Client ID and secret from a PayPal application. The documentation describes both, but the manual route is not a way around merchant verification or product restrictions.
| Route | Documented purpose | Evidence to retain |
|---|---|---|
| Automatic connection | Link the selected PayPal account through onboarding | Account identity and environment |
| Manual application credentials | Connect using a created PayPal app | App environment and authorised account |
| Sandbox connection | Test without real transactions | Sandbox seller, test buyer and order reference |
| Disconnect only | Remove connection credentials while preserving settings | Reason for reconnecting and retained configuration |
| Start over | Clear settings and restart setup | Explicit need for reset and configuration record |
This comparison helps diagnose the correct route. It does not rank one connection method as inherently safer or approve an account. Credentials should remain in the authorised configuration, never in the public article or an unrestricted support conversation.
How should sandbox testing work?
The account setup guide explains enabling Sandbox Mode and using sandbox accounts. It distinguishes sandbox and live applications in the PayPal developer dashboard. Record that distinction before testing: a sandbox seller should not be confused with the account intended to receive real customer payments.
Use a separate test buyer as the documented workflow suggests. Record the local order, sandbox transaction reference and observed status. The purpose is to see the customer’s complete journey and the resulting order behaviour without creating real transactions. Do not conclude that a live account has been accepted simply because the sandbox checkout succeeds.
Test the checkout presentation used by the actual site. If a store changes its checkout layout or adds another payment extension, repeat the cases affected by that change. Keep evidence of the configuration tested rather than relying on a generic statement that the plugin is compatible.
What should happen when the customer returns from PayPal?
Write an expected result for the customer page and the merchant order record. They should refer to the same order and accurately distinguish completed payment from a pending or unsuccessful attempt. A redirect landing on a pleasant confirmation page does not alone establish the financial outcome.
Include a case where the customer leaves payment unfinished and later returns to the store. Ask whether they can identify the existing order and the next legitimate action. Avoid encouraging another payment until the first attempt has been investigated when its result is uncertain.
For a refund case, inspect the relevant transaction and order records rather than changing a status label as a substitute for returning money. The broader PayPal Payments documentation links to payment and refund management guidance; the implementation should use the route applicable to the installed version.
A connection recovery record that preserves evidence
Use this original record before changing the connection:
Problem observed: describe the missing option, failed connection or inconsistent order state.
Current identity: authorised merchant account, app environment and store reference.
Configuration evidence: enabled methods, checkout type and relevant settings, excluding secret values.
Existing transaction: record the affected order and provider reference before reconnecting.
Proposed action: reconnect, correct environment, request account clarification or investigate the specific payment event.
Reset boundary: state whether settings will remain intact or be erased.
Result: record the actual outcome and any remaining uncertainty.
The documentation says Disconnect only removes credentials while preserving plugin settings. Start over resets the plugin and is described as destructive. These are materially different actions. A repeated connection attempt should not casually erase the evidence needed to understand the original problem.
What is an honest fallback if PayPal is unsuitable?
If receiving capability, withdrawal access or a required product cannot be confirmed, keep PayPal disabled for that workflow. Evaluate another payment route against the same merchant facts rather than changing the store’s country or borrowing another person’s account.
A manual payment option may be appropriate only if the business can operate its confirmation process clearly. A different online gateway still requires its own eligibility and integration checks. Neither choice should be described as an automatic replacement with identical capabilities.
Prepare the fallback wording before launch. Tell the customer which supported route is available and when their order becomes accepted or paid. Avoid implying that an unavailable method is temporarily broken if it was never enabled for the merchant.
Recheck the live account identity and environment before exposing payment buttons publicly. Retain the sandbox record and the agreed fallback so staff can investigate future enquiries consistently.
Discuss checkout requirements through Spout’s online payments service or start a project enquiry with the account capability questions and test record.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.