The engineering bottleneck with assembled stacks
Merchants outgrow a hosted storefront’s checkout hook and discover the backend they actually needed was never the shop window: it is the order state machine, the inventory truth, the payment-event reconciliation at 3 a.m. Renting those pieces from the storefront platform means your order history — the business itself — is exportable at the platform’s pleasure and priced by its tiers.
Architecture on the Software Lifecycle Cloud
Catalogue rows carry price, stock, and the fields the text index searches; a cart is a session-keyed record the storefront functions read and write. Checkout creates an order row and hands payment to the provider; the provider’s webhooks return as stored raw events that a worker reconciles into order states, so “paid” is a derived, provable state. Fulfilment steps — pick, pack, ship, the occasional human “call the customer” — run as a workflow per order.
Payment events are evidence, reconciled like it
Money-adjacent systems fail by ambiguity, so the design stores the provider’s events verbatim before interpreting them. When a customer swears they paid and the order says otherwise, the raw event log is the court of appeal — and because webhook ingestion is idempotent by event id, the provider’s retries cannot double-apply a payment no matter how their night went.
- Stock is a counter on the catalogue row, decremented in the same discipline as the order write
- Order states derive from stored payment events — reconciliation is a readable derivation, not a sync job
- Fulfilment exceptions become human workflow steps with the order attached, not email threads
The storefront can stay where it is
Nothing here demands a replatform of the shop window. The storefront — hosted or your own app in the project — calls this backend for catalogue, cart, and orders. Teams typically move the backend first, because that is where the data gravity and the 3 a.m. problems live, and let the window follow when it earns its turn.
Frequently asked questions
With your payment provider, always. The backend creates orders, hands over for payment, and ingests the provider’s events raw for reconciliation. Card data never touches your project, which keeps PCI scope where it belongs.
Stock is a field on the catalogue row, adjusted by the same functions that create and cancel orders; every adjustment is a recorded change. Oversell protection at flash-sale scale is a design conversation about your real volumes — the mechanism is keyed, atomic record updates.
Yes. Treat this as the backend migration: catalogue, carts, orders, and fulfilment move into your project while the storefront keeps calling APIs. The data that defines the business stops living exclusively on rented ground.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.