# Checkout Page > How to design a checkout page that turns carts into completed sales: key decisions, a step-by-step anatomy, mobile design, security and SEO. - Type: Store page blueprint - Level: Intermediate - Reading time: About 23 minutes - Audience: Written for store owners, builders, and designers refining high-performance ecommerce stores. - Last updated: 2026-10-15 - Canonical page: https://academy.getzenbasket.com/store-pages/checkout-page/ - Part of: [Store pages](https://academy.getzenbasket.com/store-pages/) on ZenBasket Academy --- ## Six decisions to make before you open a design tool ### Decision 1: Guest checkout, and how prominent? Offer it. Around 18% of abandoners cite forced account creation, making it one of the top four reasons overall. The pattern that works: guest checkout as the visually dominant path, sign-in available for those who want it, and an *optional* account creation offer **after** the order is placed, when you already have their details and only need a password. ### Decision 2: One page or multiple steps? Both work. What matters far more is the number of fields and the clarity of each step. Decide early because it shapes the whole build. A rough guide: multi-step accordion suits physical goods with shipping and payment complexity; a single page suits short checkouts with few fields; digital goods often need only one screen. ### Decision 3: Which payment methods? This is a market question, not a design one. In India that usually means UPI, cards, net banking, wallets, EMI and often cash on delivery; in the US, cards, digital wallets and buy-now-pay-later. Research what your actual customers use before designing the payment step, because the answer determines its layout. ### Decision 4: Address entry, lookup or manual? Address forms are the longest part of most checkouts. A postcode or pincode lookup can remove three or four fields of typing, and it reduces failed deliveries. Decide now whether you are integrating one, because the form design differs. ### Decision 5: What are you actually selling? Physical goods need shipping address, delivery method and date. Digital goods need an email address and nothing else: asking a customer for a shipping address for a downloadable file is a needless step that also signals carelessness. Subscriptions need renewal terms and cancellation information stated before payment. Services need scheduling. Do not use one checkout template for all of them. ### Decision 6: Do you sell across borders? International checkout adds country-specific address formats, currency display, customs and duty disclosure, and different payment preferences per market. If you sell to one country, do not build the generic international address form: a form designed for one country's address structure is dramatically shorter and less error-prone. ![3](https://bloggallery.s3.us-west-2.amazonaws.com/Zenbasket%20Docs/3_1791199791752.png) --- ## The anatomy of a checkout, step by step ![2](https://bloggallery.s3.us-west-2.amazonaws.com/Zenbasket%20Docs/2_1791199776661.png) ### Zone 0: The slim header Checkout is the one page where you deliberately remove navigation. Keep the logo (linked to the store, so a lost shopper can get back), a progress indicator if you use steps, and a security cue. Remove the main menu, search, promotional banners, cross-sells and chat pop-ups. Every one of those is an exit. Keep the footer minimal too, but do not remove it entirely: links to returns, shipping policy, privacy and contact belong here, because these are the questions a hesitating shopper wants answered without losing their form data. Open them in a modal or new tab rather than navigating away. ### Zone 1: Express payment If you support wallet or UPI-style express payment, put those buttons at the very top, above the form, with a clear "or" divider beneath. A returning customer using express payment can skip almost the entire form. Placing these buttons below the form, which is common, means the shopper has already done the work they were meant to avoid. ### Zone 2: Account selection Three options, in this order of visual weight: continue as guest (most prominent), sign in (available but quieter), create account (offered after purchase, not here). Use a clear heading and enough separation that the guest path cannot be missed: remember that in mobile testing about 60% of participants struggled to find it. If you sign people in, do it without losing their cart or their position in the flow. Returning a signed-in shopper to an empty cart is a self-inflicted lost order. ### Zone 3: Contact information Email address is genuinely required: it is where the receipt and tracking go. Phone number often is not. If your courier genuinely needs it, say so in one line next to the field: "For delivery updates from our courier." If it is for your marketing, make it optional. *(* Marketing consent is a checkbox, unticked by default, with plain wording. Pre-ticked consent is unlawful in several jurisdictions and corrosive everywhere. ### Zone 4: Shipping address The longest part of most checkouts and the easiest to shorten. Lead with the pincode or postcode and auto-fill city and state from it. Offer address lookup or autocomplete where you can. Use one field for street address with an optional second line, not four separate boxes. Set correct autocomplete attributes so the browser can fill the whole block in one tap: this single technical detail saves more time than most design changes. ### Zone 5: Delivery method Show each option with its cost *and* its arrival date, not a duration. "Arrives Saturday, 5 September: free" is a decision a shopper can make; "3–5 business days: ₹0" makes them do arithmetic against a calendar. Given that slow delivery is the second most cited abandonment reason, this is the moment to be specific and honest rather than vague. Pre-select the most sensible default (usually the free or standard option) so a shopper who does not care can move on. ### Zone 6: Payment Present the methods your customers actually use, with recognisable names and logos, and remember the selection for returning shoppers. Card details should be collected through your payment provider's hosted fields or an embedded frame, so raw card data never touches your servers: this is both the secure design and the one that keeps your PCI DSS scope small. Do not build your own card form. ### Zone 7: The order summary Persistent, not a step. On desktop it is a sidebar that stays visible; on mobile it is a collapsed panel at the top that expands on tap, showing the total even when collapsed. It carries item names, thumbnails, quantities, subtotal, delivery, tax, discounts and the final total, plus the delivery date and returns window, which is where a wavering shopper looks for reassurance. ### Zone 8: Placing the order One primary button, labelled with what it does, such as "Place order" or "Pay \$17.45", not "Continue" or "Submit". Show the amount on or beside the button. Disable it on click and show a clear loading state, so nobody double-submits. If payment redirects to a bank or UPI app, say so beforehand: "You will be taken to your bank to authorise this payment." Unexplained redirects read as something going wrong. ### Zone 9: Validation and errors (cross-cutting) Validate inline, as the shopper leaves each field, not only on submit. Say specifically what is wrong and how to fix it: "Enter a 6-digit pincode", not "Invalid". Keep every other field's data intact, including card fields, which around 34% of sites wipe. Move focus to the first error and announce it. Never clear a form because one field failed. --- ## Design decisions with real trade-offs ### One-page checkout or multi-step? **Recommendation:** a single page with clearly grouped, numbered sections (the accordion pattern) for most stores. The one-page-versus-multi-step debate is largely a distraction; the evidence points to field count and clarity mattering far more than page count. A single page with grouped sections gets the best of both: the shopper sees the whole scope at once (no dread about how many steps remain) while each section is presented one at a time. Genuine multi-step pages are still reasonable for long or complex checkouts, but they must show a progress indicator, allow moving backwards without losing data, and never re-ask for something already given. ### Where does the coupon field go? This is the most underrated damage in checkout design. A large, prominent "Discount code" box tells every shopper without a code that they are paying more than someone else, and sends a proportion of them off to search for one, many of whom never come back. ### Should you require an account? No. It is among the top handful of stated abandonment reasons, and the business benefit is almost entirely recoverable by offering account creation on the confirmation page, where the customer already trusts you and you already hold their details. At that point you are asking for one thing: a password. ### Address lookup or manual entry? Lookup where you can afford it. It removes fields, reduces failed deliveries and cuts support load. But always leave a manual override visible: lookup services miss new developments, rural addresses and unusual buildings, and a shopper who cannot find their address in a dropdown with no way to type it has hit a wall. ### Should the order summary be open or collapsed on mobile? Collapsed, but with the total always visible in the collapsed state. A fully expanded summary at the top of a mobile checkout pushes the first form field below the fold; a fully hidden one leaves the shopper unsure what they are paying. The collapsed-with-total pattern is the compromise, and it is now common enough to be familiar. ### Cross-sells at checkout: yes or no? Generally no, and never before payment. Once the shopper is in the flow, an offer is a distraction competing with the action you want. The safe places for an add-on are the cart page, before checkout begins, and the order confirmation page afterwards. If you must include one in checkout, keep it small, relevant and impossible to add accidentally. ### Progress indicators: helpful or pressure? Helpful when honest. A three-step indicator that turns out to have a hidden fourth step destroys trust at the worst moment. Label steps by content ("Delivery", "Payment"), not by number alone, and never show progress you cannot honour. ### Should you use a CAPTCHA at checkout? Avoid it on the payment path if at all possible. Use invisible or risk-based bot protection instead, and if you genuinely must challenge someone, do it before checkout, not between them and the pay button. --- ## Designing for mobile first Mobile checkout is the hardest surface in ecommerce. The touch keyboard occupies roughly half the screen in portrait and more in landscape, so the shopper often sees one or two fields at a time with no sense of where they are. Design for that, rather than for the full-page view you see in a browser. ### Label every field independently Because context disappears, a field labelled just "Phone" is ambiguous when it is the only thing on screen. "Delivery phone" or "Billing phone" costs nothing and removes the doubt. Keep labels above the field, always visible, never as placeholder text that vanishes. ### Get the keyboard right - Email fields open the email keyboard; phone and card fields open the numeric keypad. - Turn off auto-correct and auto-capitalise on address, email and card fields. - Set correct autocomplete attributes throughout so the browser or password manager can fill the block in one tap. - Use inputmode alongside field type for numeric entry. - Never disable paste: people paste addresses and codes constantly. ### Reduce typing before you optimise it Auto-detect country from location, auto-fill city and state from the pincode, and offer address lookup. Every field removed is worth more than any field improved. Support express payment methods prominently: for a returning customer they can bypass the form entirely, which is the single largest mobile improvement available to most stores. ### Layout and controls - One field per row. Side-by-side fields on a phone cause mis-taps and truncated labels. - Tap targets of at least 44 × 44 CSS pixels; radio and checkbox rows should be tappable across the whole row, not just the control. - Text inputs at 16 pixels or larger, so mobile browsers do not zoom on focus and shift the layout. - A sticky footer showing the total and the primary action, so the shopper always knows the amount and the next step. - Never open a new tab or app mid-flow without warning: returning to a lost form is a common way to lose an order. ![4](https://bloggallery.s3.us-west-2.amazonaws.com/Zenbasket%20Docs/4_1791199828557.png) --- ## SEO, indexing and security ### Checkout should not be indexed This is the one store page where the correct SEO answer is to stay out of search results entirely. Checkout, cart and account pages carry no search value, can expose session or order parameters, and waste crawl budget. --- ## Frequently asked questions ### What should a checkout page include? A slim header without navigation, express payment options at the top, a prominent guest checkout choice, contact details, shipping address, delivery method with cost and arrival date, payment method selection, a persistent order summary showing the full total, and one clearly labelled place-order button. Everything else should be justified individually. ### Why do customers abandon checkout? Website errors, an unsatisfactory returns policy, inability to see the total upfront, declined cards and too few payment methods follow. Most of the top reasons are information and policy problems rather than form design problems. ### Where should the discount code field go? Demoted to a small "Have a discount code?" link inside the order summary that expands a field when clicked. A large, prominent coupon box signals to every shopper without a code that they are overpaying, and sends a share of them off-site to hunt for one. Removing it entirely is not the answer either, because it frustrates people holding a legitimate code. ### Should I ask for a phone number at checkout? Only if you genuinely need it, and then explain why in one line beside the field. Baymard found roughly 39% of sites do not explain the requirement and about 14% of shoppers will abandon over an unexplained required phone field. If the courier needs it for delivery updates, say exactly that; if it is for marketing, make it optional. ### Should the checkout show the delivery date or the number of days? A date. "Arrives Saturday, 5 September" is a decision a shopper can make immediately; "3–5 business days" makes them work it out against a calendar and quietly overestimate. Given that slow delivery is the second most cited abandonment reason, this is a place to be specific rather than vague. ### Should I remove navigation from the checkout page? Yes. Keep the logo linked to the store, a progress indicator if you use steps, and a security cue. Remove the main menu, search, promotional banners and cross-sells, since each is an exit from a task the shopper had already committed to. Keep minimal footer links to returns, shipping, privacy and contact, opened in a modal or new tab so form data is not lost. ### How do I make checkout feel secure? Through visible competence rather than badges: HTTPS across the whole site, the correct domain in the address bar, a checkout that looks like the rest of the store, recognisable payment brands, a stated returns policy, real contact details, and no unexplained requests for personal information. Use your payment provider's hosted fields so card data never reaches your servers. ### Should billing address be required separately from shipping? Default it to the shipping address with a ticked checkbox, and reveal the billing fields only when it is unticked. For most orders the two are identical, so asking separately duplicates typing the shopper has already done. If your payment provider does not require a billing address, do not ask for one at all. ### How do I handle a declined payment? Say clearly that the payment did not go through and that the customer has not been charged, keep the order and all entered details intact, and offer an alternative payment method immediately. Around 10% of abandonment involves a declined card, and a large share of those are recoverable if the shopper is not dumped back to an empty cart with a vague error. --- ## Building this in ZenBasket Everything above is platform-independent. If you are building with [ZenBasket](https://getzenbasket.com/), the checkout arrives with the structural decisions in this guide already made, so the work is configuration and content rather than building a payment flow from scratch. - Guest checkout available by default, with post-purchase account creation - [Payment methods](https://help.getzenbasket.com/connect-payments/) configurable for your market, including UPI, cards, net banking, wallets and cash on delivery - Pincode-based [serviceability and delivery estimates](https://help.getzenbasket.com/shipping-pickup/) - Card data handled through the payment provider, so it never touches your store - Mobile-optimised form behaviour and a persistent order summary by default In the meantime, the [ZenBasket Builder Help Center](https://help.getzenbasket.com/zenbasket-builder/) covers setup instructions today, including [Manual Discounts](https://help.getzenbasket.com/discounts/manual-discounts/) for configuring the coupon field discussed above. Prefer to watch it built? The [ZenBasket Builder video playlist](https://youtube.com/playlist?list=PLaCV5NxaAlPc&si=ZZAwGXLWRpEOlfaG) walks through customizing page sections step by step.