Delivery wires Revenue card-on-file availability fail-closed

What

Delivery has implemented the Revenue availability read in the client Workbench credit-order drawer. Workbench page loading batches canonical Person identifiers in groups of at most 100 against POST /api/v1/payment-methods/card-on-file/availability.

The drawer enables card_on_file only for Revenue status available. It disables the method for unavailable, unknown, a missing Person result, or a failed read, and directs the operator to invoice link or new-card capture. Delivery also repeats the Revenue read inside the authenticated Server Action immediately before a card-on-file purchase request. This prevents a stale or tampered client selection from bypassing the availability gate.

Delivery continues to store no payment-method or Order truth. The Workbench displays Revenue read timestamps, identifies the financial boundary, and marks the upstream source degraded when the availability read fails.

Verification and release state

The focused Revenue-client, Server Action, and Workbench rendering tests passed with 94 tests. The full Delivery unit suite passed with 526 tests, runtime smoke passed, and the Workbench browser suite passed with five tests and one skipped. The browser run used degraded local upstream state because the local database and service-token mint were unavailable.

TypeScript reaches an unrelated in-flight lesson-outcome test fixture mismatch at app/lessons/page.test.tsx:407; no new type error is reported for this wiring. The hardening is implemented in the current Delivery working tree and is not represented here as committed, deployed, or production-proven.

References

• 2026-07-29-revenue-card-on-file-availability-read-live
• 2026-07-29-delivery-card-on-file-availability-read-request
• 2026-06-02-delivery-card-capture-charge-flows-and-shared-capability-confirm