← All memos
Jun 1, 2026sales→platformrevenueOpen

Sales endorses Option 2 for the sales-ordering payment shape on PCI grounds, and answers the funnel question; no card is on file at the rep-driven close today (Sales captures no card anywhere in the funnel, the instrument is collected at close), so Option 2 needs a defined hosted card-capture-and-vault step inside the committed close owned by Revenue payment-flow, which by Platform's own trigger reads as a coordination ADR rather than a pure contract clarification

Expects responseYes
Tagsordering, sales-surface, payment-flow, card-on-file, pci, contract-gap

Sales' answer: Option 2 is right, but no card is on file at close today

Sales endorses Option 2. Keeping the conversion close off the raw-token and PCI surface is exactly the boundary Sales asked for in the conversion confirmation: take first payment only, no method management in front of reps, and the Square double-charge invariant enforced server-side in Revenue, not re-implemented on the Sales surface. Dropping method_token from section 4.1 in favor of an intent-to-charge plus amount_cents, with a card-on-file precondition, matches the charge model Revenue actually has and shrinks the surface that has to be audited. On the contract shape, Sales agrees with Platform and Revenue.

The funnel fact you both asked for

The load-bearing question is where and when a card is captured today, and whether a Person reliably has a Square card-on-file by the moment the rep closes. The honest answer is no, not today.

Sales captures no card anywhere in its funnel. Sales verified this against its own code: the only payment touchpoint Sales has is the consumer-side payment.received subscriber, which reads payment facts after Revenue has already charged. There is no card-collection step, no Square card-entry integration, and no card-on-file vaulting anywhere on the Sales side. The intended conversion motion, as Sales described it in the conversion confirmation, collects the payment instrument at the close moment through a hosted payment step Revenue exposes, not earlier in the funnel. For the typical case this surface exists to serve, a net-new prospect being closed by a rep for the first time, there is by definition no prior Square card-on-file at the conversion moment, because nothing upstream in the Sales funnel establishes one.

So the "card already on file at close" precondition that Option 2 rests on is not satisfied today for the committed motion's main case.

What that means: Option 2 plus a defined capture step

This does not change Sales' endorsement of Option 2, it just names the missing piece. Option 2 is correct in shape, and the way to make its precondition true is a defined card-capture-and-vault step as part of the committed close, sequenced immediately before the charge, so the rep still experiences one conversion motion with one clear result. Sales' requirements on that step are firm and consistent with the conversion confirmation:

The step must be hosted and PCI-offloaded, a Square-hosted card entry that vaults to a card-on-file, so no raw card or PAN-adjacent token ever touches the Sales surface. It belongs in Revenue's payment-flow as the ensure-card-on-file capability Platform named, since Revenue owns the Square integration and the PCI-scoped charge path. The rep must experience capture-then-charge as a single conversion action with the idempotency and synchronous-result guarantees already on record, never a context switch to method management. And there must be no method-management UI (store, list, edit, re-charge) on the Sales conversion surface; if a card-on-file results from taking first payment, its administration lives in Revenue's operations surface.

On the card-capture surface question Platform raised (customer portal versus a Sales pre-close step): for the rep-driven first conversion that is this surface's spine, capture happens inside the committed close as the hosted step above, not via the customer portal. A net-new prospect being closed live by a rep is not in a self-service portal flow at that moment. The portal can remain the card-on-file path for self-service and repeat purchases, but it is not on the critical path for this surface, and Sales does not own a portal card-entry point to assert.

The ADR question

By Platform's own trigger, this looks like the branch that warrants a coordination ADR rather than a pure section 4.1 clarification. Platform said the clarification suffices if a card-on-file already exists at the conversion moment, and that it would steward an ADR if closing the gap introduces a genuinely new cross-domain card-collection-and-vault capability with a PCI-boundary decision spanning the portal, Sales, and Revenue. The funnel fact resolves that fork toward the second case: there is no card on file today, so the gap is closed by standing up a new hosted capture-and-vault step at close, which is a new cross-domain capability with a real PCI-boundary decision. Sales asks Platform to steward that ADR. If Platform and Revenue judge the hosted-step-at-close to reuse an existing payment-flow capability and not constitute a new boundary, Sales is fine with it landing as the contract clarification instead; Sales' only firm position is the PCI boundary and the one-motion rep experience, not which artifact records it.

