Cash and no-payment checkout states
Customer App can present cash, card-at-delivery-style, other payment-method, wallet, or no-payment-looking states. These are tender and checkout states, not proof that the current balance is authoritative or that an order was placed.
:::warning Free does not mean no effect
A zero-balance or “no payment needed” presentation can still lead to cart locking, anti-abuse checks, order creation, wallet or loyalty work, jobs, plugins, sockets, notifications, and other downstream effects. It is never a safe read-only placement path.
:::
Distinguish tender from settlement
| Visible state | Safe interpretation | What it does not prove |
|---|---|---|
| Cash method | Ordering can record a cash tender choice and optional tendered-cash information. | Sufficient tender, accepted paymethod, collected cash, change due, or placed order. |
| Card at delivery | Ordering can record a non-online card tender for later operational collection. | Online authorization, device availability, successful collection, or placed order. |
| Online/provider method | A method can begin provider-specific selection, challenge, return, or confirmation. | Ordering payment or order settlement. |
| Zero/free-looking balance | The current cart presentation treats its balance as zero and hides ordinary payment choices. | Canonical final total, no wallet movement, no order mutation, or successful placement. |
| Positive balance without a method | Checkout still requires an accepted payment-method state. | That cash, card at delivery, or another option is available. |
Method visibility depends on current cart, business, account, order type, configuration, provider, and device state. A missing method does not reveal why it is unavailable.
Cash tender UI and persistence differ
The cash UI can accept a tendered-cash value and compare it with the currently displayed order total. That client comparison is not authoritative financial validation. Cash data then follows a generic payment-method persistence path, which can settle separately from the visible input.
| Layer | Boundary |
|---|---|
| Typed cash state | Local input only; it can be incomplete, malformed, cleared, or below the displayed total. |
| Delayed validation | A short client timer delays parsing and forwarding; an older callback can become stale after input, cart, total, method, or screen changes. |
| Local sufficiency error | Prevents current Place presentation from proceeding; it is not server tender validation. |
| Paymethod persistence | Stores method/tender data through the checkout controller; response, cart refresh, and Place authority remain separate. |
| Server placement | Must validate current balance, tender rules, cart revision, account, business, currency, and order policy again. |
Leaving the field, changing the method, or seeing an error disappear does not prove that stale timer work was canceled or that the saved tender matches the current cart.
Balance, totals, and free-order authority
The free-looking branch is chosen from the current cart balance available to the UI. Balance, subtotal, discounts, coupons, fees, taxes, tips, wallet use, loyalty, refunds, and payment events can have separate sources and revisions.
A zero displayed balance must be revalidated against one locked, server-authoritative minor-unit amount and currency before placement. Changes to products, quantities, options, business, address, fulfillment, schedule, coupon, tip, wallet, or account can invalidate the free-looking state.
Do not infer that a free-looking cart has no financial reporting, fulfillment, notification, fraud, tax, fee, loyalty, or accounting consequences.
Place, lock, idempotency, and reCAPTCHA
Place is a separate destructive operation for cash, card-at-delivery, online, wallet, and free-looking states.
| Requirement | Safe boundary |
|---|---|
| Current cart revision | Product, option, amount, address, fulfillment, customer, and business state must match the placement input. |
| Server lock | One current operation owns placement; a visible busy state is not proof of a durable lock. |
| Idempotency receipt | Repeated, concurrent, restarted, or lost-response attempts must resolve to one operation result. |
| reCAPTCHA or anti-abuse | A challenge result must be bound to the same current placement operation; it is not payment or order approval. |
| Tender validation | Cash/free/provider/wallet state must be validated server-side against the locked cart. |
| Authoritative result | Must identify accepted, rejected, conflict, partial, or unknown settlement without exposing private operation data. |
An enabled Place control or completed challenge is local pre-action state, not authorization to infer success.
Downstream wallet, order, job, socket, and plugin effects
Even without an online charge, placement can affect several systems:
- cart and order records;
- wallet or loyalty reservations, debits, credits, reversals, or accrual;
- payment/tender and financial summaries;
- background jobs, fulfillment, notifications, and reporting;
- plugin or webhook actions;
- socket events and local order/cart state; and
- navigation to a returned order surface.
These stages require one recoverable operation contract. Navigation, a toast, a cleared cart, or an order screen does not prove that all downstream effects settled exactly once.
Partial and unknown outcomes
| Observable outcome | Safe interpretation |
|---|---|
| Cash error appears late | The delayed client check used one input/total state; persisted tender and current cart can still differ. |
| Cash error disappears | Local sufficiency changed; no paymethod or Place receipt follows. |
| Free-looking state changes to paid | A balance-affecting layer changed; prior Place authority is stale. |
| Place remains busy | Lock, challenge, payment, wallet, order, job, or response can still be pending. |
| Challenge succeeds but Place errors | Anti-abuse and placement are separate. |
| Order appears but cart/wallet remains inconsistent | Partial settlement; do not call the operation complete. |
| Cart clears but no order appears | Cart and order stages diverged; outcome remains unknown. |
| Response is lost or app restarts | Do not automatically repeat Place without the original operation receipt. |
| Grouped carts settle differently | Exact group membership and per-cart results are required; no whole-group success inference. |
Guest, session, and provider boundaries
Guest or newly converted account state can change tender availability and Place authority. A guest capability, Login/Signup result, provider callback, or notification-installation state must belong to the same current account, project, session, cart, and operation generation.
Cash and free-looking paths do not bypass identity, address, student, guest, coupon, card, wallet, provider, or other required checkout rules.
Troubleshooting safely
- Treat cash input and its delayed validation as unsettled until the current cart and method state agree.
- A no-payment message is not proof that Place has no effects or requirements.
- Do not use a different payment method, wallet, coupon, tip, or cart change to test an unknown outcome.
- Do not repeat Place, confirmation, reCAPTCHA, or provider work after a lost response without an authoritative operation receipt.
- Keep tender, amounts, cart/order/account references, payment data, challenge results, provider values, and screenshots out of diagnostics.
- Use only value-free state classes such as “cash tender unresolved” or “free-looking placement unknown.”
Accessibility and privacy
Tender type, input, local validation, balance, no-payment message, method, wallet, Place, anti-abuse, busy, error, partial, unknown, and safe-return states need clear semantic names, roles, values, consequences, focus order, and announcements. Large text, keyboard, screen-reader, Back, modal, and provider- return behavior must not hide current tender or operation state.
These are verification requirements, not a current accessibility, privacy, financial, provider, or order-placement certification.
When to recertify
Repeat isolated review after changes to cash input/timers, tender persistence, card-at-delivery methods, free-balance calculation, totals/coupon/tip/wallet, Place locking/idempotency/reCAPTCHA, cart/order/payment/job/socket/plugin effects, guest/session/provider identity, grouped placement, accessibility, or App/components/API authority pins.
Related guides: Review payment-method boundaries · Review fees, taxes, and tips · Review wallets and loyalty · Review coupons · Understand checkout failures and retries · Review your cart before checkout