Shipping, stock and payments: keep one order consistent across systems
Assign ownership of each piece of data and handle confirmations, cancellations and failures so one purchase stays consistent throughout the operation.
The store says paid, the inventory system is still waiting for confirmation and the carrier has a label with the old address. Every integration may be responding normally while the order itself is wrong.
Start by tracing one purchase from beginning to end. List the systems and identify who owns price, availability, payment, picking and delivery. Two systems changing the same information without a clear rule create discrepancies that are difficult to explain.
Link the records with order references
Keep the relationship between the store’s order identifier, the provider’s transaction and the shipment record. Staff should be able to start with any one and find the others. Do not rely on customer names as a link: people order repeatedly and may share names.
Decide which information is recorded with the purchase. The selected address, items and price at that time must remain understandable even after the customer profile or catalogue changes.
Describe transitions before building integrations
Decide when units are reserved, when stock is deducted and when a reservation is released. In a hypothetical last-item scenario, two people start checkout almost simultaneously. The process must prevent incompatible promises about the same available stock.
Keep payment, preparation and dispatch separate. Creating a label does not mean a parcel has reached the carrier; confirming payment does not mean the product has been picked. Statuses should guide staff and tell customers what has actually happened.
Expect repeated messages
Stripe’s webhook documentation notes that events can be repeated and delivered out of order.
The store’s design therefore needs operations that recognise completed work. Processing a confirmation again must not deduct stock twice or create a second shipment. Ask the technical team to demonstrate this using test events, rather than relying only on a successful ideal-path order.
Make exceptions visible
Create a queue for orders requiring attention: paid without picking, shipment without a valid label or cancellation awaiting confirmation. Record the last attempt, failure reason and who can resolve it. Silent errors waste time because support discovers them only when the customer complains.
- Temporarily interrupt shipping integration and observe recovery.
- Repeat the same payment confirmation.
- Cancel an order before and after picking.
- Change an address after label creation and check the agreed rule.
- Compare balances and records after each scenario.
An integration is ready when orders complete the journey and exceptions can be found and resolved. The number of connected systems is not evidence of that on its own.
Continue with the Pix and card payment journey.
About the author
Tiago F SantiagoComments
No comments yet
Share a question or an experience related to the article.
Related articles
