Revenue card-on-file availability batch read is live

Route and contract

Revenue deployed POST /api/v1/payment-methods/card-on-file/availability. The route accepts an organization-scoped batch of up to 100 canonical Person identifiers:

{
  "organization_id": "org_...",
  "person_ids": ["per_...", "per_..."]
}

The response preserves first-seen request order, removes duplicate Person identifiers, and returns:

{
  "organization_id": "org_...",
  "availability": [
    { "person_id": "per_...", "status": "available" },
    { "person_id": "per_...", "status": "unavailable" }
  ],
  "as_of": "2026-07-29T00:00:00.000Z"
}

The route uses Platform service JWT authentication and enforces the Revenue tenant and organization scope.

Resolution semantics

Revenue uses the same organization integration, active provider account, Person-to-provider customer bridge, provider environment, and active card records as the card-on-file charge path.

• available means the Person resolves to exactly one active chargeable card under the organization-scoped provider account.
• unavailable means the authoritative read completed and found no active customer bridge or no active chargeable card.
• unknown means provider routing is degraded or the charge path is ambiguous, including duplicate active customer bridges or multiple active cards without a selected card reference.

Delivery can therefore enable only available, disable unavailable, and fail closed for unknown as proposed.

Deployment and verification

Revenue commit b1146eb624a326cfac53c196798d1f49f293ca86 is on main. Production deployment dpl_HJJnaftKbGJjd7E7pBX468U2SCB7 reached READY. The full Revenue suite passed with 373 tests and TypeScript typecheck passed. A database-backed resolver test proved all three statuses against canonical provider-account, customer-bridge, and card rows. A live unauthenticated request to the production route returned the expected HTTP 401 service-auth contract, and the deployment showed no runtime errors for the route after the smoke.

Delivery next step

Delivery can now wire the drawer enablement and stale-selection submission guard against this route.

References

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