An order arrives on a webhook and passes through thirteen steps before anything is confirmed: validation, customer resolution, order creation, payment check, inventory check, notification, logging and response. Every branch that can fail has somewhere to go.
Results at a Glance
A single order has to reach the customer database, the CRM, the payment gateway, the inventory system and the accounting log. Doing that by hand is slow; doing it with a script that assumes everything works is worse, because the failures are silent.
This workflow makes each of those steps explicit and gives each one a failure path, so an out-of-stock product or a declined payment produces a notification rather than an order that quietly never ships.
The difficulty in an order pipeline is not the happy path, it is everything else. A customer might already exist or might be new. Payment might not clear. Stock might have gone while the order was in flight. Each of those needs a different route, and none of them can end in silence.
New or returning customer
The same order needs a different route depending on whether the customer already exists, and the rest of the pipeline should not have to care which.
Payment might not clear
A declined payment has to stop the order and say so, rather than creating a fulfilment nobody paid for.
Stock moves while you wait
Inventory is checked at the point of processing, and an out-of-stock result notifies both sides instead of failing quietly.
Someone will ask what happened
Every run writes to Postgres and Sheets, so a disputed order can be reconstructed.
The challenge was real, and it was costing time, money, and client experience.
The webhook validates and parses the incoming order, then checks whether the customer already exists. Existing customers are fetched and updated; new ones are created and added to the CRM. Both paths merge before the order is created, so downstream steps do not need to know which route was taken.
Payment and inventory are then checked in turn. In-stock orders deduct their stock and continue; out-of-stock orders branch to notify both the admin and the customer. Everything is logged to Postgres and Google Sheets before a success response returns to the webhook caller.
The solution was designed from the ground up to fit this exact business.
A webhook takes the order, parses it and checks the required fields before anything downstream runs.
Existing customers are fetched and updated, new ones created and pushed to the CRM, then both paths merge.
Payment status and inventory are verified through their own APIs, each with its own failure route.
Email and SMS out, Postgres and Sheets written, success returned to the caller.
Each tool chosen specifically for reliability, integration depth, and ease of use for the client.
Orchestration, branching and error handling.
Customer, CRM, order, payment and inventory systems.
Durable order log.
Operational view the team can read.
One webhook in, a fulfilled order and a complete audit trail out.
Documented on the canvas, so the next person can follow it.
Customer, CRM, payments, inventory and accounting.
Postgres for durability, Sheets for the people who need to look.
Send me the brief, a Figma file, a reference site or a rough outline, and you'll have a fixed quote with a delivery date within 24 hours.
