start with the market, not the payment method
The most common checkout planning mistake is starting with payment method selection, deciding which cards, wallets or local methods to support, before understanding the market those methods will serve. Market analysis should precede payment type decisions, because the market determines the payment types, the payment types determine the checkout flows, and the checkout flows determine the compliance requirements.
For each target market, three questions need answers before checkout planning can begin: Who are the customers, what is their demographic, device usage, and digital payment maturity? What payment types are dominant in this market for digital commerce? And what regulatory requirements govern how payments are accepted, disclosed and processed in this jurisdiction?
demographics determine payment type
Customer demographics are not just a marketing consideration, they are a payment infrastructure decision. In Brazil, Pix instant bank transfer now dominates both physical and digital commerce. In most African markets, mobile money is the primary digital payment type for the largest consumer demographic. In South Africa, the outlier on the continent, card payments remain dominant. In Europe, PSD2 has created a mature open banking ecosystem alongside card dominance.
A checkout that does not offer the payment type a customer expects to use will not convert, regardless of how well everything else is designed. Payment type selection should be driven by what the target customer actually uses in their market, not by what is easiest to integrate.
coralcommerce makes two sets of hosted checkout templates available to clients for customisation, a comprehensive library covering every standard step in a payment checkout including card tokenisation, card store and wallet steps, 3dssec verification, order confirmation, payment option selection, and email notifications. templates are fully editable html/css/js and hosted in our secure azure environment.
understanding country and regulatory requirements
Payment regulation varies not just by country but by payment type. Mobile money across most of Africa is regulated separately from card payments, always settles in local currency only, and is subject to its own licensing regime distinct from banking regulation. Card payments in Europe require PSD2 Strong Customer Authentication compliance for online transactions above certain thresholds. The UK applies some of the strictest distance selling and consumer protection regulations to digital commerce in any major market.
For payment facilitators accepting payments on behalf of merchants, the regulatory threshold is higher still, most markets require the facilitator itself to be licensed or to operate through a licensed local partner. South Africa requires a locally registered licensed partner. Nigeria tightly controls its licensed payment operator ecosystem. Understanding these requirements before committing to a market is not optional, it is the difference between a compliant operation and an illegal one.
hosted vs headless: the compliance decision
One of the most consequential checkout architecture decisions is whether to use a hosted checkout, where the payment pages are served by the payment provider, or a headless integration where the merchant controls the entire user interface.
Hosted checkouts place the sensitive payment steps (card data capture, SCA challenges, 3DS flows) within the payment provider's secure environment. This means the merchant's PCI DSS compliance scope is significantly reduced, in most cases to a self-assessment questionnaire rather than a full annual audit. CoralCommerce hosted checkouts automatically qualify for PCI DSS Level 1 compliance.
Headless integrations give the merchant full control over the customer interface, but any step that captures cardholder data within the merchant's own environment places that environment in scope for a full PCI DSS audit. For merchants with the engineering capacity and compliance infrastructure to manage this, headless offers maximum design flexibility. For most merchants, hosted is the commercially rational choice.
building user journeys before building code
Each payment type produces a distinct user journey, different steps, different outcomes, different terminology and different potential error states. A card payment flow, a mobile money flow, and a bank transfer flow through the same checkout are three separate sequences of events. Planning these journeys on paper, or in a design tool, before writing code surfaces complexity that would otherwise emerge as bugs during testing.
Between order confirmation and payment completion, every step should be communicated clearly to the customer. If a hosted checkout redirects the customer to a third-party environment, prepare them for that transition rather than allowing an unexpected change of visual context to create doubt. Overcommunication at each checkout step costs nothing and recovers meaningful conversion.