Overview

Build the customer cart, inspect server-calculated totals and find the same cart from the operator side.

Before you start

Have a published customer product page with a known SKU/variant and a configured delivery method. Keep one shopper browser session for the exercise; switching to an unrelated private window can create another cart. The historical examples below use Cedar Botanical Print: A4 $25 or A3 $35, with $5 delivery. The cart is a pre-order record; its total is not a payment receipt.

01. Build and change a cart

Why this matters

A cart preserves the buyer’s product and option choices before the order exists.

Follow these steps

Open the actual customer product page, select a valid variant and quantity and choose Add to Cart. Open the cart, inspect product/variant/price, change quantity and remove an item. Add it again and reload the page to check the retained state.

Check the result

Do not use the admin product editor as proof of a buyer cart. Required options and unavailable products need their own rejected-input checks.

Follow one variant into the cart

1. Open your site's actual View link, open the product and select the intended size before Add to Cart.
2. Open the cart control. Compare the selected option, quantity and unit price with the product page.
3. Use the line's quantity controls, wait for recalculation and inspect the product subtotal separately from shipping. Remove the item with its remove control, add it again and reload the same browser page to check persistence.

Historical A3 cart result totals $40. It verifies the recorded selection/calculation, not current stock allocation or payment.

02. Delivery, codes and totals

Why this matters

Delivery and discount eligibility can change with the destination, item and buyer.

Follow these steps

Apply an eligible code and inspect the changed lines, then remove it. Enter contact and shipping details through Checkout → Continue and inspect the displayed options and selected delivery total. Compare an eligible and ineligible destination. Use a configured gift-card tender only after payment configuration, then inspect balance and total.

Check the result

An address typed into checkout does not prove account ownership. A subtotal is not the final delivered total.

03. Find the staff cart

Why this matters

A cart record is distinct from a completed order and from a recovery campaign.

Follow these steps

Open Storefront → Cart, find the corresponding cart by its actual customer/session context and open details. Compare items, totals, contact/address and lifecycle with the shopper view. Complete a controlled checkout and inspect the related order rather than treating the cart as the purchase.

Check the result

Anonymous and signed-in sessions may have different identities. Use independent sessions deliberately and do not assume a typed email restores another person’s basket.

Read the staff record without confusing guest identity

1. Open Storefront → Cart and use Search carts… to locate the recorded customer/session context. A row labelled Guest is not proof that a buyer has signed in.
2. Open the cart identifier. Compare SKU, chosen options, quantity, subtotal, shipping and last-updated time with the shopper session.

Historical cart977ae174 holds A4 and totals$30. It is deliberately not presented as the same A3 cart pictured earlier; match your own cart identity before reconciling.

3. Do not describe the staff cart as a paid order. After a successful controlled checkout, use the resulting order number and its Payments records for collection evidence.
4. If no corresponding record is clear, preserve the shopper's SKU, time and session context before searching further. Typing a customer's email into checkout does not authorize access to that person's other carts.

04. Recover a failed checkout

Why this matters

Resolve the failing product, offer, shipping or payment condition before repeating checkout.

Follow these steps

Read the exact rejection, inspect the product’s current availability, code dates/usage and shipping eligibility, then recalculate the cart. For payment errors inspect existing payment/order results before retrying. If a cart is labelled abandoned, inspect the available recovery action and actual recipient delivery separately.

Check the result

An abandoned badge does not prove outreach was sent.

Detailed instructions

The following retained material documents earlier local work. Its pending checks remain pending; historical successful outcomes are not claims of a fresh execution. Use the source-authored instructions above to prepare the new recording, and preserve these references for comparison.

E14: Read the customer’s price

Worked example

Before taking payment, check the size and the delivered total separately. Choose A3 in the customer product page: the ten-dollar option raises the print from twenty-five to thirty-five. Add it and open the cart. Delivery is still five, so this size totals forty. Our buyer will choose A4 for the purchase: twenty-five plus five, or thirty.

Included controls: public catalogue, product detail, A4/A3, Add to Cart, open cart, option value, reload, subtotal/shipping/total.

