The first order after launch is usually celebrated. The first partial return is where the system becomes real. One item comes back, another stays, a discount touched both, shipping was conditional, tax must be corrected and the warehouse has already marked the parcel received. None of that appeared in the sales demo.
A commerce build is not finished when checkout succeeds. It is finished when ordinary exceptions can move through the business without a spreadsheet acting as the missing backend.
Returns are a state machine
A return is not a button that issues money. It moves through request, eligibility, authorisation, shipment, inspection, restock, refund and communication. Some products are excluded. Some refunds are partial. An exchange can reserve new inventory before the old item arrives. A promotion may need to be recalculated.
The cost is not only development. Operations needs rules, reason codes, permissions and a view of what happened. Finance needs reconciliation. Support needs a truthful status without asking the warehouse in a private channel.
Before launch, write the return states and name who can move an order between them. If the answer is simply admin, the workflow is still undefined.
Subscriptions multiply failure paths
Subscription checkout looks like a small extension to ordinary payment. The operational surface is much larger. Cards expire, renewals fail, prices change, products go out of stock, customers pause, addresses become invalid and cancellation rules vary by contract.
The difficult work sits between systems. The payment provider knows about the charge, the commerce platform knows about the order, the fulfilment system knows about stock, and support has to explain the combined truth. A webhook arriving twice or late must not create duplicate fulfilment. A retry must preserve a trace of every attempt.
Treat billing state and fulfilment state separately. Paid does not always mean ready to ship, and cancelled does not always mean nothing remains to refund.
Support tooling belongs in the build
A customer account page can be elegant while the internal support screen is unusable. That imbalance becomes recurring labour. If staff cannot search by order, payment reference, email and shipment identifier, each case turns into detective work. If they cannot see the event history, they guess.
The minimum useful operational view includes the current state, the source of that state, recent events, safe actions and the consequences of each action. Sensitive operations should have narrow permissions and an audit trail. Free text notes help, but they do not replace structured reasons for refunds, cancellations and manual overrides.
The catalogue keeps charging rent
After launch, products change. New variants arrive, tax classes move, images are replaced, translations drift and feeds reject records. Promotions overlap. Search synonyms need attention. Third party integrations change their contracts or payloads.
This work needs an owner and a budget. The alternative is not zero cost. It is slow catalogue decay, manual patches and decisions made from conflicting exports. Maintenance should include feed monitoring, failed job queues, dependency updates, payment changes, accessibility checks and periodic recovery tests.
Price the operating model this week
Take a representative order and walk it through cancellation, partial return, exchange, failed payment, delayed shipment and support escalation. For every transition, record the system of record, responsible role, customer message and reconciliation step. The gaps are the post-launch backlog.
Then separate the budget into platform fees, payment and app charges, hosting, monitoring, support time, catalogue operations and engineering capacity for change. A low build quote that excludes these surfaces is not a lower commerce cost. It has moved the cost into daily work where it is harder to see and more expensive to remove.