Multi-business checkout availability
Customer App contains integrated multi-business checkout behavior, but the current sources do not establish one supported, safe customer journey for creating a cart group and completing every cart, payment, provider, wallet, and order effect. This page is a blocked capability reference, not a checkout procedure.
:::warning Multi-business completion is not established
Do not infer support from a registered screen, grouped summary, enabled Place control, provider return, or navigation to grouped order details. Group membership and every financial and order result require an authoritative, recoverable receipt.
:::
Integrated MultiCheckout and standalone MultiCart differ
| Surface | Current source boundary | Public disposition |
|---|---|---|
| Integrated MultiCheckout | Current cart callers can open MultiCheckout for multiple carts or an existing group. One branch nests group creation inside MultiCheckout before showing the regular checkout surface. | Reachability exists, but mutation safety and completion are blocked. |
| Standalone MultiCart | The route is registered, but no ordinary production caller is established by the pinned static source. | Reachability remains unknown; registration is not a customer journey. |
| Grouped order details | A later read surface can present returned grouped-order context. | It does not prove checkout, placement, payment, or group completion. |
The nested group-creation branch and the standalone route can reuse underlying behavior, but they are not equivalent navigation evidence. Group creation can begin as the nested branch mounts, so opening it is not a passive reachability test.
Group creation and membership
| State | Safe interpretation |
|---|---|
| No eligible carts | No valid group request should be inferred or created. |
| One eligible cart | A single-cart checkout boundary applies; creating a group is not established as valid. |
| Multiple ungrouped carts | Group creation can be requested, but membership, caller ownership, and resulting group identity remain unsettled. |
| Existing group | Returned membership can be displayed after reauthorization; it is not proof that every current cart still belongs. |
| Mixed, stale, or invalid carts | Membership, business, fulfillment, address, coupon, payment, and totals can diverge. |
| Group response or navigation | One phase advanced; no cart, payment, provider, or order completion follows automatically. |
A supported contract needs one exact current account/project/session, an owned set of eligible carts, a versioned membership snapshot, and idempotent group creation. Repeated opening or submission must not create duplicate groups.
Multi-cart summary and freshness
Integrated MultiCheckout can present multiple cart/business sections and a combined summary. The visible carts can come from locally retained group state while coupon, fulfillment, address, time, or other changes update a different context.
| Visible layer | What it does not prove |
|---|---|
| Cart/business sections | Current group membership, cart eligibility, or one shared revision |
| Product quantities/options | Current catalog or successful cross-cart update |
| Combined subtotal or total | Canonical amount, currency, discounts, fees, tips, wallet use, or provider settlement |
| Loading or disabled Place | Which cart, field, provider, or operation is pending |
| Refreshed summary | That every cart and financial branch refreshed together |
When one layer changes without a new authoritative group snapshot, keep the entire multi-business outcome unknown.
Coupon, tip, wallet, payment, and provider branches
| Branch | Required separation |
|---|---|
| Coupon | Group-wide and per-cart presentation, requiredness, replacement, analytics, totals, and applied/removal identity must settle explicitly. |
| Tip, fees, taxes, discounts, and totals | Need one locked minor-unit amount, currency, recipient, and revision across carts. |
| Wallet or loyalty | Reservation, debit, reversal, and remaining balance are separate from provider and order state. |
| Payment method | Availability, selection, saved instrument, challenge, return, and Ordering confirmation are separate stages. |
| External provider | Provider acceptance or return is input to Ordering reconciliation, never proof of group placement. |
| Cash or provider-free branch | Absence of an external provider does not prove atomic group order creation. |
The current source does not support a public claim that coupons are enforced consistently across the group, that a displayed total is final, or that one payment result settles every cart.
Address, fulfillment, schedule, and map boundaries
Each cart can depend on current address, order type, delivery details, timing, business availability, and configured validation fields. MultiCheckout can retain earlier group/cart state after an address, type, coupon, or time change.
Typed addresses, precise coordinates, maps, geocoding, permission, and provider state are private external boundaries. A visible address, map, or returned business state does not certify serviceability, approved provider disclosure, or refresh of every cart.
Place, confirmation, and partial outcomes
| Observable outcome | Safe interpretation |
|---|---|
| Place becomes enabled | Local validation considers the current visible state eligible; server/group/payment authority remains separate. |
| Place is requested | One multi-stage operation may have started; duplicate submission must remain disabled. |
| Some carts return success and another fails | Partial group settlement; do not call the group placed or completed. |
| Provider reports success | Ordering payment and per-cart order creation still require reconciliation. |
| Confirmation is requested | A later operation phase started; it is not finality. |
| Grouped order details opens | Navigation/read state changed; exact created orders and financial settlement remain unproved. |
| Response is lost or app restarts | Keep every cart, payment, provider, wallet, and order result unknown. |
| Retry appears possible | Safe idempotent retry is not established without the original operation receipt. |
No success state is complete unless it identifies every input cart and returns one authoritative result for group, payments, wallet/provider effects, and all orders—or an exact recoverable partial result.
Guest and account ownership
Guest and signed-in carts use different identity and merge boundaries. A guest capability, visible cart, or later Login/Signup result does not prove that cart membership and payment/order ownership transferred to the current account.
Account, project, session, guest capability, group, cart, business, payment, provider, and operation generations must match before any result is accepted. Late results must not enter a new account or project context.
Loading, errors, and unknown states
- A transition skeleton does not prove standalone MultiCart reachability or successful group creation.
- A missing error, empty, or retry state does not turn a failed group request into success.
- A stale coupon, cart total, order type, address, or schedule keeps placement authority unknown.
- A generic provider/payment error does not identify which cart or financial stage settled.
- A returned Home, Cart, Checkout, or grouped-order screen is navigation, not a placement receipt.
- Do not repeat group creation, Place, confirmation, payment, wallet, coupon, or provider actions to discover an unknown result.
Accessibility and privacy
Group/cart membership, business sections, product state, coupon, address, fulfillment, schedule, totals, tip, wallet, payment, provider, loading, error, partial, unknown, Place, confirmation, and safe-exit states need clear semantic headings, names, roles, values, consequences, focus order, and announcements. Large text, keyboard, screen-reader, Back, modal, and provider-return behavior must keep each cart and the group consequence distinguishable.
Do not include cart/group references, addresses, coordinates, amounts, payment instruments, provider values, account details, or screenshots in documentation, diagnostics, or fixtures. These are verification requirements, not a current accessibility, privacy, financial, or provider certification.
Product disposition and recertification
Retain this article as blocked until product ownership explicitly accepts a supported entry and the current pinned runtime proves safe zero/one/many-cart behavior, group membership, full/partial recovery, and effect isolation. Do not promote the standalone route, publish a completion procedure, or claim deployed support from source registration alone.
Repeat isolated review after changes to Cart-to-MultiCheckout callers, standalone MultiCart reachability, group creation/membership, cart-group reads, coupon/tip/totals, wallet/payment/provider, address/map, fulfillment/schedule, guest/account ownership, Place/confirm/recovery, grouped-order navigation, accessibility, or App/components/API authority pins.
Related guides: Review your cart before checkout · Review coupons · Understand fees, taxes, and tips · Review payment-method boundaries · Review wallets and loyalty · Understand checkout failures and retries