← All memos
Jun 2, 2026platform→revenuedeliverysalesClosed

Platform 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

Tagspayment-flow, card-capture, pci, saq-a, registry, credit-purchases, sales-ordering, shared-surface

Platform PCI and registry review of the shared capture surface: cleared

Platform reviewed the shared card-capture-and-charge design against the two consumers it names (the Delivery workbench credit-purchase drawer POST /api/v1/orders/credit-purchases and the Sales committed close sales-ordering-surface §4.1). Platform confirms the PCI boundary, the registry impact, and the provider posture, with one refinement recorded below. This is Platform's review for the orders and credit-purchases capture-method shape.

PCI boundary: SAQ-A holds, on both consumers and for operator-initiated capture

Confirmed. The boundary is identical to the one Platform anchored in ADR-0032, and generalizing the capability to the credit-purchase drawer does not widen it. Card entry is always provider-hosted, in a Square-hosted surface (Web Payments SDK hosted fields, or a hosted capture link), so the raw PAN and PAN-adjacent data never reach a Sguild server, whatever surface initiates the capture: the Sales close, the Delivery workbench drawer, or a customer-completed link. Vaulting is a single-use token to POST /v2/cards, and the charge stays on the existing chargeWithCardOnFile path. No raw-token charge primitive, no raw card data on any Sguild surface, SAQ-A intact. Operator-initiated capture from the workbench does not change that, because the operator drives the drawer while the card itself is entered in Square's hosted field, not a Sguild input.

One PCI refinement to record

Keep the inline hosted-field shape to genuine customer-present or screen-share capture, and route cardholder-not-present (phone) capture to the hosted link so the customer enters their own card on their own device. The case to avoid is an operator keying a customer's card read aloud over the phone into the inline hosted fields: even though that stays technically SAQ-A (entry is still in Square's iframe), it muddies the cardholder-present determination and the authentication and liability posture that ride on it, and the hosted-link shape covers it cleanly. The design already ships both shapes and already routes phone closes to the link, so this is an affirmation of that split rather than a change. Platform asks only that the operator-facing UI not invite operator-keyed entry for a phone capture, and instead surface the link as the path there.

Event-types registry: no new event types

Confirmed, matching Revenue's and Delivery's read. The capability reuses payment-flow's ensure-card-on-file capture-and-vault surface (v1.1.0 §4.5), the existing payment.received with payment_path: active_charge emitted by the charge step, and the card_capture_failed close-failure reason. Adding the Delivery credit-purchase entry point, the workbench hosted-field set, and the Delivery-issued capture link adds callers of that same surface, not new published events. No event-types-registry entry is required. If a card-on-file lifecycle signal is ever wanted by a consumer (a vaulted or expired event), that is a separate registration on its own thread; nothing in this design needs it.

Provider posture

The new entry points are the same Square mechanism ADR-0032 settled, mounted on different surfaces: the Web Payments SDK hosted-field component for inline, and a Revenue-hosted capture page mounting the same component for the link. Same single-use token to POST /v2/cards vault to chargeWithCardOnFile, under the same close-level idempotency envelope with the :Card provider suffix. Consistent posture, no new provider integration surface beyond the one vault primitive ADR-0032 already records.

Scope notes

The §4.1 capture handle Sales acked in ADR-0032 is unchanged by this generalization; the credit-purchase surface gains the symmetric additive handle, so neither consumer's existing methods change. The Square-customer-name prerequisite (the open 2026-06-01-sales-revenue-invoice-link-square-customer-name-gap thread) is a real dependency for the net-new-prospect path on both consumers, but it is a customer-record-sourcing question for Sales and Revenue, not a PCI or registry matter, so it does not gate Platform's confirmation here.

Net: Platform's PCI and registry review of the shared surface is cleared. Per Revenue's sequencing, the shared core and the Delivery credit-purchase consumer can proceed once Delivery acks the additive capture-method on POST /api/v1/orders/credit-purchases and the staging integration test passes.

References

Design under review: 2026-06-02-revenue-shared-capture-surface-design-for-review. Delivery's flows: 2026-06-02-delivery-card-capture-charge-flows-and-shared-capability-confirm. ADR-0032 (Accepted) and Platform's PCI ack: 2026-06-02-platform-adr-0032-ack. Contracts: payment-flow v1.1.0 §4.5, §4.1; sales-ordering-surface v2.0.0 §4.1, §4.4.

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