Checkout best practices for PayFacs, PSPs and ISVs cover the hosted checkout they give their merchants: a short step-by-step flow, few form fields, fields and payment methods localized by country, saved cards with network tokens, clear error messages and fallback to a second provider. On NORBr, Smart Checkout ships these defaults to every merchant under the operator's brand.
Merchants judge a payment provider by what their customers see at the moment of paying. This article explains why checkouts lose customers, how a hosted checkout should be structured, how many fields to ask for, how to localize fields and payment methods, how saved cards and express options reduce friction, and how errors, trust and fallback affect completion.
Why do shoppers abandon checkout and why do payments fail?
Most abandonment happens before the payment is even attempted, and a large share of it is caused by the checkout itself. According to Baymard Institute's cart abandonment research (updated September 2025), the average documented abandonment rate is 70.22 percent; among shoppers who left during checkout, 19 percent did not trust the site with their card details, 18 percent were asked to create an account, 17 percent found the process too long or complicated, and 17 percent hit errors.
Then come the payment failures: declines for insufficient funds or limits, mistyped card data, fraud checks that flag legitimate buyers, and outages at a single processor. For an operator, every one of these is a lost transaction for a merchant, and most can be reduced by the way the checkout is built.
How should a hosted checkout be structured?
A checkout should guide the customer through clear steps, such as cart review, customer information, delivery and payment, with a visible progress indicator. If steps are shown as an accordion, completed steps should collapse into readable summaries so customers can check their information without reopening each one.
The page itself should use a simple, single-column, top-to-bottom layout, work as well on mobile as on desktop, and keep the customer in the merchant's environment rather than redirecting to an unfamiliar page. NORBr's Smart Checkout hosted page runs behind a CSS layer the merchant controls, so colors, fonts and buttons match the merchant's brand from cart to confirmation.
How many form fields should a checkout ask for?
As few as possible. According to Baymard Institute, the average US checkout flow displays 23.48 form elements by default, while an ideal flow can be as short as 12 to 14.
The usual levers: a single full-name field, billing address defaulting to the delivery address, address autocomplete, an unambiguous MM/YY expiry format, large touch targets on mobile, and no automatic jumps between fields, which cause typing errors. Every field the operator removes from its default template is removed for every merchant at once.
How do you localize checkout fields per country?
Some fields are not optional in certain markets, and a checkout built for one country will fail in another. In the United States, the ZIP code feeds the Address Verification Service used against card fraud and determines the sales tax rate. In Japan, address formats follow prefecture and region conventions that must be captured correctly for delivery. In Brazil, the CPF taxpayer number is routinely required for online purchases.
Payment choice can be local too. In France, most cards are co-badged Cartes Bancaires and Visa or Mastercard, and under the EU Interchange Fee Regulation the merchant can set a preferred brand while the cardholder keeps the right to choose. A checkout that handles these rules per country lets an operator open markets without asking each merchant to rebuild its forms.
Which payment methods should be displayed, and in what order?
The methods customers expect in their market, with the most used one first. In Baymard Institute's research on payment method selection, 11 percent of users abandoned a checkout because their preferred payment option was not available.
That means cards and wallets everywhere, plus local methods such as Wero in the Netherlands, Belgium and Germany, Bizum in Spain or Blik in Poland, shown with recognizable names and logos. On Smart Checkout, the methods displayed and their order are a configuration choice made from the methods active on each merchant's contract, and the #PayWorldTour guides list what to show in each country. The instant payments article covers Wero and other account-to-account methods.
How do saved cards, guest and express checkout reduce friction?
Returning customers should not retype their card, and new customers should not be forced to create an account. In Europe, PSD2 strong customer authentication applies to customer-initiated payments, while merchant-initiated payments, such as subscriptions, can rely on the consent given at the first payment; saved cards must respect that split.
On NORBr, the token captured on the first customer-initiated payment is stored in the NORBr Vault as a universal network token, reusable across every provider, so a saved card keeps working when the merchant changes acquirer. Guest checkout with account creation offered after the purchase, and express wallets such as Apple Pay and Google Pay, remove the remaining steps. The network tokenization page details how tokens are managed.
How do error messages, trust signals and fallback affect completion?
Errors should be flagged as soon as they happen, in plain language ("Please enter a valid card number" rather than "Invalid card number"), one at a time and next to the field concerned. Trust signals, such as recognizable payment logos, security indicators and visible links to returns and support, address the shoppers who hesitate to share card details.
Behind the page, two settings recover payments the customer never sees failing: 3DS rules tuned from authorization data, and fallback that retries a failed transaction with a second provider, configured in payment resilience. Smart Checkout also records every checkout initiated, the method displayed, the device and the moment of abandonment, so operators and merchants can test changes against real data rather than assumptions.
_%2520a%2520game%2520changer%2520for%2520digital%2520transactions_-Cover.webp){kind=spacer}
