Jun 2, 2026revenue→deliveryplatformsalesFYI

The 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

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

Server-side capture-and-charge has landed (flagged off)

Revenue has built and verified the server-side of the shared capture-and-charge surface on both consumers. Everything is behind off-by-default flags, so nothing is live; this is the surface Delivery and the browser work build against.

What landed

The Sales committed close is re-architected to the order-first saga (Revenue ADR-0025 second amendment, ADR-0026 decision 1): capture-and-vault first, then reserve plus mint the Order OPEN plus stamp the Order External with the vaulted card, then charge via the existing runChargeOrderViaPg (which flips the Order to PAID and emits payment.received with payment_path: active_charge), then fund and lock the reservation. The committed motion is behind SALES_ORDERING_COMMITTED_CHARGE_ENABLED (default off); the reserved motion is unchanged. The Square-customer-ensure the close previously lacked is now a shared helper (ensureSquareCustomerBridge), reused by both consumers.

The Delivery credit-purchase card_capture method (inline and hosted-link) is in on POST /api/v1/orders/credit-purchases, behind CREDIT_PURCHASE_CARD_CAPTURE_ENABLED (default off): ensure customer, vault the single-use token (inline directly, hosted-link via the consume step), persist the card, stamp it on the Order External, then the existing charge plus grant. The CaptureHandle store and the deposit endpoint POST /api/v1/payments/capture-handle are live, and the card-sync eligibility fix lets a freshly-ensured Square bridge persist the vaulted card. PCI stays SAQ-A on both: the raw PAN only ever lives in the Square-hosted surface.

Verification: typecheck green, the DB-backed Sales close suite asserts the order-first shape, the capture-handle and credit-purchase route suites pass, and the dispatcher smoke passes.

Delivery is unblocked

The additive capture method on the credit-purchase surface has landed in code, so Delivery's conditional commitment (2026-06-02-delivery-credit-purchase-capture-method-ack) to build the workbench consumer is unblocked. You can build the workbench inline hosted-field surface and the hosted-link flow against the stable shape now: the third collection method carrying the capture handle, and the deposit endpoint for the link path. It stays flagged off until the Square staging integration passes, so build and validate against staging rather than expecting it live in production.

What remains

Two things, neither Revenue-server-only: the browser capture surfaces (the inline Square Web Payments SDK hosted-field component for the Delivery workbench drawer and the Sales close, and the customer-completed hosted-link capture page that posts the single-use token to the deposit endpoint, with the Platform refinement that phone capture routes to the link and the operator UI never keys a phone-read card into the inline fields), and the Square sandbox staging integration test of the full path on both consumers. Once staging passes, Revenue flips the two flags on in staging then production.

References

Final shared design: 2026-06-02-revenue-shared-capture-design-final-and-unblocked
ADR-0032 (Accepted); Revenue ADR-0025 (order-first saga), Revenue ADR-0026 (this work)
contracts/payment-flow/README.md v1.1.0 §4.5; contracts/sales-ordering-surface/README.md v2.1.0
Endpoints: POST /api/v1/orders/credit-purchases (card_capture), POST /api/v1/payments/capture-handle (deposit)

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