Commerce & Orders
Order Summary
The final checkout review + payment step in the flow: Menu Item Detail → Cart → Pickup Scheduler → Order Summary → Payment or Confirmation. It shows fulfillment data, itemized totals, payment readiness, and then either submits directly to backend orders or hands off into Stripe flows.
Last customer review before payment, confirmation, and order creation.
Receives pending order state and actions from AppPlayer runtime.
Uses Stripe when available, with backend order submission at the end.
Four things worth knowing
Renders fulfillment and store context
Shows restaurant information, fulfillment mode, selected pickup details, and order context coming from earlier checkout screens.
Builds full itemized totals view
Lists line items, quantities, selected options, and totals (subtotal, service fee, grand total) using existing currency and parsing helpers.
Tracks Stripe readiness and payment path
Checks Stripe configuration, uses Checkout Session when possible, and falls back to PaymentIntent flow when needed.
Submits backend order payload
Creates the final payload and calls onSubmitOrder, then transitions into payment or confirmation state based on runtime context.
Find it, drop it, wire checkout navigation
Where to find itAdd it to your checkout screen
- Component picker → Commerce & Orders → Order Summary.
- Drop it onto the final checkout review screen after Cart or Pickup Scheduler.
- Set
paymentScreenIdfor Stripe flow andordersScreenId/menuScreenIdfor navigation return paths.
Before you publishThree things to check
- Keep payload keys stable (
tracking,trackingContext,items, totals fields) for backend and orders list mapping. - If fulfillment/pickup fields change, update Pickup Scheduler and Cart to keep the flow in sync.
- Verify backend recalculates totals server-side before creating charge or final order record.
Most edited runtime and builder props
| Prop | Type | Default | Description |
|---|---|---|---|
ordersScreenId, menuScreenId, paymentScreenId | string | none | Navigation targets for returning to orders/menu and moving to payment flow. |
cartItems, navigationParams | runtime | Injected by AppPlayer | Pending order data from Cart and Pickup Scheduler. |
onSubmitOrder, onGoBack, onScreenNavigate | function | Injected by AppPlayer | Submission and navigation callbacks used by checkout actions. |
headerText, emptyText, checkoutButtonText, restaurantName | string | Registry defaults | Main copy for heading, empty state, CTA, and store naming in checkout UI. |
serviceFeePct, appId, secureApiCall, usesBackendOrders, _prefetchedStripeConfig, _prefetchedPaymentMethods | number / runtime | Runtime dependent | Service fee math and integration controls for Stripe readiness and backend order flow. |
Make it yours
Style tokens are editable through registry props, with selected values intentionally locked in runtime. Keep registry defaults and component locks aligned.
| Prop | Default | What it controls |
|---|---|---|
backgroundColor, cardBackgroundColor | Theme defaults | Outer and inner checkout card backgrounds. |
titleColor, metaColor, priceColor | Registry defaults | Primary text, supporting metadata, and monetary value colours. |
accentColor, accentTextColor | Registry defaults | CTA and emphasis colours for payment actions. |
borderColor, borderRadius | Registry defaults | Card edge styling and rounded corner radius. |
fontFamily, titleFontSize | Registry defaults | Typography family and heading sizing. |
metaFontSize | Locked | Intentionally removed from editable prop list and controlled via LOCKED_ORDER_SUMMARY_PROPS. |
Common mistakes to avoid
Keep payload keys stable
Do not casually rename tracking, trackingContext, items, or totals fields. Backend mapping and orders history depend on these names.
Sync cart and pickup changes
If fulfillment or pickup field shapes change here, update the same fields in Cart and Pickup Scheduler in the same release.
Use existing helpers for money
Keep formatting with formatCurrencyAmount(…) and continue using established numeric parsing helpers to avoid rounding drift.
Never expose payment secrets
Keep tokens and secret keys backend-side. UI should only consume non-sensitive readiness and client-safe payment configuration.