Check the result: A4 25+5=30; A3 35+5=40; current app repaired totals, no stale hidden-DOM claim.

Retained evidence: capture/SF20-shopper-shipping-corrected.webm.

Implementation reference: app.tsx.

Next-batch matching evidence: SF32-designed-store-size-and-checkout.webm, SF47-buyer-gift-purchase.webm.

E15: Capture the buyer’s delivery details

Worked example

Choose Checkout. Complete contact details and Continue, then enter the shipping address and Continue. Our rehearsal uses fictional contact details. Check that the summary still shows the chosen A3 print at thirty-five dollars and five dollars shipping, total forty. The contact address tells us where to communicate about this order. Typing an email does not establish ownership of a customer's stored balance; we’ll handle account-based payment separately.

Included controls: Checkout, contact, shipping address, Continue, summary, identity boundary.

Check the result: Capture exact current contact/address details and summary matching basket; no invented authenticated customer.

Retained evidence: capture/SF16-coupon-shipping-complete.webm, capture/SF20-shopper-shipping-corrected.webm.

Implementation reference: Checkout.tsx.

E18: Complete the buyer’s purchase

Worked example

Choose A4, quantity one, and Add to cart. Open the cart: twenty-five for the print plus five delivery makes thirty. Choose Checkout. Enter the buyer's email and Continue, then their full name, street, city, state and ZIP. Keep Use same address for billing selected and continue to payment. Open Gift card and apply the issued code. It covers thirty and leaves twenty on the card; applying the quote hasn't spent it yet. Choose Place order — paid with gift card. The receipt now shows Paid, thirty dollars and the card ending J P S 3. Keep the order number to find this purchase in Studio Manager.

Included controls: buyer payment, success/order handoff, order number, cart clearing, product SKU/options, contact/address, total, payment reference, paid balance.

Limitations and checks: The reserve email/name/address are course fixtures, not signup requirements. External processor settlement/mixed or insufficient tender are separate gaps.

Check the result: Same buyer/catalogue order/transaction/total on both sides and actual state; record stock settlement.

Recovery / evidence caution: If payment exists but order does not, retain reference and inspect order/transaction before retry; capture smallest actual recovery without second charge.

Implementation reference: CheckoutSuccess.tsx, storefront.checkout.service.ts.

Next-batch matching evidence: SF47-buyer-gift-purchase.webm.

A18: Inspect carts from the owner’s side

Worked example

The shopper’s cart holds choices; the owner’s Carts screen lets us inspect their saved context. Open Carts from Storefront and select the recorded guest cart ending nine seven seven a e one seven four. Its detail shows one A4 botanical print at twenty-five dollars, five dollars shipping and thirty total, with Created and Last updated timestamps. Compare those item and delivery lines with the shopper’s cart. The guest label and basket total do not prove the customer signed in or paid. A cart is not an order; check a matching order and Payments before treating these thirty dollars as collected. This demonstration inspects a saved cart. It does not restore a signed-in basket, change quantities from the owner’s screen or establish that every older guest basket is an abandoned sale.

Included controls: staff Carts list, detail, customer/items/totals, timestamps, active/abandoned, quantity/remove, anonymous/signed-in, restored cart, mixed rental/product.

Verified scope / remaining work: Actual guest cart detail/timestamps/items/totals inspection. Owner quantity/remove, sign-in restore and mixed rental/product cart pending.

Check the result: Correct shopper cart matched; no false order or identity claim.

Implementation reference: app.tsx, Checkout.tsx.

Actual evidence: SF40-cart-analytics.webm, SF40-01-cart-detail.png.

A02: Diagnose why an offer does not apply

Worked example

A success toast is not the calculation check; inspect the deduction and total. A nonexistent code gives Discount code not found. Correct the entered code before changing the offer. When a training promotion is finished, return to its row actions and Deactivate. Reload checkout with PRINT10: Discount is inactive appears, the deduction is removed and the total returns to forty dollars. An inactive offer needs a deliberate status decision, not repeated clicks on Apply Coupon.