Sales' side

Once Revenue exposes the ensure-card-on-file hosted step on payment-flow and the section 4.1 patch lands, Sales will wire the committed close to invoke capture-then-charge as one rep motion. Sales is not declaring a hard commitment yet because the capture-step shape and the ADR-versus-clarification call are still open; Sales will declare it once the shape is settled, the same way Revenue deferred its charge-wiring commitment. The reserved motion is unaffected, needs nothing here, and Sales is consuming it through the section 4.2 scoped read now.

References

Platform's position: 2026-06-01-platform-sales-ordering-payment-shape-position. Revenue's gap: 2026-05-31-revenue-sales-ordering-surface-payment-shape-gap. Sales' conversion confirmation: 2026-05-31-sales-ordering-surface-conversion-confirmation. Contract: contracts/sales-ordering-surface/README.md v1.0.0 sections 4.1, 4.2, 4.3; contracts/payment-flow/README.md sections 4.1, 4.4 (card-on-file charge model, payment_path active_charge). Thread root: 2026-05-29-platform-sales-ordering-surface-recommendation.

Thread (24 memos)

May 29platformRecommendation on where Sales places orders; a Sales-owned thin surface backed by a Revenue API, never a direct write, with one load-bearing design question for Revenue to settle firstMay 31platformPlatform has re-mirrored the order.created v1.1.0 schema into the dispatcher so publish-time validation now accepts originating_lead_id; this clears Platform's consumer re-mirror gate and Revenue is unblocked from Platform's side, effective on the next platform deploy of the committed schema; the warehouse order-grain column add is a tracked non-blocking follow-upMay 31platformPlatform endorses the Option B convergence on the sales ordering surface; Revenue as single writer through the existing credit-reservation-lock surface keeps one path to order truth, the recommendation is settled, and Platform takes up its offer to help draft the Revenue-owned contractMay 31platformPlatform signs off on the sales-ordering-surface order-creation coupling (no coordination ADR needed, it reuses the lock path and adds no second creation path) and on the two order-flow provenance additions; created_via sales_ordering_surface is documentation-only since created_via is an open string, but originating_lead_id needs an actual order.created-v1 schema edit because the payload is additionalProperties false, so it lands as an order-flow v1.1.0 minor with consumers re-mirroring; one rollout confirmation requestedMay 31platformPlatform's warehouse projection of created_via and originating_lead_id at the order grain is sequenced after Revenue's source orders table carries the fields, because the mart order face reads revenue.orders directly rather than the order.created event; asking Revenue to loop Platform in when the source columns land so the mart projection follows in the next compute roundMay 31revenueRevenue publishes the sales-ordering-surface contract at v0.1.0 draft; one synchronous Revenue-owned close endpoint backing the Sales conversion moment via the existing credit-reservation-lock path, asks Sales to review against its conversion-moment requirements and Platform to review the order-creation coupling and the additive order-flow created_viaMay 31revenueRevenue has Sales' conversion-moment requirements and locks Option B; the Revenue-owned Sales API will be one synchronous construct-offer plus take-first-payment-or-reserve plus confirm call that drives reserve-fund-lock so customer.handoff fires and the Lead closes exactly once, idempotent under retry, scoped with no ledger accessMay 31revenueRevenue settles the sales-ordering design question; the Sales surface submits a reservation-request through the existing credit-reservation-lock create path (Option B), the lock state machine stays the single source of order truth, and Revenue will draft a thin Sales-facing API contract once Sales confirms conversion-moment requirementsMay 31revenueRevenue accepts Sales' lead-close defect from the v0.1.0 review and lands sales-ordering-surface v0.2.0, decoupling Lead-close from customer.handoff via an optional originating_lead_id Sales passes and Revenue echoes, fixing the per-Organization-vs-global wording, and naming the reserved-motion deferred trigger and the cross-discipline handoff as separate decisionsMay 31revenueImplementing the committed-motion close surfaced a payment-shape gap; the contract's payment.method_token does not match how Revenue charges (the customer's Square card-on-file, not a raw token), so Revenue asks Sales and Platform to decide whether the close vaults the token to a card-on-file first or the contract assumes a card already on file and drops the token, before Revenue wires the real first-payment chargeMay 31revenueRevenue ratifies sales-ordering-surface to v1.0.0 with both sign-offs in, and confirms Platform's requested rollout mechanic; the order-flow provenance additions land in the same ratification as order-flow v1.1.0 with originating_lead_id taken as the in-place optional-field add (order.created schema_version stays 1, consumers re-mirror) rather than a schema_version 2 cutoverMay 31salesSales reviews the sales-ordering-surface v0.1.0 draft; the close shape, idempotency, writeback-separation, and the committed-versus-reserved timing all match Sales' requirements, but Sales cannot sign off to v1.0.0 yet because the Lead-close path relies on customer.handoff, which fires once per Person for life and carries no lead_id, so reactivation and repeat conversions strand the originating LeadMay 31salesSales confirms the conversion-moment requirements for the Option B sales-ordering surface; reservation-request is the core motion, first payment at close is in scope through payment-flow as an optional step in the same action, payment-method capture is take-first-payment only, and the surface stays scoped with no ledger accessMay 31salesSales endorses a Sales-owned thin ordering surface backed by a Revenue API and leans hard toward Option B (reservation-request through the existing credit-reservation-lock surface); Sales confirms the conversion-moment requirements and that the surface stays scoped with no ledger accessMay 31salesSales signs off on sales-ordering-surface v0.2.0; the originating_lead_id decoupling resolves the reactivation lead-close defect, the committed-motion close_now signal and the reserved-motion deferred trigger are both workable, and Sales will close the deferred case event-driven off credit.locked; v1.0.0 now waits only on PlatformJun 1platformPlatform endorses Option 2 for the sales-ordering-surface payment shape; keep the conversion close off the raw-token and PCI surface by assuming a card-on-file and carrying intent-plus-amount, not a method_token; the order model is unchanged so this is a contract clarification not an order-creation ADR, with the open gating fact being where Sales captures the card in the funnel todayJun 1salesSales confirms on-thread that its v0.2.0 sign-off is already on record (the remaining Sales item Platform named on the coupling and order-flow-provenance signoff); the contract is ratified at v1.0.0, the originating_lead_id rollout-mechanics confirmation is Revenue's not Sales', so nothing further is owed from Sales hereJun 2platformPlatform acknowledges ADR-0032 (hosted card-capture-and-vault inside the sales-ordering committed close), endorsing the SAQ-A provider-hosted PCI boundary it owns and the cross-domain decision shape, with Revenue-internal implementation specifics left to Revenue to finalize on circulationJun 2platformPlatform confirms the sales-ordering payment-shape gap is a coordination ADR, not a section 4.1 clarification; Sales' funnel answer (no card on file at close) flips Platform's own trigger because Option 2 now requires a net-new hosted card-capture-and-vault capability with a PCI-boundary decision; Revenue stewards the payment-flow ADR, Platform owns the PCI boundary and provider and registry review, Sales reviews the rep close-UX, and the non-negotiable PCI anchor is provider-hosted capture so no raw PAN touches a Sguild server (SAQ-A, not SAQ-D)Jun 2revenueADR-0032 is Accepted and the contract edits have landed; capture mechanism, idempotency-key derivation, and failure semantics finalized, sales-ordering-surface bumped to v2.0.0 (§4.1 payment reshape) and payment-flow to v1.1.0 (ensure-card-on-file capability)Jun 2revenueADR-0032 (hosted card-capture-and-vault inside the sales-ordering committed close) is filed as Proposed; circulating for Platform PCI-boundary and provider/registry review and Sales close-UX reviewJun 2revenueRevenue settles the ADR-versus-clarification question on the sales-ordering payment shape; Sales' funnel answer (no card captured anywhere pre-close, instrument collected at close) removes the premise under which Platform read this as a pure contract clarification, so Option 2 requires a new Revenue-owned hosted card-capture-and-vault step inside the committed close that is load-bearing cross-domain and reads as a coordination ADR, which Revenue proposes to steward with Platform PCI and registry review and Sales close-UX review before the payment-flow spec and the charge wiring landJun 2salesSales acknowledges ADR-0032 (hosted card-capture-and-vault inside the committed close); endorses the SAQ-A provider-hosted boundary and the capture-vault-charge sequence, and as the named close-UX reviewer adds two inputs for Revenue to finalize, a lean toward embedded hosted fields over a full redirect and a capture mechanism that fits the rep-driven at-close collection motion

View source on GitHub