Checkout Architecture
Part of Ecommerce checkout architecture
Native checkout versus an external checkout service
Compare platform checkout with a separate service by order ownership, payment handoff and failure recovery.
Choose a platform checkout when its supported flow can take the required order and your team can operate it. Consider a separate checkout or payment service when a specific requirement justifies the extra handoff and the team can reconcile each payment with its commerce order. Compare who owns the order, not just the screen a shopper sees.
Define the boundary
A platform checkout creates or advances an order in the commerce platform's supported flow. It may still use a separate payment gateway. An external service can present a hosted page, embedded interface or separately built flow, but those interfaces do not all transfer order ownership in the same way.
| Question | Platform checkout | Separate service or checkout |
|---|---|---|
| Total and delivery rules | Check the platform's supported rules and extensions | Specify which system calculates and validates each rule |
| Shopper handoff | Inspect the platform flow and gateway | Inspect the redirect, embedded view or custom page |
| Payment result | Check platform order and payment statuses | Specify how the result reaches the right commerce order |
| Recovery | Identify who handles gateway exceptions | Identify who handles unmatched or repeated notifications |
The proposal should state when an order exists, what happens after a failed payment and how staff find its matching transaction.
Platform Checkout vs External Checkout Service: Key Differences
- Total and delivery rules
- Check the platform's supported rules and extensions
- Total and delivery rules
- Specify which system calculates and validates each rule
- Shopper handoff
- Inspect the platform flow and gateway
- Shopper handoff
- Inspect the redirect, embedded view or custom page
- Payment result
- Check platform order and payment statuses
- Payment result
- Specify how the result reaches the right commerce order
- Recovery
- Identify who handles gateway exceptions
- Recovery
- Identify who handles unmatched or repeated notifications
Compare the actual routes
WooCommerce Checkout block is a platform route for a store that can maintain its WordPress hosting and extensions. It displays payment methods that are available and compatible with the block. Enabling a gateway in the admin does not establish that it will appear in this checkout. Check the required payment and delivery combination in the proposed setup.
BigCommerce hosted and embedded checkout keep checkout within BigCommerce's order flow even when the storefront is separate. A headless site can redirect shoppers to BigCommerce's hosted checkout or embed its Optimized One-Page Checkout.
For the embedded route, check BigCommerce's current documentation for compatible payment gateways and any requirements for the storefront setup. If embedding does not meet the requirements, evaluate the hosted route and its gateway separately; do not assume it will satisfy every requirement.
Stripe Checkout offers hosted and embedded payment interfaces. Using it as a separate payment page requires an integration that connects the payment outcome to the commerce order. Confirm how the chosen commerce platform receives payment results and how repeated or delayed events are handled.
Account eligibility, payment methods and currency still need configuration-specific checks.
Platform Checkout Support Summary (Australia)
- WooCommerce Checkout Block
- Supported on WordPress hosting; requires compatible gateways
- BigCommerce Hosted Checkout
- Maintains order ownership within BigCommerce; ideal for headless stores
- BigCommerce Embedded Checkout
- Requires storefront compatibility; may need additional setup
- Stripe Checkout
- Hosted or embedded; requires integration to link outcomes to orders
Decide with a failure case
For each proposed route, trace a basket through payment started, payment confirmed and fulfilment released. Ask what staff see if the shopper never returns from a payment page, payment is declined, or confirmation arrives late. Identify the authoritative total, the event that permits fulfilment and the owner of an unmatched payment.
Choose the route whose required order and recovery path the business can demonstrate and maintain.
Trace a Basket Through Payment: Failure Case Analysis
- Payment startedStaff must see the initiated transaction in the commerce system
- Payment confirmedVerify that the order status updates correctly and fulfilment is unlocked
- Fulfilment releasedEnsure the system permits dispatch only after valid payment confirmation
- Shopper never returnsDefine what happens to the order (e.g. auto-expiry, manual review)
- Payment declinedConfirm staff can identify and resolve failed transactions
- Confirmation arrives lateEstablish how delayed webhook events are handled without duplicate processing