Included controls: unknown coupon, inactive coupon, Deactivate, eligibility inspection, cleanup, negative result.

Check the result: Unknown-code/inactive errors; final couponInactive and total40.

Retained evidence: capture/SF19-coupon-deactivation-check.webm.

Implementation reference: discount.service.ts.

T07: Pay from an existing customer balance

Learner draft — pending demonstration:

Account-balance payment belongs to an identified customer account, not to whoever types that customer's email. Start with the correct signed-in account and inspect the eligible balance. Compare a purchase the balance covers with one it cannot cover, then check the debit and order transaction. This is an alternative tender with an identity prerequisite.

Included controls: AccountBalance identity, eligible balance, debit, insufficient balance, order tender, customer account association.

Limitations and checks: Inspect actual authenticated account/credit setup entry; controlled customer balance fixture, full/insufficient and any split supported path; capture debit/order/refund behavior.

Check the result: Correct account balance debited and linked order; unrelated typed email cannot impersonate.

Implementation reference: PaymentGateways.tsx, storefront.payment.service.ts.

Limitations and checks

Current UI entry and editor: . Corresponding SDK storefront schemas and the retained AppEngine references define fields and consumer boundaries. Provider calls, external delivery, payments and financial mutations were not performed for this writing task.

Next steps

You can now follow the module from its configuration to the record that proves the result. Use the relevant chapter to revisit an alternative or troubleshoot the exact failed handoff.

Overview

Follow one order through payment and fulfilment, keeping the buyer’s purchase, money records and stock movements connected.

BusinessMade entry and scope

Open Storefront → Orders at /storefront/orders in BusinessMade. This route mounts the shared Orders module; the surrounding menus are BusinessMade’s. Use Operations → Contacts for customer details, Operations → Customers & Benefits for group eligibility, Admin → Business locations for branches, and Operations → POS / Order entry for counter sales. Keep the organization and record identity consistent across those screens.

The location selector governs the venue-specific POS, but does not establish that every shared Storefront module filters its data by that selection. Inspect the record’s own location and currency. Payments are under Storefront → Payments, while delivery rules and shipments are under Storefront → Shipping; creating this module’s record is not payment or shipping-provider configuration.

Bring a known saved order

Use a controlled paid POS tab or converted invoice and retain its saved reference. Do not create another order just to have something in this screen. The historical first-sale example below is a one-item 6.00 cash sale; a separate invoice-conversion example is identified later. Customer/address corrections, payment, shipment and stock handling are separate operations even when presented on the same order.

Have access to Storefront → Orders. If opening the route shows a dashboard, choose Order Management to work with individual records. Read the relevant row before taking a status action; dashboard totals combine more than one record.

01. Find the same order

Why this matters

A buyer purchase, staff order and converted invoice can originate differently while arriving in Order Management.

Follow these steps

Open Storefront → Orders → Order Management. Find the intended order by its saved number/customer, open it and compare its line items with the buyer confirmation or source invoice. Use Overview, Items, Pricing, Shipping and Payments to inspect the same record.

Check the result

A manual free-text line is not automatically a stock-backed catalogue item. Preserve SKU and variant identity when stock matters.

Navigate from totals to the actual order

Open Storefront → Orders. The Dashboard shows totals and a pipeline summary. In the first-sale capture it shows one order and 6.00 revenue. That is useful context, but it does not identify a buyer, payment reference or shipment.

Historical local first-sale dashboard: one Paid/Confirmed order, no demonstrated shipping or delivery.

Select Order Management. Use Search orders with the saved order number/reference or known customer. Compare Items, Total, Gateway and Status. The later historical list below has two one-item 6.00 manual-paid orders, so amount alone cannot tell them apart. Retain the POS reference to distinguish the first walk-up sale from Sam’s pickup.

Historical list: two references and two rows, not a duplicate merely because totals match. The captured Customer column contains POS reference strings; it is not evidence that a named contact was assigned.

