# React Checkout Page: Cart, Steps, Coupons and a Pay Bar
> Build a React checkout page from cart to confirmation: four checkout steps, coupons that recheck, a sticky pay bar on phones and form details that cut drop-off.
- Author: [Serban Rusu](https://wingo-ui.com/blog/authors/serban), Founder of Wingo UI
- Published: Oct 16, 2026
- Category: [Build it: screens and apps](https://wingo-ui.com/blog/category/build)
- Reading time: 12 min
- Canonical: https://wingo-ui.com/blog/react-checkout-page
## TL;DR
A React checkout page needs three stages: a cart that edits quantities and coupons with the total always visible, four checkout steps (address, delivery, payment, review) that validate one step at a time and keep data on Back, and a confirmation that takes focus. On phones, keep the total and the main button in a sticky bar above the home indicator and hide it while the keyboard is open. The Wingo UI Checkout Page block does all of this; you wire up the cart API, the coupon check and the order call.
Most tutorials for a React checkout page stop at a form with a Pay button. The real work sits around that form: a cart that edits quantities without losing the total, coupon codes that stop applying when the cart shrinks, a step that fails without wiping what the buyer typed, and a pay button that stays under the thumb on a phone. This tutorial builds the whole flow, from cart to confirmation, with the [Checkout Page](https://wingo-ui.com/components/checkout-page) block from Wingo UI, the library we build, and shows the smaller parts you can use on their own.
## What does a React checkout page need?
It needs three stages and a short list of details that decide whether people finish. The stages:
1. **Cart.** Lines with quantity steppers, remove with undo, a free delivery bar, a coupon field and a summary whose total updates on every change.
2. **Checkout steps.** Address, delivery, payment and review. Each step validates on Continue, Back keeps everything, and the review step places the order and shows a refusal in place.
3. **Confirmation.** The order number, the email it went to, Track order and Continue shopping, with focus moved to the heading so a screen reader announces it.
The details come from research on why people leave. Baymard Institute's [cart abandonment page](https://baymard.com/lists/cart-abandonment-rate) (updated September 22, 2025) lists the top reasons shoppers in its survey gave for abandoning a checkout: extra costs too high (40%), slow delivery (20%), not trusting the site with card details (19%), required account creation (18%) and a checkout that was too long or complicated (17%). Another 12% could not see or calculate the total up front. Four of those are UI problems: show the total and delivery cost early, allow guest checkout, keep the form short, and make the payment step look trustworthy.
Baymard's [checkout benchmark](https://baymard.com/blog/checkout-flow-average-form-fields) (published June 26, 2024) puts the average checkout at 5.1 steps and 11.3 form fields, and says most sites need only 8 fields. Fields cost more than steps, so the checkout below asks for one name field instead of first and last, and hides the company fields behind a switch.
Install the block. The CLI pulls in the cart, steps, coupon, sticky bar and order tracker it composes:
```bash
npx wingo-ui@latest add checkout-page
```
> Live demo (Checkout Page): Change a quantity and watch the free delivery bar and the total follow, apply FALL15 in the coupon field, then press Continue to delivery and go through the four steps. On a narrow screen, scroll past the summary and the sticky bar with the total slides up. Try it at [Checkout Page](https://wingo-ui.com/components/checkout-page) and install it with `npx wingo-ui@latest add checkout-page`.
## How do I wire the checkout page into Next.js?
Render `CheckoutPage` in a client component and hand it four callbacks: one that saves the cart, one that checks a coupon on the server, one that places the order and one that opens the order. The block owns the stages, the step state, focus and the transitions. It works as a checkout page template in one import: every string sits in `labels` and every visual choice is a prop.
One pitfall first. The checkout steps inside the block default to Romanian rules (6 digit postal codes, the CUI tax ID check, phones starting at +40), and the block has no country prop of its own. A US ZIP code such as 94103 then fails the address step with "The postal code has 6 digits". With a non-Romanian `locale` the block already swaps the county picker for US states, but the country rules stay. Set the country once through `UIProvider` defaults, which the steps read for any prop the block leaves out, and rename the company fields through `labels.checkout`:
```tsx
// app/(shop)/cart/checkout.tsx
"use client";
import { useRouter } from "next/navigation";
import { CheckoutPage, type CheckoutPageProps } from "@/components/blocks/checkout-page";
import type { CouponResult } from "@/components/ui/coupon-input";
import { UIProvider } from "@/lib/ui-config";
// US postal codes and phones in the address step; tax IDs are no longer checked as Romanian CUIs
const US_CHECKOUT = { "checkout-steps": { country: "US" } };
// the company fields keep their Romanian names and placeholders unless you rename them
const US_COMPANY_LABELS = {
cui: "Tax ID (EIN)",
cuiPlaceholder: "12-3456789",
regCom: "State registration no. (optional)",
regComPlaceholder: "",
};
type ShopData = Pick<
CheckoutPageProps,
"defaultItems" | "coupons" | "savedAddresses" | "deliveryMethods" | "lockers" | "paymentMethods" | "customerEmail" | "guest"
>;
export function Checkout(shop: ShopData) {
const router = useRouter();
return (
fetch("/api/cart", { method: "PUT", body: JSON.stringify(items) })
}
onApplyCoupon={async (code): Promise => {
const response = await fetch("/api/coupons/check", {
method: "POST",
body: JSON.stringify({ code }),
});
if (!response.ok) return { ok: false, error: "We don't recognize that code" };
return (await response.json()) as CouponResult;
}}
onPlaceOrder={async (value, totals) => {
const response = await fetch("/api/orders", {
method: "POST",
body: JSON.stringify({ value, total: totals.total }),
});
// the message shows on the review step, above Place order
if (!response.ok) throw new Error(await response.text());
return (await response.json()) as { orderNumber: string };
}}
onTrackOrder={(orderNumber) => router.push(`/account/orders/${orderNumber}`)}
onContinueShopping={() => router.push("/")}
/>
);
}
```
The page itself stays a server component that loads the data. `getCart` and `getShop` stand for your own data layer:
```tsx
// app/(shop)/cart/page.tsx
import { getCart, getShop } from "@/lib/shop";
import { Checkout } from "./checkout";
export default async function CartPage() {
const [cart, shop] = await Promise.all([getCart(), getShop()]);
return (
);
}
```
Every data prop you leave out falls back to the block's sample shop (including the sample buyer's email when `customerEmail` is undefined), which is why the wrapper passes the cart, the coupons, the addresses, the delivery methods with their lockers, the payment methods and an empty `recommended` rail. Use `items` with `onItemsChange` instead of `defaultItems` when another part of the page, such as a header badge, also reads the cart. Each line is a `CartItem`: `id`, `title`, `price`, `quantity`, and optionally `compareAtPrice`, `maxQuantity`, `taxRate`, `image`, `variant` and `href`. `guest` drops the saved addresses and the prefilled email and adds a Create an account hint to the confirmation, so nobody is asked for an account up front. Save for later confirms itself with a toast, so mount `` from `@/components/ui/toast` once in the shop layout.
Two rules for the server side. First, recompute the total from your own prices and never trust `totals.total` from the browser. The block sums the cart with `computeCartTotals` from `@/lib/commerce`, a plain module without `"use client"`, so a route handler can run the same math and reject an order whose total moved:
```ts
// app/api/orders/route.ts
import { computeCartTotals } from "@/lib/commerce";
import type { CheckoutValue } from "@/components/ui/checkout-steps";
import { getCart, getShop } from "@/lib/shop";
export async function POST(request: Request) {
const { value, total } = (await request.json()) as { value: CheckoutValue; total: number };
const [cart, shop] = await Promise.all([getCart(), getShop()]);
const method = shop.deliveryMethods.find((m) => m.id === value.deliveryMethod);
const payment = shop.paymentMethods.find((m) => m.id === value.paymentMethod);
// applied codes, in the order the buyer added them, looked up in your own catalogue
const coupons = (value.coupons ?? []).flatMap((applied) => shop.coupons.filter((c) => c.code === applied.code));
const totals = computeCartTotals(cart.items, {
coupons,
shipping: method?.price ?? null,
// the steps' rule: a method's freeFrom wins, pickup never takes the threshold
freeShippingThreshold: method?.freeFrom ?? (method?.type === "pickup" ? 0 : 250),
});
const expected = totals.total + (payment?.fee ?? 0);
if (Math.abs(expected - total) > 0.005) {
return new Response("Prices changed while you were checking out. Review the total and place the order again.", { status: 409 });
}
// charge `expected`, store the order, then answer with its number
return Response.json({ orderNumber: "1043" });
}
```
Second, keep the response honest: a declined card should be a non-2xx response with a message the buyer can act on, because the block shows that message above Place order and keeps the review step open.
## How should the React cart page handle quantities and coupons?
Every change to the cart moves the total, and nothing the buyer does is lost without a way back. The cart stage follows four rules:
- **Every change moves the summary.** Steppers, removals and coupons update the subtotal, the savings badge, the delivery estimate and the total in place, so the buyer never wonders what they will pay.
- **Removal is undoable.** The × (or a swipe left on touch) folds the line into a row with Undo and a five second countdown. Save for later moves a line to a list below the cart instead of deleting it.
- **Free delivery is visible.** A bar shows how much more is needed and turns green at the threshold, which answers the "extra costs" question before checkout starts.
- **Coupons recheck.** A code with a minimum order is rechecked when a quantity changes. If it stops applying, the block removes it and says why, instead of showing a discount the server will refuse.
The coupon field is the [Coupon Input](https://wingo-ui.com/components/coupon-input), and it works on its own in any cart. Give it a local catalogue for instant checks, or `onApply` for a server check that resolves `{ ok: true, coupon }` or `{ ok: false, error }`:
```tsx
"use client";
import { useState } from "react";
import { CouponInput, type AppliedCoupon } from "@/components/ui/coupon-input";
import type { Coupon } from "@/lib/commerce";
const COUPONS: Coupon[] = [
{ code: "FALL15", type: "percent", value: 15, maxDiscount: 150, label: "Fall sale" },
{ code: "FREESHIP", type: "shipping", value: 0, label: "Free delivery" },
{ code: "SAVE50", type: "fixed", value: 50, minSubtotal: 300 },
];
export function CartCoupon({ subtotal, shipping }: { subtotal: number; shipping: number }) {
const [applied, setApplied] = useState([]);
return (
);
}
```
Pass the items' `subtotal` and the current `shipping` cost on every render, in the same currency units as the coupon values (dollars, not cents). They are what a catalogue code is checked against, and when they change, applied codes recount what they save. A code that no longer applies turns amber with a note under it, so the buyer sees why the discount went before the server refuses it.
> Live demo (Coupon input): Open "Have a promo code?", type save50 and press Enter: it is upper-cased, checked and lands as a chip. Remove it and try big200 to see how much more the cart needs. Try it at [Coupon input](https://wingo-ui.com/components/coupon-input) and install it with `npx wingo-ui@latest add coupon-input`.
Enter inside the coupon field never submits the checkout form around it, which is a common bug when the code field sits inside a `