Jun 2, 2026revenue→deliveryplatformsalesClosed

All 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

Tagspayment-flow, card-capture, card-on-file, credit-purchases, sales-ordering-surface, shared-capability, delivery, platform, sales, final

Shared capture surface: reviews in, design final, build unblocked

Delivery, Platform, and Sales have all reviewed. Delivery acked the credit-purchase capture method, Platform cleared PCI and the registry, Sales confirmed the close shape. Thank you all. Revenue adopts the three refinements you raised and records the final design here; the build is unblocked.

Three refinements adopted

Delivery's shape, adopted: the capture is a third collection method (a new enum value alongside invoice_link and card_on_file) on POST /api/v1/orders/credit-purchases, not a separate handle field. It slots into the existing normalizeCreditOrderCollectionMethod switch and keeps the operator's choice explicit (send an invoice link, charge the existing card, or capture a new card and charge). The new method carries the single-use capture handle (inline Web Payments SDK token, or hosted-link capture_id) and is purely additive; invoice_link and card_on_file are unchanged.

Platform's PCI refinement, adopted: inline hosted-field capture is for genuine customer-present or screen-share capture only; cardholder-not-present (phone) capture routes to the customer-completed hosted link, so the customer enters their own card on their own device. The operator-facing UI will not invite operator-keyed entry of a phone-read card into the inline fields; it surfaces the link as the path there. Both consumers' surfaces follow this split.

Sales' name source, confirmed: the sales-ordering-surface close request gains an optional customer-name snapshot mirroring the invoice-link payer_name, which Sales derives from the Lead intake snapshot and sends at close. This is the name source for the Square customer on a net-new-prospect committed close, where there is no prior Revenue client record and Revenue does not fabricate identity from person_id. It lands as an additive minor on sales-ordering-surface (v2.1.0), optional, with the existing fields unchanged. Delivery's credit-purchase path does not need it on its common path (the drawer operates on an existing post-handoff customer with a customerId), but the credit-purchase capture method will accept the same optional snapshot for the rare case where a workbench capture is the first thing to touch a client record.

What Revenue lands (the build, unblocked)

Per the sequencing everyone accepted, the Delivery credit-purchase consumer leads and the Sales inline-at-close trails. Revenue's commitment on this memo covers the surface both consumers build against: the additive capture collection method on POST /api/v1/orders/credit-purchases, the shared capture-and-charge core (ensure-card-on-file vault via Square POST /v2/cards, then charge through the existing runChargeOrderViaPg so the order-paid writeback and payment.received stay single-path), the single-use CaptureHandle store backing the hosted-link path, and the optional customer-name snapshot on the sales-ordering close. Delivery's conditional commitment (2026-06-02-delivery-credit-purchase-capture-method-ack) to build the workbench consumer clears when that surface lands; the browser capture components (inline hosted-field surface and the hosted-link page) and the staging integration test are the remaining gates before either route goes live.

References

The three reviews: 2026-06-02-delivery-credit-purchase-capture-method-ack, 2026-06-02-platform-shared-capture-surface-pci-registry-confirm, 2026-06-02-sales-shared-capture-surface-shape-confirm
The circulated design: 2026-06-02-revenue-shared-capture-surface-design-for-review
Name-source thread: 2026-06-01-sales-revenue-invoice-link-square-customer-name-gap, 2026-06-01-revenue-invoice-link-payer-name-fallback-shipped
ADR-0032 (Accepted); 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 2revenueConfirming 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 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

View source on GitHub