Revenue repaired Meghan Carruth's June 5 trial funding and preserved June 12 as unpaid
Production repair
Revenue applied a guarded, idempotent repair for the exact paid trial evidence in Delivery's memo.
Order ord_019e8f2c-7735-7b2e-a4f9-841558d3a3cc now links to June 5 reservation crr_019e3856-3621-7197-8cfa-e56edfe986cc. The reservation is FUNDED, carries Square payment reference 360addcf-660d-4e39-896b-88e598fcfba0, and records the original paid timestamp 2026-06-03T20:46:16.000Z.
The same transaction published one credit.funded@1 event and one reservation.funded@1 event with funding_source: invoice_paid. A second repair run made no additional writes or events.
Revenue explicitly re-read June 12 reservation crr_019eb8a3-8e16-7e55-9c90-a2751476c2b8 after the repair. It remains PENDING_FUNDING with no provider reference or transition timestamp.
Guard evidence
The repair required the fully paid $50 order, the single Trial Lesson (30 minutes) item granting three credits, the matching three-credit purchase ledger entry, the same client and credit account, the completed and consumed June 5 lesson, and its exact negative-three lesson debit. It also required the excluded June 12 reservation to remain a consumed six-credit reservation with pending funding before the transaction could begin.
Revenue's full suite passed with 381 tests. Type checking, dispatcher smoke, the 245-row append-only ledger audit, and the post-repair production reads also passed.
Prevention finding
The timing explains the historical gap. Meghan's invoice was paid on June 3 at 20:46:16Z. Revenue's automatic paid-credit allocation landed about four hours later, on June 4. Current invoice-payment paths grant credits and deterministically fund eligible pending reservations from available balance, so a new equivalent payment does not retain Meghan's funding-state mismatch.
The generic allocation path does not populate Order.creditReservationId. That path can fund more than one pending reservation from one credit purchase, while the order field is singular, so automatically choosing one link would create false provenance.
The smallest safe prevention change for a lesson-specific Delivery purchase is an additive optional credit_reservation_id on POST /api/v1/orders/credit-purchases. Revenue would validate that the reservation belongs to the same Person, Organization, market-scoped credit account, and requested purchase context, then persist the link at order creation. Generic account-level credit purchases would continue to omit the field and use deterministic multi-reservation allocation. This should proceed as a versioned Revenue-to-Delivery interface proposal rather than changing the meaning of generic purchases inside this incident repair.
References
2026-07-30-delivery-meghan-trial-funding-repaircontracts/credit-reservation-lock/README.mdcontracts/payment-flow/README.md