Checkout Architecture
Ecommerce checkout architecture
Map basket, checkout, payment and order ownership, then assess customisation, currency and support responsibilities.
Checkout architecture defines how a basket becomes an order, how payment is confirmed, and which system records the result. For an Australian store, map one intended purchase through those steps before choosing a checkout design. The customer screen alone cannot show whether payment and order records will agree.
Map the transaction
Start with the basket and follow it through confirmation, fulfilment and refund. Record which system owns each decision and how another receives the result.
| Point in the journey | Decision to document |
|---|---|
| Basket | Which system supplies items, discounts and the amount due? |
| Address and delivery | Where are eligibility and delivery charges calculated? |
| Payment | Which service presents methods and confirms the outcome? |
| Order | When is it created, and how is a failed or delayed payment recorded? |
| Service | Where can staff find the order, payment and refund? |
If systems use different identifiers, record how staff match a payment to its order. Include the case where a shopper closes the browser before returning to the store.
Assign session ownership
Ask who manages the shopper's session, not just which page renders checkout. BigCommerce says its storefront APIs maintain shopper sessions using cookies and its standard mechanisms. When checkout runs outside that storefront, the server-side application is responsible for session management.
Record this responsibility beside the system that creates the cart and moves it into checkout. If an external application owns the session, name the team responsible for keeping it usable across the handoff and for investigating cart-checkout mismatches.
Make channel ownership visible
For an external BigCommerce storefront, Embedded Checkout uses a channel and site associated with the external website. Later requests, including cart creation, use the channel ID, linking the storefront to commerce records.
BigCommerce says API-created channels appear in the control panel's channel manager. Staff can sort customers by channel and create custom order views to group or filter orders. Include these views in the handoff plan so service staff know where to look for a particular storefront's orders.
Choose the checkout boundary
A platform checkout follows the commerce platform's supported order flow, although it may use a separate payment provider. In WooCommerce, the Checkout block shows a payment method only when it is available and compatible with the block. Delivery and pickup controls also depend on store settings.
A separate storefront can still use its commerce platform's checkout. BigCommerce documents a redirect to its hosted checkout and an embedded version for headless storefronts. Its documentation lists compatible payment gateways for Embedded Checkout. Check the proposed gateway before treating embedding as an available option.
A separate payment page creates another handoff. Stripe Checkout offers hosted and embedded payment interfaces, but a Stripe payment page does not by itself define how a commerce platform creates or updates an order. The proposed integration must show how payment completion passes back to the commerce platform and is associated with an order.
Check what the business must change
List required branding, fields, delivery rules, payment display and order-summary changes. Name the plan, extension and person responsible for each. Shopify supports app-based checkout customisation; apps that change its information, shipping and payment pages require Shopify Plus.
BigCommerce documents styling and developer routes through Open Checkout and its Checkout SDK; the SDK cannot introduce new payment or shipping methods. WooCommerce extensions can register Checkout block fields in contact, address or order-information locations, with different storage behaviour.
Confirm platform configuration ownership
In WooCommerce, adding the Checkout block to a page is not the final configuration step: the chosen page must also be designated as the checkout page in the store's advanced settings. Assign someone to verify that setting when checkout pages change or a new storefront is connected.
The block's inner content can respond to other WooCommerce settings rather than being controlled entirely in the page editor.
Record adjacent payment handoffs
Currency display and payment handling can cross system boundaries. Record which system owns each relevant handoff. Detailed Australian currency and payment choices are covered separately.
Make a decision record
For each candidate, write down the supported route, required configuration, unresolved dependencies and owner of payment exceptions. Request a demonstration of the intended Australian order, a declined or delayed payment, and a refund. If overseas sales matter, include a customer whose displayed currency differs from AUD. Inspect both the customer view and the resulting records.
In this guide
- Native checkout versus an external checkout serviceCompare platform checkout with a separate service by order ownership, payment handoff and failure recovery.
- Evaluating checkout customisation limitsTurn checkout changes into requirements and check plan, field, gateway and express-payment limits before committing.
- Checking payment and currency coverage for Australian merchantsCheck payment eligibility for an Australian store and distinguish displayed, charged, order and payout currencies.
