Intranet
Strategy & decisions

Cart/Checkout Integration Addendum (v2 deltas — adopt per item)

The new unified cart/checkout plan (htmlink.agend.info/u/26b203.html, reviewed 2026-07-08) intersects four committed docs. The originals are deliberately untouched — each delta below is independently adoptable; fold a delta into its target doc only when that direction is confirmed. Rejecting one delta does not invalidate the others. Status: PROPOSED · 2026-07-08

What the cart plan establishes (source facts)

  • Scope: event tickets, courses, memberships, generic products, corporate seats. "WordPress, the portal, Learn and Events are entry points into that path, never parallel payment systems."
  • WooCommerce: "not recommended for new builds"; existing receiver is "a legacy bridge for clients mid-migration". WP buy buttons deep-link into portal checkout via SSO (portal-cart / portal-checkout registry keys).
  • Ledger: crm_cart/crm_cart_items → checkout provider → crm_orders + items as the single source of truth; one gateway driver layer (@agend/payments: Stripe Connect + eWay), one signature-verified idempotent webhook.
  • Pricing: server-side product resolvers from live membership status; "no price, no amount and no member identity travel in the link."
  • Out of scope: recurring subscriptions (stays token-charge renewal sweep), guest checkout, shipping/postage. Blocking gap: the production checkout provider (only no-op/test exist). Five phases; Phase 2 = WordPress entry links + SSO.

Delta 1 → WP integration plugin spec (wordpress-integration-plugin-spec.md)

Change: commerce is removed from the plugin's problem space entirely. Buy buttons render on WP and deep-link into portal checkout via SSO — no cart UI, no gateway touch, no order state on WordPress. Add a requirement R8 (buy-button component using the SSO shareable-link registry) and note that cart plan Phase 2 and BOA-08 are one workstream — build them together, not twice.

If not adopted: the spec stands as written; buy-buttons ship later as a widget-library addition.

Delta 2 → bridge map Oracle class (upbeat-data-bridge-map.md §1)

Change: the Oracle's implementation home is now concrete — a upbeat-pricing product resolver inside the cart's resolver layer, performing the draft-invoice quote for bridged clients only. Migrated/native clients price hub-natively; for them the oracle does not exist. The class stays in the map; this names its one call site.

If not adopted: the Oracle class remains implementation-agnostic (no harm).

Delta 3 → write-back design (writeback-two-way-sync.md §5.4 / W2)

Change: the cart supplies the charging front half (order composed, priced, charged, landed in crm_orders); W2's outbox becomes the recording back half for bridged clients only — a settled crm_orders row propagates to Upbeat as the invoice/payment group. W2's trigger shifts from "WooCommerce order events" to "crm_orders settled events" — a cleaner seam than the doc assumed.

If not adopted: W2 proceeds against the legacy WooCommerce flow as originally sketched (workable, worse).

Delta 4 → legacy AMS parity map (legacy-ams-parity-map.md)

Change: the commerce row's exit path is now named: portal checkout replaces WooCommerce checkout for one-off purchases (events, courses, memberships, seats). Carry-forwards that keep the row honest: subscriptions stay on the renewal sweep (WC Subscriptions dunning parity still owed to the billing engine), purchase orders and postage/shipping are not in the cart plan and remain open parity items before "away with WooCommerce altogether" is literally true.

If not adopted: parity map's commerce row stays "lossy — pending billing engine" with no named mechanism.

Findings for the cart team (actionable regardless of deltas)

  1. No Upbeat awareness in the plan. Bridged clients need a pricing resolver that makes an external synchronous call (draft-invoice quote) and a settled-order hook for Upbeat recording. Flag before Phase 1 locks the checkout-provider interface — resolver contracts must permit an async external call with timeout/fallback semantics.
  2. Purchase orders (corporate checkout, live in legacy AMS) absent from the gateway list — defer knowingly, not accidentally.
  3. Shipping/postage absent — blocks physical-goods clients from full WooCommerce exit.
  4. Guest checkout contradiction: cart requires portal auth; the Events API ships allow_guest_event_checkout. One decision needed before Phase 3 consolidates the paths.
  5. eWay's webhook-less fulfilment (return-query + reconciliation poll) is the same fragility class the upbeat-async work fixed once — resource the reconciliation poll properly.

Net effect on the programme (if all deltas adopt)

WooCommerce leaves Agend Pro for everything except recurring subscriptions (interim), POs and postage (open gaps). The thin WP plugin gets thinner; W2 gets a cleaner trigger; the Oracle gets a named home; the parity map's billing dependency gets a concrete engine. Pathway page v2 (one-agend-pro-pathway-v2.html) carries the corresponding narrative updates; v1 remains as previously circulated.