Chapter 1. The last mile: what friction really costs.
An e-commerce site can spend a fortune on acquisition, yet everything is decided in the last few minutes between the cart and the confirmation page. The checkout, which covers sign-in, shipping, and payment, is where purchase intent meets friction: fields to fill in, accounts to create, fees revealed at the last moment, declined cards. Every pain point has a measurable cost, and every second saved shows up in revenue.
To find out why shoppers abandon, the Baymard Institute, the leading authority on e-commerce UX research, surveys US shoppers every year who abandoned a purchase after starting it, excluding those who were only browsing. The 2024 results show a clear ranking of pain points:
| Reason for abandonment | Share of abandoners | Fix |
|---|---|---|
| Extra costs too high (shipping, taxes) | 48 % | Show the total cost as early as possible, with clear free-shipping thresholds |
| Account creation required | 26 % | Guest checkout by default (chapter 3) |
| Didn’t trust the site with card details | 25 % | Visual reassurance, scheme logos, consistent secure page |
| Delivery too slow | 23 % | Estimated delivery dates, express options |
| Checkout too long or complicated | 22 % | Fewer fields, wallets first (chapters 2 and 3) |
| Couldn’t see the total cost up front | 21 % | Cost estimator starting in the cart |
| Site errors or crashes | 17 % | Funnel monitoring, error handling (chapter 5) |
| Unsatisfactory return policy | 16 % | Clear policy, visible at checkout |
| Not enough payment methods | 13 % | Wallets, BNPL, bank transfer, depending on the customer base |
| Card declined | 9 % | Translated decline codes, alternative methods (chapter 5) |
Before optimizing, you need to know where you are losing customers. Checkout is measured as a funnel in which each step has its own pass-through rate, and multiplying those rates gives overall conversion. The rest of the course follows the funnel in the order the customer experiences it: the form, payment methods, mobile, and declines, with measurement and experimentation to close.
Chapter 2. The form: field order, autofill, and validation.
The form is the basic unit of checkout friction. Baymard counts an average of 11.3 fields displayed, when 7 to 8 are enough to fulfill an order. Every unnecessary field adds time, typing errors, and chances to hesitate. Three principles govern a good form: ask only for what is needed, ask for it in the right order, and help the browser fill it in automatically.
Field order matters
- Email first. It is the key to everything. It lets you recognize a returning customer (and offer their saved payment methods), send the confirmation, and follow up on an abandoned cart if the customer drops off there. Asking for it first gets the most value out of partial abandonments.
- Shipping before payment. The address determines shipping costs and the delivery date. The customer must know the total cost before reaching for a card, never the other way around (remember that 48% of abandonments come from surprise fees).
- Payment last. Entering card details is the biggest commitment, so ask for it only once every other question is settled. Make the billing address the same as the shipping address by default, with a single checkbox to uncheck when they differ (fewer than 10% of B2C orders).
- A single “full name” field rather than separate first and last names, no title (Mr./Ms.), and no mandatory phone number unless the carrier really needs one. If it does, say why (“so we can notify you about delivery”).
Autofill: let the browser do the work
Browsers and password managers can fill in an entire form in one click, provided the fields carry the correct HTML autocomplete attribute. The attribute is also an accessibility requirement (WCAG 2.1, success criterion 1.3.5, “Identify Input Purpose”). With split fields, unusual field names, and blocked copy-paste, a form that breaks autofill turns 30 seconds into 3 minutes, especially on mobile.
<input name="email" type="email" autocomplete="email" inputmode="email" />
<input name="name" autocomplete="cc-name" />
<input name="cardnumber" autocomplete="cc-number" inputmode="numeric" />
<input name="exp" autocomplete="cc-exp" inputmode="numeric" placeholder="MM/YY" />
<input name="cvc" autocomplete="cc-csc" inputmode="numeric" />
<!-- inputmode="numeric": numeric keypad on mobile -->
<!-- Never block copy-paste or break input with forced spaces -->Chapter 3. Wallets first and guest checkout: shortening the path.
The best form optimization is having no form at all. A wallet payment (Apple Pay, Google Pay, PayPal, and soon Wero) combines, in one gesture, cardholder authentication through the phone’s biometrics, tokenized card details, and the shipping address. A full manual entry takes 2 to 3 minutes on mobile; a wallet completes in under 30 seconds. In Europe, it also meets the PSD2 strong customer authentication (SCA) requirement natively.
The wallets first principle places express buttons (Apple Pay, Google Pay, PayPal) at the top of the checkout, or even on the cart page, above the standard form. Customers with a wallet skip every step; everyone else scrolls down to the card form. According to Worldpay’s Global Payments Report (2025 edition), wallets already account for more than half of global e-commerce spending, and Europe, though behind, is on the same trajectory. One technical precaution: show only the wallets actually available on the device (Apple Pay on Safari/iOS, and so on). A dead button is worse than no button.
// Browser-side detection before showing the express button
if (window.ApplePaySession && ApplePaySession.canMakePayments()) {
showButton("apple-pay")
}
// Standard multi-wallet approach: Payment Request API
const request = new PaymentRequest(methods, details)
const canPay = await request.canMakePayment()
if (canPay) showExpressCheckout()Guest checkout: an account is an option, never a toll
26% of shoppers who abandon cite mandatory account creation (Baymard, 2024). The rule is simple. Guest checkout is the default path, and account creation is offered after confirmation (“create a password to track your order”). The email and address are already filled in, so only one field is missing. UX literature cites a textbook case in which ASOS sharply cut abandonment by replacing its “create an account” screen with one that simply invited new customers to continue. The account was still created at the same moment; only the word was gone.
| Strategy | Friction | Impact on conversion | Data/CRM impact |
|---|---|---|---|
| Account required before purchase | Maximum | -26% of potential buyers (Baymard 2024) | Richer but smaller customer base |
| Guest checkout only | Minimal | Best immediate conversion | Customers hard to retain |
| Guest + account creation after purchase | Minimal at purchase | Better conversion and retention | The right trade-off for most sites |
| Wallet or network sign-in (Apple Pay, PayPal) | Almost none | Excellent on mobile | Data limited to what the wallet shares |
For returning customers, the complementary building block is one-click payment. The card is tokenized on the first purchase, with the explicit consent that PSD2 requires in Europe to store credentials, and reused afterward. Visa and Mastercard network tokens replace the PAN with a merchant-specific token that carries over when the card is reissued. The networks claim an authorization rate lift of about two to three percentage points (Visa, 2024).
Chapter 4. Mobile first and accessibility: designing for every thumb.
Most e-commerce traffic is now mobile, yet mobile conversion remains structurally lower than desktop, because of small screens, tedious typing, and constant interruptions. Every optimization therefore pays off most on mobile. And since June 28, 2025, an accessible checkout flow is no longer optional: the European Accessibility Act now applies to e-commerce.
Mobile checkout fundamentals
- The right keyboard for each field:
inputmode="numeric"for the card number and CVV, the email keyboard for the email address. Making users hunt for the number keys on a letter keyboard is a small torture repeated 20 times. - Generous touch targets: buttons and tap areas of at least 44×44 points, well spaced, because a thumb is not a cursor.
- One column, one goal per screen: the order summary collapses, the main action button stays visible (often pinned to the bottom), and the total is always displayed.
- Wallets first, even more than elsewhere: on mobile, it’s Face ID versus 16 digits plus expiration date, CVV, and address. No contest.
- Performance: every second of load time costs abandonments. Checkout should be the fastest page on the site, not the one most weighed down by third-party scripts.
- Never lose state: customers switch apps to read a 3DS text message or copy an IBAN. When they come back, the cart and every field they filled in must be intact.
Accessibility: a legal requirement and a conversion lever
The WHO estimates that 1.3 billion people live with a significant disability (2023). An inaccessible checkout shuts them out and makes the experience worse for everyone else. Captions help people in open-plan offices, large buttons help hurried thumbs, and clear error messages help everyone. Directive (EU) 2019/882, known as the European Accessibility Act, has made accessibility mandatory for e-commerce services since June 28, 2025. The technical standard is EN 301 549, aligned with WCAG 2.1 Level AA. In France, RGAA 4 (the national accessibility framework) is the audit baseline, and the DGCCRF, France’s consumer protection authority, handles enforcement.
| Criterion | Requirement | Common checkout mistake |
|---|---|---|
| 1.4.3 Contrast | Minimum 4.5:1 ratio for text | Light gray placeholders, unreadable legal text |
| 1.3.5 Input purpose | Correct autocomplete attributes | Unannotated card fields, broken autofill |
| 3.3.1 / 3.3.3 Errors | Error identified and a fix suggested | “Invalid field” in red, with no reason or fix |
| 2.1.1 Keyboard | Everything must work with a keyboard | Date picker or 3DS modal trapping focus |
| 4.1.2 Name, role, value | Components exposed to screen readers | Fake buttons built from <div>, untitled payment iframes |
| 1.4.11 Non-text contrast | Field borders and icons at 3:1 | Form fields almost invisible on a white background |
Chapter 5. Error messages: turning decline codes into saved sales.
The customer has filled everything in, clicks “Pay,” and the bank says no. This is the most fragile point in the funnel. 9% of abandonments are caused by a declined card (Baymard, 2024), and most of those sales were recoverable. The issuer returns the decline as a standardized code, inherited from ISO 8583, which your PSP passes on to you. The goal is never to display that raw code, but to turn it into an action the customer can take.
Soft and hard declines: two families, two strategies
A hard decline is final for that card: stolen, expired, invalid number. Retrying is pointless, even risky. A soft decline is situational: insufficient funds, limit reached, issuer unavailable. Since PSD2, a fourth soft-decline case has become widespread in Europe: authentication required. The issuer declines the unauthenticated transaction but will approve it if it is resubmitted with 3-D Secure (Visa code “1A,” Mastercard “65”). Your PSP should handle this case automatically, without the customer ever seeing it.
| Code | Network meaning | Type | What to display / do |
|---|---|---|---|
| 05 | Do not honor (generic issuer decline) | Soft | “Your bank didn’t authorize this payment. Try again or use another method.” Offer a wallet or bank transfer. |
| 51 | Insufficient funds | Soft | Neutral message (“payment not authorized”), suggest another method or installments. Never say “insufficient funds”: it’s humiliating and sometimes inaccurate. |
| 54 | Expired card | Hard (this card) | “This card has expired.” Detectable on the front end as soon as the date is entered: don’t let this decline happen. |
| 14 | Invalid card number | Hard | Client-side Luhn check before any call: this error should never reach the issuer. |
| 41 / 43 | Lost / stolen card | Hard | Generic message. Never invite a retry or reveal the reason. Offer another method. |
| 57 | Transaction not permitted to cardholder | Hard | Unsuitable card (e.g., a card that requires authorization on every transaction): offer another method. |
| 59 | Suspected fraud | Soft/Hard | Completely neutral generic message. Never say “fraud,” whether to a possible fraudster or to an honest customer. |
| 61 | Payment limit exceeded | Soft | “Your card limit appears to have been reached.” Suggest calling the bank, paying in installments, or paying by bank transfer. |
| 91 | Issuer unavailable | Soft | Delayed automatic retry on the server side; on the client side, “please try again in a moment.” |
| 1A / 65 | Authentication required (SCA soft decline) | Soft | Automatic 3-D Secure resubmission by the PSP. The customer must never see this decline. |
Four golden rules for payment error messages
- Say what happened without blaming the customer: “your bank didn’t authorize this payment” rather than “your card was declined.” The decline comes from the issuer, so say so: it points the customer to the right party.
- Always offer a way out: another card, a wallet, a bank transfer, trying again later. An error message with no next step is a commercial dead end.
- Preserve state: the cart stays intact, fields stay filled in (except the CVV), and the customer never goes back to square one. A customer who has to re-enter everything after a decline is a lost customer.
- Never reveal anything exploitable: don’t distinguish “stolen card” from “generic decline” on screen, because fraudsters test cards precisely to read those responses. The details go in your logs, not in front of the shopper.
{
"05": { "retry": true, "message": "Your bank didn't authorize this payment. Try again or choose another payment method." },
"51": { "retry": true, "message": "Payment not authorized. Try another payment method or pay in installments." },
"54": { "retry": false, "message": "This card has expired. Please use a valid card." },
"41": { "retry": false, "message": "This payment couldn't be completed. Please use another payment method." },
"43": { "retry": false, "message": "This payment couldn't be completed. Please use another payment method." },
"91": { "retry": true, "message": "Service temporarily unavailable. Please try again in a moment." },
"1A": { "retry": "auto-3ds", "message": null }
}Chapter 6. A/B testing: experimenting without fooling yourself.
Everything above gives you solid hypotheses, but every site has its own customers, average order value, and device mix. The only truth is experimental. An A/B test compares two versions of the checkout on randomly assigned groups and measures the difference. Done badly, it produces false certainty, which is more dangerous than ignorance. Done well, it turns checkout into a learning machine.
Common pitfalls that invalidate a test
- Peeking: checking results every day and stopping as soon as “it becomes significant.” Look often enough and you will always hit a false positive. The fix: set the duration and sample size before launch and stick to them (or use sequential methods designed for this).
- Too small a sample: with a baseline conversion rate of ~2–3%, detecting a 10% relative improvement takes tens of thousands of sessions per variant. On a small site, run fewer, bolder tests.
- SRM (sample ratio mismatch): you expected 50/50 and see 53/47, which means randomization is broken (a script bug, caching, bots). Any result is then invalid, however attractive it looks.
- The wrong metric: measuring clicks on “Pay” rather than successful payments (authorized ones!), or conversion rather than revenue per session, even though a test can raise conversion by attracting smaller orders.
- A contaminated context: a sale, a TV campaign, or a PSP switch in the middle of the test. A clean test runs in a stable environment.
- Ignoring segments: an overall gain can hide +8% on desktop and -6% on mobile. Always read mobile and desktop separately, but don’t slice the data into 40 segments until a winner appears (that’s peeking in disguise).
| Metric | Definition | Role in the test |
|---|---|---|
| Checkout conversion | Successful payments / checkout starts | Most common primary metric |
| Revenue per session | Revenue / exposed sessions | Primary when the variant can change average order value |
| Authorization rate | Authorized payments / attempts | Guardrail: a variant must not lower the approval rate |
| Form error rate | Sessions with at least one field error | Diagnostic: explains why a variant wins |
| Time to complete | Median time from cart to confirmation | Friction diagnostic |
| Wallet / card / BNPL share | Breakdown of chosen methods | Guardrail: watch for shifts in the payment mix (and their costs) |
Chapter 7. Baymard benchmarks and action plan.
The Baymard Institute continuously audits the world’s largest e-commerce sites against several hundred UX guidelines drawn from user testing. The verdict never changes: even industry leaders have dozens of violations in their checkout. Nobody is done, and the benchmark’s main use is setting priorities. Here is the course’s practical summary.
autocomplete and inputmode attributes, client-side Luhn check, persistent labels, translated decline messages, collapsed promo code field, a one-line CVV explanation.- Measure before changing anything: instrument every funnel step and the authorization rate by decline code. A week of data beats a month of opinions.
- Subtract: every field and every step must justify its existence. Target: 7–8 fields for a guest order.
- Prioritize mobile: that’s where the volume and the friction are, and where wallets make the biggest difference.
- Treat the decline as a UX step: translated messages, cart preserved, an immediate alternative, soft declines resubmitted with 3DS.
- Experiment cleanly: one hypothesis per test, sample size set in advance, SRM checked, segments read honestly.
- Audit accessibility: compliance with the EAA, in force since June 28, 2025, is also your best conversion checklist.