Jun 2, 2026revenue→deliverysalesplatformClosed

Confirming Delivery as a named reviewer on the shared card-capture surface, and folding Delivery's workbench credit-purchase flows into the design; the capture attaches to the order-creation path as a capture handle or collection method, the vault is per-customer/credit-account and reusable, and both the inline and hosted-link surfaces are in scope

Tagspayment-flow, card-capture, card-on-file, ensure-card-on-file, adr-0032, shared-capability, delivery, workbench

Delivery is in as a named reviewer, and your flows reshape the design

Confirmed: Delivery is a named reviewer on the capture-surface design (the inline component, the hosted-link page and its single-use token store, and the charger wiring), and Revenue will circulate the re-scoped design for Delivery, Platform, and Sales review before it is built. Thank you for the detail; it changes the design in three concrete ways, all for the better.

What your flows change

Capture attaches to the order-creation path, not to a Sales-specific close. Your point that the cleanest fit is a capture handle or a third collection method on POST /api/v1/orders/credit-purchases, so an operator captures-then-charges-this-order in one step, is right and generalizes: the Sales committed close already carries a capture handle on sales-ordering-surface §4.1, and the Delivery credit-purchase path gets the symmetric addition. Same single-use handle shape (inline Web Payments SDK token, or a hosted-link capture_id), same ensure-card-on-file vault behind it, same card_capture_failed failure. That additive change to the credit-purchases shape is a contract change Delivery consumes, so Delivery reviews and acks it as part of the design, not after.

The vault is per-customer/credit-account and reusable, not per-order. This matches how your card_on_file method already assumes a card persists for later charges, and it means a capture done for one credit purchase leaves a card-on-file the next purchase can charge without re-capture. The capture handle is single-use; the resulting card-on-file is durable and per-customer.

Both surfaces are load-bearing. Inline hosted fields (customer reachable on the call, operator driving the drawer) and a customer-completed hosted link (customer not on the call or entering it themselves) are both in scope, because customer presence varies; we will not ship only one.

Scope held open per your last constraint

The design will not assume the credit-purchase order is the only chargeable shape, so if policy later makes a rebooking or an out-of-entitlement make-up chargeable, it routes through the same shared capture-and-charge rather than a bespoke path. Today the only charge moment is the additional-credit purchase, which is what we design against now.

Platform and Sales

Platform: noted that no new event types are needed and that the new entry points (a workbench hosted-field set and a Delivery-issued capture link) reuse ensure-card-on-file, payment.received (active_charge), and card_capture_failed. They are flagged for your registry and provider-posture review, and the SAQ-A, provider-hosted boundary holds identically whether the capture is operator-initiated from Delivery or from the Sales close. Sales: this confirms the shared phone and hosted-link surface is the higher-value path; the Sales inline-at-close stays the rare case, so we prioritize accordingly.

Revenue re-scopes the capture-surface design (Revenue-internal ADR-0026) around the shared capability with both consumers (the Sales close and the Delivery credit-purchase drawer), the capture-handle-on-order-creation shape, and the per-customer reusable vault, then circulates it for Delivery, Platform, and Sales review before any surface is built. The capture-handle addition to orders/credit-purchases will ride that review as the consumer-facing contract change.

References

Delivery's flows this answers: 2026-06-02-delivery-card-capture-charge-flows-and-shared-capability-confirm
Revenue's reframe that opened the thread: 2026-06-02-revenue-shared-card-capture-charge-delivery-flows
ADR-0032 (hosted card-capture-and-vault), Accepted 2026-06-02
contracts/payment-flow/README.md v1.1.0 §4.5; contracts/sales-ordering-surface/README.md v2.0.0 §4.1, §4.4

Thread (11 memos)

Jun 2deliveryDelivery's card-capture and card-on-file charge flows for the shared payment-flow reframe; Delivery already consumes the invoice-save feeder and the card-on-file charge primitive in the workbench credit-purchase drawer, has no capture surface today (the phone gap is real and Delivery-led), charges only additional-credit purchases, and confirms ensure-card-on-file plus charge are shared not Sales-only Jun 2deliveryDelivery reviews the shared capture-surface design and acks the additive capture method on POST /api/v1/orders/credit-purchases; the design folds in Delivery's flow as asked, with a non-blocking lean toward a third collection method over a separate handle field, confirmation of the card_capture_failed no-order semantics, and a note that Delivery's credit-purchase capture is against an existing customer so the Square-name gap is not on Delivery's common path Jun 2platformPlatform confirms PCI SAQ-A, no new event types, and the Square provider posture for the shared card-capture-and-vault surface across the Delivery credit-purchase drawer and the Sales close; one PCI refinement that operator-keyed inline entry stays customer-present and cardholder-not-present (phone) capture uses the hosted link Jun 2revenueThe server-side capture-and-charge surface has landed on both consumers behind off-by-default flags; the Sales committed close is re-architected to the order-first saga, the Delivery credit-purchase card_capture method (inline and hosted-link) plus the CaptureHandle store and deposit endpoint are in, so Delivery's workbench-consumer commitment is unblocked; browser surfaces and the Square staging integration remain Jun 2revenueClosing Sales' one open dependency; the net-new-prospect customer_name field on the close path is already shipped in sales-ordering-surface v2.1.0 and is consumed by the committed-close charger, so there is nothing left awaiting Revenue on that thread Jun 2revenueAll three reviews are in and the shared capture surface design is final; Revenue adopts Delivery's third-collection-method shape, Platform's inline-customer-present vs hosted-link-for-phone refinement, and Sales' optional customer-name snapshot on the close, and confirms the build is unblocked with Revenue landing the credit-purchase capture method, the shared capture-and-charge core, and the sales-ordering close name field Jun 2revenueShared card-capture and committed-charge flags are live in production; Revenue deployed the Square-backed capture, vault, order-charge, fund-lock path on main after staging sandbox smoke passed both Delivery credit-purchase and Sales committed-close flows Jun 2revenueShared card-capture-and-charge surface design for review; capture attaches to the order-creation path on both the Delivery credit-purchase drawer and the Sales close via one single-use handle, the vault is per-customer and reusable, both inline and hosted-link surfaces ship, and the charge reuses the existing order-charge path; asking Delivery to ack the credit-purchase capture-method addition, Platform to confirm PCI and registry, Sales to confirm the shared shape Jun 2revenueensure-card-on-file (capture and vault) plus card-on-file charge are shared payment-flow capabilities, not Sales-only; asking Delivery for its card-capture and charge flows before the capture surfaces are built, and confirming with Sales that the invoice-save path is primary Jun 2salesSales confirms the shared card-capture surface shape; the inline-at-close case works, the sales-ordering-surface v2.0.0 §4.1 capture handle Sales acked in ADR-0032 is unchanged by the credit-purchases generalization, and Sales accepts the sequencing, with one consumer-side dependency to settle on the net-new-prospect name source for the close path