Ecommerce system design should make the transitions from shopping session to order, payment and fulfilment explicit. Start with a state-and-responsibility map, then test normal and interrupted journeys in a separate environment. The design should let each responsible person explain what has happened, which record proves it and what action is permitted next.
A cart describes an intended purchase, while an order, payment result and fulfilment record can describe different stages of that purchase. Write the meaning of each before connecting interfaces. This gives the application team and operations team a common reference when a shopper stops, returns or encounters an uncertain result.
The original boundary exercise below uses a fictional physical product. Narrow examples come from BigCommerce checkout architecture and WooCommerce order-status documentation, retrieved on 24 October 2026. They are separate product examples. Broader work belongs with online stores and web development.
Who owns the shopping session?
BigCommerce distinguishes checkout hosted on its storefront from checkout rendered externally. In the storefront route, BigCommerce manages shopper sessions through its standard mechanisms. The checkout overview makes session ownership a concrete architecture question to settle before designing the page flow.
For external checkout using Management APIs, the consuming system handles session management. Record which component owns the session in the proposed design and how the selected cart is identified across requests. A checkout interface can look similar while having a different responsibility boundary behind it.
BigCommerce’s Checkout JS SDK wraps the Storefront Checkout API. BigCommerce says that SDK cannot introduce new payment or shipping methods. These documented qualifications illustrate why a visual redesign and a new transaction capability need separate scope decisions. Identify which requirement concerns presentation and which concerns the underlying commerce behaviour.
For the fictional product, draw the route from browsing to the chosen item and checkout. Label the component that owns each step and the identifiers that cross the boundaries. Keep unresolved session or transaction questions on the map so they can be assessed before implementation expands.
When has the transaction reached an order state?
WooCommerce describes Pending payment as an order received without payment made. WooCommerce describes Processing as paid, with stock reduced and fulfilment pending. Its order-status guide provides product-specific meanings to compare with the states required by your own design.
WooCommerce describes Completed as fulfilled and complete. WooCommerce’s On hold status awaits payment confirmation. Keep these distinct meanings in the operating brief. A colleague preparing goods needs evidence that the order is eligible for their action, while a colleague answering a payment question needs the relevant payment state and reference.
WooCommerce notes that a manual refund can reach Refunded without money having been returned. Include the evidence of the actual business action in the design requirement. A status field can be useful to operations, but the team should know what it establishes in the configured process and where further confirmation is required.
| Proposed boundary | Question to settle | Evidence needed by the next owner |
|---|---|---|
| Session to cart | Which selection belongs to this shopper? | Session and cart references |
| Cart to submitted order | What has the shopper committed? | Submitted record and selected items |
| Order to payment | What payment state is established? | Relevant status and payment reference |
| Payment to fulfilment | What permits preparation or dispatch? | Agreed eligibility and operational record |
| Fulfilment to completion | What establishes that work is complete? | Actual fulfilment evidence |
| Exception to recovery | Who decides the next safe action? | Correlated records and unresolved state |
This is an original architecture worksheet. Define its expected states for the chosen platform rather than combining vendor labels into an assumed universal state machine.
How should interrupted journeys be represented?
Choose an interruption at each relevant boundary. The shopper might leave before submission, return after a payment response is delayed or ask about an order while fulfilment is still pending. Write what the user sees and what the responsible operator can establish from the records.
WooCommerce uses Draft for a temporary block-checkout state before submission. Record the particular checkout implementation when testing that example. The broader design question is how the application distinguishes an incomplete shopping interaction from an operational order requiring action.
An uncertain response deserves a visible investigation state in the proposed process. Ask which system can establish whether the intended record or payment exists and who performs that check. Keep the resulting decision separate from automatically repeating a transaction merely because the user-facing request was interrupted.
Use customer-facing messages that reflect the evidence available. The shopper should be able to understand the next step without being shown internal identifiers or implementation detail that does not help them act. Operations can retain the technical references privately for correlation and investigation.
For each proposed transition, identify the triggering event and the role or component allowed to make it. Include the evidence that should remain afterwards. This helps the reviewer distinguish an automatic transition from a deliberate operator decision and makes unexplained status changes easier to investigate.
Original cart-to-fulfilment boundary exercise
Prepare a fictional product and a designated test customer in a separate staging environment. Define the intended item selection, submitted order, payment-test route and fulfilment outcome. Write the expected record and responsible role at each boundary before the journey is exercised.
Begin with the normal path. Ask the reviewer to identify the selected item in the cart, the submitted order and the subsequent operational state. Retain the references connecting those records. Have the fulfilment owner explain which evidence permits them to proceed and what they record when their work is complete.
Next, stop the journey before submission and inspect the records that actually exist. Repeat with a controlled interruption around the agreed test payment route. Compare the shopper’s view with the operator’s evidence and record any ambiguity. Keep the exercise confined to the documented safe testing arrangement for the integration.
Then introduce a fulfilment exception in the fictional case, such as a sample item requiring investigation before dispatch. Ask how the responsible person identifies the order, records the issue and communicates the next action. The worksheet should distinguish a business exception from a technical delivery failure so the right owner receives it.
Finish by asking a second colleague to reconstruct the journey from the retained records. They should be able to explain the current state, relevant evidence and next responsibility without replaying the demonstration from memory. Record any missing relationship as a specific architecture requirement.
Use the map to agree system boundaries before expanding the design. For payment-specific decisions, see online payments. To discuss the intended cart, order and fulfilment relationships, get started with the boundary worksheet and its unresolved cases.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.