Connecting 2Checkout to WooCommerce requires 5 checks: merchant eligibility, connector variant, credentials, payment notifications and order testing. The existence of an official connector does not establish that a particular Zambian business can open or use the required merchant account. Confirm that route before planning a checkout around it.
Which 2Checkout connector route are you evaluating?
Identify the legal merchant and the proposed account before discussing plugin installation. Ask the provider to confirm eligibility for the business’s registration country, activity and intended payment route. Customer payment reach and merchant signup eligibility are different questions. The opened connector sources do not establish Zambia merchant approval, settlement arrangements or permitted business categories, so those remain explicit requirements rather than assumed features.
Use the official WooCommerce connector repository to identify the module being proposed. Its README lists API, inline and hosted-checkout variants. A tutorial for one route should not be applied to another without checking the differences. Record the selected module, installed version and supported environment. Similar payment labels in search results do not establish that the same integration is being demonstrated.
Compare inline and hosted presentation through the actual customer journey. One may place more of the interaction within the store while another sends the customer through a hosted route. Do not infer the complete current behaviour from the variant name alone. Demonstrate the approved account configuration and inspect where customers enter payment information, cancel and return to the order result.
Keep credentials in the authorised server-side configuration. The README identifies merchant and secret-related settings, but that does not justify copying them into a brief or public troubleshooting message. Record who can configure the integration and how the business retains ownership of the merchant account. This article does not require or authorise access to any credentials.
Plan the notification route deliberately. The official README documents an IPN callback URL associated with the selected variant and a configured hashing algorithm. Use the exact current instructions for the installed module, with implementation review of the callback verification. A browser returning to a success-looking page should not be treated as the sole evidence that the store has received a valid payment outcome.
Documented module setup route
The repository README maps twocheckout to 2PayJS/API, twocheckout-inline to Inline Checkout and twocheckout-convert-plus to Hosted Checkout. For the selected route, its instructions place that module directory under WordPress’s plugins directory, install it through Plugins, then open WooCommerce settings > Payments and the module. Enable it, set its public title/description and configure the account values privately. The inline and hosted variants additionally use the secret-word setting.
Save the settings and obtain the IPN Callback URL displayed by that module. In the merchant dashboard’s Integrations area, configure IPN with this copied destination, select SHA3 and enable the documented triggers. Do not construct a callback by guessing the variant suffix or expose any secret in an example. This is the repository’s documented sequence, not a tested current-account walkthrough; verify compatibility for the installed versions before applying it.
Core WooCommerce settings documentation separately locates provider enablement/configuration under WooCommerce > Settings > Payments and notes that extensions add settings. Distinguish that core route from module-specific controls.
How do you test notifications and order status?
Write the expected order-state transitions before testing. Distinguish an order created, a payment attempted, a verified successful result and an exception requiring attention. Ask which documented event moves the order between those states. Do not invent status semantics from a screenshot. If the connector cannot demonstrate a required transition, retain it as an unresolved implementation question.
Test a normal authorised transaction in the provider’s supported test facilities. Record the store order reference, provider reference, observed notification and resulting order state. Keep sensitive payloads out of public documentation. A useful acceptance record contains enough redacted information to trace the transaction without exposing customer or authentication data.
Test interruption and delayed notification. Imagine the customer closes the browser before returning to the store, or the store does not receive the expected notification immediately. Ask what the customer and staff see, and how the eventual result is reconciled. The correct handling must be demonstrated in the proposed integration. Do not substitute a general claim that webhooks make every order automatically reliable.
Test repeated notification and repeated customer action. The integration should follow the agreed business rule without creating duplicate fulfilment or contradictory order history. Ask the implementer to explain the stable transaction reference and show the observed result. This is an acceptance requirement, not a claim that the repository README proves every deduplication mechanism or every current module behaviour.
Include cancellation, failure and refund paths. A route that collects one successful test payment may still leave staff unable to explain an abandoned attempt or a later reversal. Clarify which actions happen in WooCommerce and which require the provider dashboard. Retain manual dependencies honestly. A complete integration brief should make operational ownership legible rather than leaving every unusual state to informal investigation.
Add a configuration-handover exercise to the gateway ledger. Ask a colleague with the intended authorised role to identify the selected module, locate the redacted callback reference and explain the expected order state after a delayed result. They should not need the secret values to understand the workflow. Then compare a cancelled payment with an unresolved notification: those situations can require different customer messages and staff actions. Retain the observed distinction and any manual provider check. This exercise tests whether the integration can be operated after its original installer leaves, without treating a README setting or a successful sample transaction as proof of complete operational readiness.
Decision worksheet
Original contribution: a payment-notification acceptance ledger. For a fictional purchase, record the WooCommerce order, selected module, expected provider outcome and permitted resulting state. Add cases for a closed browser, delayed notification, repeated notification and cancelled attempt. Give each case a responsible owner and a redacted evidence reference. Then compare the order history with the provider’s test record. The ledger makes missing or ambiguous confirmation visible instead of allowing an attractive success page to close the evaluation.
| Checkpoint | Evidence to retain | Decision or corrective action |
|---|---|---|
| Merchant eligibility | Provider confirmation for the actual entity | Do not infer signup from customer reach |
| Connector variant | Module, version and checkout route | Use the matching documentation |
| Credentials | Authorised configuration and account owner | Keep secrets outside the brief |
| Notifications | Verified callback and state mapping | Separate browser return from confirmation |
| Order tests | Success, interruption, repetition and refund | Assign unresolved exceptions |
Run the ledger with the same fictional product and approved test setup for each connector route under consideration. Keep the expected business result unchanged while comparing the technical paths. If a hosted route and an inline route produce different customer recovery behaviour, record that as a real comparison item. Do not describe either as universally more reliable without evidence.
Finally, inspect the maintenance plan. Identify who will recheck compatibility after WooCommerce or connector changes and who can investigate an account restriction. The official 2Checkout integration page establishes that an integration route is described; it does not establish the suitability of an unreviewed installation. See online payments and WordPress for related scope. To discuss a gateway brief, get started with the fictional ledger and registration country.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.