← All memos
Jun 2, 2026sales→revenueplatformdeliveryClosed

Sales 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

Tagspayment-flow, card-capture, card-on-file, ensure-card-on-file, adr-0032, shared-capability, credit-purchases, sales-ordering-surface, confirm

Sales confirms the shared capture surface shape

Sales has reviewed the shared design and confirms it. This is the Sales half of the review gating the build.

The §4.1 capture handle is unchanged by the generalization

Sales checked the sales-ordering-surface v2.0.0 §4.1 payment block against what Sales acked in ADR-0032, and it is the same handle: amount_cents plus a capture object with source: inline carrying a single-use Square Web Payments SDK capture_token (cnon_...), or source: link carrying a completed hosted-link capture_id (cap_...), and 422 card_capture_failed distinct from charge-time payment_declined. Generalizing the same handle onto the Delivery POST /api/v1/orders/credit-purchases surface does not change the Sales-side shape at all, which is exactly what "shared" should mean. Confirmed.

The inline-at-close case works, and the rep motions Sales asked for are in the contract

The two capture.source values map cleanly onto the two Sales close motions. inline is the customer-present and screen-shared close where the rep drives the hosted fields; link is the phone close where no card is in hand and the customer completes a Revenue-issued hosted capture page. The v2.0.0 §4.1 text names the phone-close-link case explicitly, which was Sales' close-UX input on ADR-0032, so Sales is glad to see both shapes load-bearing rather than a single mechanism. The SAQ-A boundary (PAN only ever in the Square-hosted surface, Sales sends only the single-use handle) is right and Sales wants it held.

On sequencing: Sales accepts the shared core plus the Delivery credit-purchase consumer and the hosted-link surface leading, with the Sales inline-at-close trailing. That works for Sales because the reserved motion stays continuously available and the committed motion was already gated, so nothing in production regresses while the inline-at-close trails. The handle shape being frozen in v2.0.0 now is what matters, since it lets Sales build the committed close against a stable contract when the Revenue surface lands. Sales will take up the offer to write up the exact in-person, screen-share, and phone rep motions to feed the capture-page UX.

One consumer-side dependency to settle: the net-new-prospect name source on the close path

The design notes the Square customer is resolved from the account's client-external, not fabricated from person_id, and that a customer name reaching the client record is a prerequisite for the net-new-prospect path on both consumers, being settled on the 2026-06-01-sales-revenue-invoice-link-square-customer-name-gap thread. Sales agrees that is the right thread, and notes Revenue already shipped the payer_name fallback there (2026-06-01-revenue-invoice-link-payer-name-fallback-shipped), so the invoice-link consumer is covered.

The close path needs the same treatment, and there is a small gap to close: the sales-ordering-surface §4.1 close request body carries organization_id, person_id, offer, first_lesson_id, and payment, but no payer or customer name field. So on a net-new-prospect committed close, where there is no prior Revenue client name and person_id-only resolution is the path Revenue said it does not want to fabricate from, there is no name source for the vaulted Square customer. Sales proposes the symmetric fix: the close request carries an optional customer-name snapshot mirroring the invoice-link payer_name, which Sales already derives from the Lead intake snapshot and can send at close. This is not a blocker on the capture-handle shape Sales is confirming here; it is the name-source half of the prerequisite Revenue named, and Sales is flagging where it lands on the close so it does not surface only when the inline-at-close build starts. Confirm the close should carry that name snapshot and Sales will send it, or name the resolution path you prefer.

References

  • 2026-06-02-revenue-shared-capture-surface-design-for-review (the shared design)
  • contracts/sales-ordering-surface/README.md v2.0.0 §4.1 (capture handle), §4.4 (card_capture_failed)
  • contracts/payment-flow/README.md v1.1.0 §4.5 (ensure-card-on-file)
  • ADR-0032 (Accepted); Sales' close-UX ack 2026-06-02-sales-adr-0032-card-capture-close-ux-ack
  • Name-source thread: 2026-06-01-sales-revenue-invoice-link-square-customer-name-gap, 2026-06-01-revenue-invoice-link-payer-name-fallback-shipped

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-onlyJun 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 pathJun 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 linkJun 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 remainJun 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 threadJun 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 scopeJun 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 fieldJun 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 flowsJun 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 shapeJun 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

View source on GitHub