Open the intended order, then follow its Overview, Items, Pricing, Shipping and Payments tabs as described below. The retained images cover dashboard/list readback, not a new demonstration of every order-detail action. If the reference is not visible, clear list filters and refresh before creating anything.

02. Customer details and operational state

Why this matters

Correct contact and address information supports fulfilment; payment state must still be inspected independently.

Follow these steps

In Overview inspect Customer, Addresses and Timeline. Use Edit Contact or Edit Billing/Shipping Address to correct the intended fields, save and reopen. Review the available status operations from the current state: confirm/process, hold, ship/deliver/complete or cancel as offered. Read the dialog before confirming and supply the reason where requested.

Check the result

Marking an order operationally complete does not establish provider payment. The timeline records transitions, not proof that a carrier delivered a parcel.

03. Take payment and reconcile

Why this matters

A payment record needs a result and reference, not just a new order badge.

Follow these steps

Open Payments and inspect existing payments first. Choose Take Payment, select the configured method and amount, complete the controlled payment, then refresh. Compare total paid, remaining balance, currency and payment reference. For partial payment repeat only for the remaining intended amount and inspect both payment records.

Check the result

If the operation times out, refresh before retrying. Never mark an order Paid manually as a substitute for provider confirmation.

04. Fulfil, communicate and recover

Why this matters

Shipping, customer messages, private notes and workflow history have different audiences and effects.

Follow these steps

Open Shipping and create or inspect the linked shipment. Verify tracking on the shipment and customer-facing order where available. Use Messages for the intended communication, Notes for internal context, History for audit and Workflow for the configured process. For a return/refund open the linked records and compare paid/refunded amounts and inventory decisions.

Check the result

Refund money and restock goods independently. A failed handoff stays unresolved until the destination record is inspected; a note saying refunded cannot replace the refund record.

BusinessMade operational handoff — Trace a POS tab into its order

Why this matters

Orders connects to the saved customer, product or transaction. Follow that identity through the BusinessMade operation rather than creating a second record to illustrate a result.

Follow these steps

Choose one location in the top bar and open Operations → POS / Order entry. Add the prepared product, complete required choices and open Settle. Choose the intended tender; for cash enter the actual tendered amount, for card follow the configured Stripe form, and for gift card enter its code/PIN. Charge once and inspect paid versus remaining balance. Note the tab/order identity and open Storefront → Orders to inspect the same record’s Items, Pricing and Payments. Reopen the operational tab through Tabs when further service actions are needed. Use Customer copy only after the payment result exists; a print job and physical receipt are separate outcomes.

Recovery and implementation boundary

Storefront Orders is the order record; Operations Tabs/POS is the operational checkout. Do not create a second order to represent the paid tab. Location selection is not proof that every shared Storefront list applies a location filter.

Enter through the invoice’s saved order link

For invoice-origin work, reopen the source invoice. After its one-time More → Create Order operation, use the saved Order # link beside the invoice number. The preserved example links invoice INV-V2NPJ0 to order HRVR94A4P.

Historical invoice-origin route into Orders, separate from the six-dollar POS examples above. It proves a saved relationship, not delivery or stock deduction.

Compare the converted order’s customer, line quantity, currency and payment snapshot with the invoice. Return through the same saved identities after any correction. Conversion does not establish continuous synchronization: if a later invoice payment/refund changes its balance, inspect both records rather than assuming the order changed automatically. A catalogue item should retain its identifying SKU when stock matters; a manual service line may not have one.

Those gaps are not covered by repeatedly reusing this dashboard or invoice link.

Limitations and checks

• Shared module procedure and source evidence

Substantive pending work: Storefront Orders is the order record; Operations Tabs/POS is the operational checkout. Do not create a second order to represent the paid tab. Location selection is not proof that every shared Storefront list applies a location filter. Runtime evidence for the taught handoff remains separate from authored coverage. Do not mark the course production-ready until the intended branch’s saved result, failure recovery and customer/provider outcome have been checked.

Next steps

You can return directly to the chapter for the change you need. Keep the saved record and its operational result together: the same customer, product, location and transaction should remain identifiable through each handoff.