How do cart and checkout work?

What you will learn

By the end, you will understand:

Follow cart, checkout, authorization, capture and order states
Understand gateway/provider, processor, issuer and payment-method roles
Design idempotent confirmation and failure recovery

Visual explainer

See the idea clearly.

Cart items enter checkout, validated order details create a payment request, issuer authorizes or declines, the server verifies an event, inventory and order state update once, and confirmation is sent.

Cart and checkout have different jobs

Cart

A temporary list of intended products, quantities, price context and promotions.

Checkout

The process of confirming identity/contact, delivery, tax, payment, terms and final order.

Payment participants

Role	Job
Merchant/store	Creates the order, amount, terms and fulfilment obligation.
Payment service/gateway	Securely connects checkout to payment processing and methods.
Processor/acquirer/network	Routes and processes the transaction under payment rules.
Issuer/wallet/bank	Authenticates and approves or declines according to method/account.
Customer	Provides method and completes required authentication/authorization.

A simplified card payment flow

01
Create server-side amount/order reference
02
Collect method through approved payment UI
03
Request confirmation/authentication
04
Receive authorization result
05
Verify signed server webhook/event
06
Apply idempotently
07
Mark paid/authorized state
08
Allocate fulfilment
09
Send accurate confirmation

Authorization and capture can differ

Authorization confirms that a payment can be reserved/approved under current conditions; capture completes the charge. Some businesses capture immediately, others after stock/service checks according to provider and network rules.

A successful-looking redirect is not sufficient evidence. The customer can close the browser, callbacks can repeat and network responses can be delayed.

Idempotency prevents duplicate effects

Retries are normal. The same payment or webhook event must not create two orders, reduce stock twice or send conflicting confirmations. Use provider event IDs and business order keys with transactional handling.

Never trust price or paid state supplied only by browser fields. Recalculate and verify server-side.

Checkout quality checklist

Guest/account choice justified
Persistent labels
Address validation without blocking legitimate formats
Final item/price/fees
Delivery/returns
Promo behavior
Accessible errors
Authentication recovery
No duplicate submission
Pending/declined states
Order reference
Receipt/support route
Consent separation

Real-world example

Example: webhook arrives twice

Example

A payment provider retries the same successful event because the store did not respond quickly. The server recognizes the event ID, returns success and leaves the already-created order unchanged. Without idempotency, the warehouse could receive two orders.

Try this

Draw the failure states

Map success plus validation error, payment decline, authentication abandoned, webhook delayed, duplicate event, out-of-stock and refund. Define customer message, order state, stock effect and staff action for each.

Common questions

Questions beginners ask.

What is a shopping cart?

A temporary collection of intended items and quantities before order completion.

What is checkout?

The process of confirming order, customer, delivery, payment and terms.

What is payment authorization?

Approval/reservation from the payment chain indicating the transaction may proceed under current conditions.

What is capture?

The step that completes/settles an authorized charge according to the payment flow.

What is a webhook?

A server-to-server event notification from a provider that should be authenticated and handled safely.

What is idempotency?

Processing repeated identical requests/events without repeating the business effect.

Should card numbers be stored by the store?

Avoid direct storage unless there is a justified compliant architecture; use approved provider-hosted/tokenized methods.

Why can payment succeed after the browser closes?

Server-side processing/events can complete independently of the customer’s current page.

Assessment

Check what you understood.

5 questions · instant explanations

1. What should confirm a paid order?

2. What is idempotency for?

3. What is capture?

4. Where should final price be verified?

5. True or false: repeated webhook events should create repeated orders.

Sources

How do cart, checkout and online payments work?