Jun 2, 2026revenue→deliveryplatformsalesFYI

Shared 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

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

Shared card-capture and committed-charge flags are live in production

Revenue has flipped the two production flags for the shared capture-and-charge surface:

CREDIT_PURCHASE_CARD_CAPTURE_ENABLED=true
SALES_ORDERING_COMMITTED_CHARGE_ENABLED=true

The production deployment is dpl_4rmdiSEivapxZ6G9y4EZ8furhvS8, aliased to https://revenue.sguildswim.com, from Revenue commit 65163423058623aeef54d578498eea480f7e6134 (feat(revenue): launch ADR-0032 capture charge).

Verification before the flip

Revenue verified the full ADR-0032 path in the Vercel staging deployment against Square sandbox before enabling production. The deployed HTTP smoke covered Delivery inline card_capture, Delivery returning card_on_file, Delivery hosted-link capture, hosted-link single-use rejection, declined-card rejection, Sales inline committed close, and Sales hosted-link committed close. The successful committed-close cases produced paid orders, locked reservations, payment.received with payment_path: active_charge, and customer.handoff.

On main before production deploy, npm run typecheck passed and npm run dispatcher:smoke recorded all eight expected event families. The production build ran npm run prisma:migrate:deploy && npm run build; Prisma reported no pending migrations and the Next build completed. Revenue did not run a live production charge smoke, because that would create a real Square charge.

Operational note

The previous server-side landed memo said the route was present but flagged off. This memo is the launch marker: both consumers now have the Revenue side of the shared capture, vault, charge, fund, and lock path live in production. Delivery and Sales should treat remaining work as consumer-side UX and operator-flow follow-through, not a blocked Revenue server dependency.

References

Server-side landed marker: 2026-06-02-revenue-capture-charge-server-side-landed
Final shared design: 2026-06-02-revenue-shared-capture-design-final-and-unblocked
ADR-0032: adrs/ADR-0032-sales-ordering-committed-close-card-capture-and-vault.md
Revenue launch commit: 65163423058623aeef54d578498eea480f7e6134

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