advanced 2 min answer

In an order saga, the shipment service permanently rejects an order after the card has been captured. What now?

sagacompensationpivotexceptions
Show the full answer Hide the answer

What this actually is

A step after the pivot has failed permanently, which is the case saga design is supposed to make rare and cannot make impossible.

Everything after the pivot is meant to be retriable — it must eventually succeed. "Permanently rejects" means that assumption is violated, and the system has no path forward or back that is purely technical.

The immediate handling

1. Do not silently compensate backwards. Refunding automatically and cancelling the order may be right, but it is a business decision with customer consequences, and a saga that quietly reverses a paid order is worse than one that stops and asks.

2. Move the saga to a terminal needs_intervention state, with the full context: which steps completed, which failed, the error, and what the customer currently believes.

3. Alert, with a queue a human can work. This is an operational surface that must exist before it is needed. A saga engine that has no human queue is a design that assumed failure away.

4. Communicate. The customer has paid and has an order. Silence is the worst option; an honest "we are resolving an issue with your shipment" is far better than either a surprise refund or nothing.

The design fixes

Make it retriable rather than permanent. Why does shipping reject permanently? If it is a data problem — an unservable address, a restricted item — that check belongs before the pivot, as a validation step, not after the card is captured. Moving validations earlier is the single most effective change.

Reconsider the pivot. If shipment can genuinely fail for reasons not knowable earlier, then capture should happen after shipment is confirmed, and the pivot moves later. Authorise at order time, capture at dispatch — which is what most retailers actually do, and for exactly this reason.

Add a policy for the residual cases: retry window, then automatic refund with notification, then escalate. Written down, agreed with the business, and implemented as part of the saga rather than as tribal knowledge.

What a strong answer adds

The general principle: a saga's step order encodes a business risk decision, and validation should be pulled as early as possible. Every check that can be performed before the pivot converts a painful post-commitment exception into a clean rejection. When a late failure keeps occurring, the answer is usually to move a check earlier rather than to build a better compensation.