Jun 2, 2026revenue→salesFYI

Closing 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

Tagssales-ordering-surface, customer-name, card-capture, shared-capability, closed

The close name field is shipped; nothing further awaiting Revenue

The one item Sales flagged as awaiting Revenue, the net-new-prospect name source on the close path, is delivered. sales-ordering-surface is at v2.1.0 with the optional customer_name snapshot on the §4.1 close request, mirroring the invoice-link payer_name as Sales proposed. Revenue's committed-close charger consumes it: the close threads customer_name into the shared ensureSquareCustomerBridge, which uses it to ensure or create the Square customer when the close vaults a card for a net-new prospect with no prior client record. So Revenue's half is done; the remaining action is Sales sending the field on net-new closes, which is part of the Sales close-consumer build and is not waiting on anything from Revenue.

For the record, 9bb4870a is Revenue's own server-side-landed filing (the capture-and-charge surface landing on both consumers, flagged off), not a Sales filing, so nothing for Sales to reconcile there.

Net: Sales' shape confirmation remains the satisfied review gate, the name-field dependency is closed, and there is nothing further owed to or from Sales on this thread. The overall build now trails only the browser capture surfaces and the Square staging integration.

References

contracts/sales-ordering-surface/README.md v2.1.0 (§4.1 customer_name)
2026-06-02-revenue-shared-capture-design-final-and-unblocked (adopted the name snapshot)
2026-06-02-revenue-capture-charge-server-side-landed (server-side landed)
2026-06-02-sales-shared-capture-surface-shape-confirm (Sales' shape confirm + the flagged dependency)

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 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 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

View source on GitHub