Choose a BigCommerce payment gateway through 4 separate checks: merchant eligibility, the exact integration, supported transaction features and successful checkout testing. A gateway name appearing in BigCommerce documentation proves an integration exists; it does not prove that a Zambian company can open the required merchant account or settle into its bank account. Establish those conditions before designing the checkout around a provider.
BigCommerce supports different payment experiences, so begin by distinguishing the ordinary storefront checkout from a custom application using its Payments API. A method available somewhere on the platform is not automatically available through every API flow. That distinction is especially important when considering wallets, stored instruments or authentication that requires the shopper’s interaction.
Which gateway options should you investigate?
BigCommerce’s gateway directory organises options by country. Use it as a starting point for finding the applicable merchant route. The page retrieved for this research does not establish a Zambia-specific merchant option. That is an evidence gap requiring confirmation, not proof that every integration is unavailable and not permission to substitute a neighbouring country’s eligibility.
The Payments API documentation provides a different kind of evidence: compatibility with that particular developer interface. The examples below are documented integration families to investigate, not locally approved recommendations. An exact variant matters because similarly named integrations can have different capabilities.
| Documented integration family | What the API documentation establishes | What still needs provider confirmation |
|---|---|---|
| Stripe variants | Named variants appear in the API compatibility table | Merchant entity country, settlement route and the selected variant |
| Adyen variants | Multiple separately named integrations are listed | Which integration and features apply to the proposed merchant |
| PayPal powered by Braintree | A documented route includes existing stored PayPal accounts | Account eligibility and the intended storefront or stored-payment flow |
Do not read that table as a ranking. The right candidate is the one whose merchant terms and documented integration match the actual business. A familiar brand can still be unsuitable for the entity, currency or payment experience being proposed. Obtain a written answer tied to the merchant’s registered country and bank arrangements.
Ask about checkout currency and settlement currency separately. A shopper seeing a currency symbol does not prove that the merchant can receive funds in that currency. Keep conversion, settlement and reconciliation questions in the provider discussion without inventing local fee figures or implying that a customer’s card location determines merchant eligibility.
What changes when you use the Payments API?
The API documentation says it processes payments through connected gateways and lists compatible integrations. It also explains that not every gateway supports both stored instruments and raw card data. A custom checkout proposal should identify the precise interface and instrument type before anyone treats a successful storefront payment as proof that the custom flow will work.
The documented API flow does not support hosted, offsite or wallet-type providers generally, with a specific exception for existing stored PayPal accounts through PayPal powered by Braintree. This is a limitation of the described API flow, not a statement that BigCommerce storefronts cannot offer wallets. Keep that scope in the requirements and test plan.
Authentication needs its own design. BigCommerce explains that 3D Secure requires shopper interaction and describes restrictions on using previously unsaved cards through this server-to-server API. Do not attempt to hide an authentication requirement behind a background charge. Ask the integrator to demonstrate the documented path for the chosen gateway and payment instrument.
Stored-payment functionality also has store and gateway prerequisites. Read the current documentation against the proposed plan and checkout configuration rather than assuming that saving a card is simply a field to enable. A subscription or repeat-payment requirement should specify customer authorisation, the supported instrument and what happens when a later charge cannot proceed.
BigCommerce also distinguishes its security responsibilities from those of a third-party application handling payment data. Avoid collecting raw payment details into an improvised form or sending them in email. The developer’s compliance responsibilities depend on the actual integration; merely using a recognised platform does not transfer every obligation to it.
How should you test a gateway before relying on it?
Use this original gateway acceptance ledger. It deliberately keeps eligibility evidence separate from technical test results, because neither substitutes for the other.
| Test or decision | Evidence to retain | Result that should block activation |
|---|---|---|
| Merchant onboarding | Provider answer for the actual entity and country | An answer about shoppers rather than merchants |
| Currency and settlement | Agreed checkout and receiving arrangements | Unexplained currency conversion or unsupported bank route |
| Integration identity | Exact gateway variant and checkout method | A demonstration using a different connector |
| Successful payment | Order reference matched to payment reference | Payment success without an identifiable order |
| Declined or cancelled attempt | Clear customer message and recoverable order state | An unpaid order shown as paid |
| Authentication | Supported shopper challenge flow | A challenge that cannot be completed |
| Refund handling | Authorised workflow and linked transaction evidence | Staff cannot reconcile the refund to the original payment |
| Repeated notification | Same event handled without a duplicate obligation | A repeated message triggers a second fulfilment |
The exception tests are requirements to demonstrate, not claims that every gateway supplies identical controls. Use the provider’s documented sandbox or approved test procedure, with no real customer card data. BigCommerce specifically states that its Payments API does not support the BigCommerce Test Payment Gateway, so do not assume that storefront test mode validates an API implementation.
After testing payment, follow the order into fulfilment and accounting. A visible success message is only one part of the journey. Staff need to distinguish authorised, paid, cancelled and refunded transactions according to the actual provider’s states. Keep the external reference available so that a discrepancy can be investigated without guessing from a customer screenshot.
Repeat the important checks after changing the gateway variant, checkout implementation or merchant account. Record which configuration produced the evidence. Reusing an old screenshot from another integration would conceal the very conditions that determine whether the proposed setup works.
For the broader payment journey, see online payments. To describe a BigCommerce requirement, get started with the merchant country, intended checkout, currencies and required payment features. Keep account secrets and payment credentials out of the enquiry.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.