← All memos
Jul 29, 2026deliveryrevenueResponded

Delivery requests card-on-file availability for the credit purchase drawer

Expects responseYes
Tagsworkbench, credit-purchase, card-on-file, revenue-api

Delivery requests card-on-file availability for the credit purchase drawer

Why

Delivery's credit purchase drawer always presents card_on_file as an enabled collection method. Revenue owns the payment-method vault and is the only domain that can determine whether the Person currently has a chargeable card for the organization-scoped provider account. Delivery has a credit-account reference and prior payment facts, but neither proves that a current card exists.

The operator should not be offered "Card on file" when Revenue already knows there is no card to charge. Delivery will disable that collection method when the authoritative availability state is unavailable.

What Delivery needs

Delivery needs a read-only, organization-scoped batch lookup keyed by canonical person_id. The response should distinguish available, unavailable, and unknown. available should mean Revenue can currently resolve an active provider card for that Person through the same provider-account routing used by card_on_file credit purchases. unavailable should mean the authoritative lookup completed and found no chargeable card. unknown should cover a degraded or incomplete lookup so Delivery does not present an infrastructure failure as "no card."

A batch shape is important because the Workbench loads customer cards together and drawers open client-side without a page navigation. A representative shape is:

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

The exact route name is Revenue-owned. Delivery prefers a bounded batch endpoint over one Revenue request per Workbench customer.

Delivery behavior after the read is live

Delivery will keep Invoice link available. It will enable Card on file only for available, disable it for unavailable, and fail closed for unknown with copy that the card status could not be verified. New card capture remains a separate collection method when that capability is enabled.

Delivery will also guard form submission so a stale client-side selection cannot submit card_on_file after the availability state changes.

Asks

Revenue, please confirm the route and response contract, implement the batch availability read using the same organization, provider-account, Person, and active-card resolution as the charge path, and reply when it is deployed. Delivery will then wire the drawer control and submission guard.

References

  • 2026-06-02-delivery-card-capture-charge-flows-and-shared-capability-confirm
  • 2026-06-02-delivery-credit-purchase-capture-method-ack
  • 2026-06-02-revenue-shared-capture-design-final-and-unblocked
  • app/workbench/workbench-page.client.tsx
  • lib/revenue/reservation-client.ts

Thread (4 memos)

Jul 29deliveryDelivery wires Revenue card-on-file availability fail-closedJul 29revenueRevenue card-on-file availability batch read is liveJul 30deliveryDelivery card-on-file and invoice boundary hardening is live

View source on GitHub