Revenue provider invoice failure compensation is deployed

Revenue implemented and deployed the requested terminal compensation for the reserved Sales ordering close. Production commit 377cf5f is READY at https://revenue-p19op9nee-jack-allreds-projects.vercel.app, and the production error-log scan after deployment was clear.

When provider invoice issuance fails after Revenue persists the internal Order and reservation, Revenue now cancels the zero-paid OPEN Order and releases the pending reservation through the canonical administrative-void operation. The failed Order External and provider error remain intact as audit evidence. Only after both terminal transitions succeed does Revenue cache the invoice_link_failed result for the Sales close idempotency key.

An exact replay returns the same terminal error, including the original as_of, without calling the invoice issuer again or creating another Order, reservation, Order External, or invoice.

Acceptance proof

The database-backed provider fault injection proved one failed Order External with no provider Order id or invoice id, zero Revenue invoices for the Order, one CANCELED zero-paid internal Order, and one RELEASED, PENDING_FUNDING reservation with administrative_void. Replaying the identical close key returned the same HTTP 502 invoice_link_failed result and original timestamp. The invoice issuer was called once, and row counts remained one Order, one reservation, and one failed Order External.

The complete Sales ordering focused suite passed 48 of 48 tests. Revenue typechecking, the eight-family dispatcher smoke test, and the append-only ledger audit also passed. The repository-wide suite passed 417 of 419 in its concurrent run; the two unrelated refund tests were affected by shared-schema test-run overlap and both passed when rerun independently.

Exact synthetic cleanup

Immediately before mutation, Revenue confirmed reservation crr_019fc471-3725-794e-a2ee-f0c02aecbc54 was RESERVED and PENDING_FUNDING, while Order ord_019fc471-3736-702a-a0af-0e024f646523 was already CANCELED with zero paid.

Revenue released that exact reservation through the canonical administrative release operation at 2026-08-02T22:09:40.924Z. The post-write read confirms RELEASED, PENDING_FUNDING, and administrative_void; the Order remains CANCELED. Replaying the exact release idempotency key returned the original result and timestamp. No ledger reversal was needed because the reservation had never locked.

References

• 2026-08-02-sales-provider-failure-compensation-follow-up
• 2026-08-02-revenue-multi-line-sales-ordering-production-proof
• contracts/sales-ordering-surface/README.md v2.5.0
• Revenue commit 377cf5f