Ecwid offers several payment routes for a Zambia-based store: listed online providers, manual payment methods and a custom integration through its Payment API. Start with the country-specific options, then confirm the chosen provider will onboard your actual business. A provider name in Ecwid’s directory is useful evidence of a platform route, but it is not an individual merchant approval.
The practical comparison is between how each route collects money and how the order becomes paid. A familiar logo matters less than whether customers can complete the payment, staff can identify the transaction and the business can reconcile the receipt. This guide compares those routes without assuming that every directory entry offers every payment method or settlement destination. Ecwid’s Zambia payment options.
Which Ecwid payment gateways should a Zambia-based store investigate?
Ecwid’s Zambia page lists providers including DPO Group and 2Checkout. Use the complete current directory as your starting point rather than an old global list. For each candidate, check account eligibility, permitted business activity, customer methods, settlement arrangements and the integration actually offered for your store.
A directory listing answers a narrower question: Ecwid presents that provider as an option for the selected country. It does not establish that your application will be accepted, that all products are allowed or that a particular account can receive funds through your preferred route. Keep these questions separate in the evaluation.
Avoid choosing by the longest payment-method list. Ask a candidate to identify which methods apply to your account and which require additional activation. If that answer remains unclear, leave the candidate unconfirmed instead of describing it as ready for customers.
How do listed, manual and custom payment routes compare?
The following comparison combines Ecwid’s documented route options with editorial selection questions. It does not rank provider performance or claim that Spout has tested these integrations.
| Route | What the official documentation establishes | What you still need to establish |
|---|---|---|
| Listed online provider | Ecwid names country-specific integration options | Merchant acceptance, enabled methods and settlement terms |
| Manual payment | Customer pays outside the store; order awaits payment | Who checks the receipt and marks the order paid |
| Custom gateway | Ecwid points to its Payment API for unlisted local gateways | Development scope, provider support and ongoing maintenance |
These are different operating models. Manual payment can support a deliberate staff-led process, whereas an online gateway needs reliable communication between checkout, the provider and the order system. A custom integration adds development responsibilities; being technically possible does not make it an existing ready-to-use connector. Country routes, manual payment workflow.
What happens when a customer chooses manual payment?
Ecwid explains that manual payments are collected outside the store. The customer can receive instructions for a bank transfer or another agreed offline method. The order is initially marked Awaiting Payment and remains there until payment is arranged, funds are collected and the operator marks it Paid.
That distinction should shape the checkout wording. An order acknowledgement can confirm that the store received an order without saying payment has arrived. Staff should be able to locate the order reference in the receipt evidence. A screenshot supplied by a customer should start an investigation rather than automatically release goods.
Ecwid also allows manual payment methods to be limited to particular shipping methods. This can help keep an in-person collection arrangement attached to the relevant delivery choice. Check the actual configuration rather than relying on explanatory text alone. A customer should not reach a contradictory combination at checkout.
How should the checkout test be recorded?
Create a separate acceptance record for every enabled route. Begin with the customer’s device, selected delivery method, payment option and order reference. Record what the customer sees before payment, after returning to the store and in the order acknowledgement.
For an online provider, use its documented test arrangement and follow the transaction through both dashboards. For manual payment, create an unpaid test order and verify that staff can see it awaiting payment. Do not mark it paid merely to make the test look successful. Record the exact action that changes the state and the evidence the operator is expected to check first.
Include an abandoned payment and a customer who returns to the order later. These are proposed acceptance cases, not claims about Ecwid failure rates. Their purpose is to uncover unclear instructions or missing order references before a real shopper encounters them.
A reusable payment-route decision record
Copy the following artefact into your store specification. Complete it with evidence for each candidate rather than leaving every row as a general aspiration.
Route name: selected provider, manual method or custom connector.
Account evidence: business entity, application status and provider confirmation reference.
Checkout evidence: enabled customer method, delivery restrictions and customer-facing instructions.
Order transition: state before payment, event or operator action that changes it, and the retained transaction reference.
Settlement evidence: statement export, bank matching process and owner of unresolved items.
Exception evidence: abandoned attempt, unsuccessful payment, duplicate attempt and refund route.
Operating owner: person responsible for checking unpaid orders and investigating discrepancies.
Decision: suitable, unsuitable or awaiting a named answer.
This record is original editorial guidance. It is designed to prevent “the button appeared” from becoming the only acceptance criterion. It should also reveal whether a proposed custom connector is filling a genuine gap or duplicating a supported route.
When is a custom gateway worth investigating?
Ecwid explicitly points merchants to its Payment API when an intended local gateway is absent from the list. Treat that as permission to investigate the integration architecture, not evidence that a particular gateway is already integrated or approved.
Ask who will maintain the connector when either system changes, how payment events update orders and how the business can investigate missing notifications. Require a documented support boundary between the platform, gateway and implementer. If nobody owns a disputed payment, adding more checkout methods has not improved the operating model.
Before enabling a route, remove stale instructions and hide unfinished methods. Provide a clear alternative contact route if a shopper cannot complete payment. Do not promise instant collection or settlement for a manual process.
Spout’s online payments service is a starting point for discussing your store’s requirements. Send a project enquiry with the route decision record and outstanding provider questions.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.