cp10 standalone checkout engine

What the deliverable looks like today

This is the cp10 engine served standalone from its own directory (php -S + index.php, screenshot taken 2026-06-09). It returns HTTP 200 with the JS bundle baked in — proof of the REQ-572 live-route delivery and the guarded PHP includes.

1. Card payment block — Braintree hosted fields mount here once the engine boots on a real page. Behind this form sits the new explicit decline-code map (REQ-565/566) that replaced fragile substring matching, with every customer-facing error banner preserved verbatim.
2. PayPal option — its popup lifecycle is broadcast via the hardened, origin-scoped postMessage helper (REQ-567). A declined PayPal payment now reliably shows the PayPal banner instead of generic card advice (REQ-582).
3. Address-suggestion block, visibly un-hidden — normally hidden by script. It shows here because standalone serving has no page-provided jQuery, which is exactly the documented load precondition: the host page must supply window.jQuery ≥ 3.5. Expected in this context, not a bug.
4. Subscribe button — on success the engine writes window.newSubData / window.existingSubData, the contract the page's post-purchase hooks read.

All 17 cp10 REQs

How cp10 integrates — and where the isolation line is

The engine is not an iframe. The host page fetches the engine's HTML and injects it into its own document, so page and engine share one window. The robustness comes from where the boundary is drawn: nothing inside the engine directory reaches outside it, and nothing in cp8/cp9 can touch it.

Rollout path (everything reversible at every step)

flowchart LR
    A["Today: built, unit-tested,
e2e-proven — 14 REQs done"] --> B{"Your sign-off
first real customers"}
    B -->|go| C["REQ-573 A/B gate
small % of cp9-page traffic
+ PayPal live-capture check"]
    C --> D["REQ-574 Feroot
PCI monitoring"]
    C -->|proving succeeds| E["REQ-575 GA: cached
self-contained .html?v="]
    C -.instant rollback.-> R["cp9 engine URL"]
    E -.rollback.-> R
  

Limitations — what this does not give you yet

1. No customer has touched cp10. Until REQ-573 flips the A/B gate, zero production traffic flows to it. Verification so far is unit-level (135 tests) plus a live HTTP serve check — not a real purchase.
2. The e2e proof ran against mocked declines, not live ones. The card path tokenizes against the real Braintree sandbox, but the decline cases use the captured backend response shapes — the local Go service holds no merchant credentials and implements neither the card nor PayPal legs. Real decline bodies get confirmed during the A/B window (the live-capture checklist item below).
3. The PayPal-400 fix is built from captured response shapes, not live captures. The four hardening follow-ups (REQ-582–585) are all fixed and test-pinned, but REQ-582's decline-signal design rests on the source-derived backend shapes from the REQ-565 investigation. The pre-rollout checklist item: an operator live-captures real PayPal decline bodies during the A/B window and confirms PayPal-path declines report the PayPal banner in Subscription Error analytics.
4. The engine cannot run alone by design. It needs a host page providing jQuery ≥ 3.5 and the platform's serve-time PHP mounts. That couples cp10 to the page — never to the cp8/cp9 engines — and is documented as a load precondition, not hidden.
5. Until the cached GA artifact ships (REQ-575), a deploy filter that drops dist/bundle.js kills the engine. A precise console error surfaces it, but the real cure is the self-contained cached file.
6. Gateway-ID rotation is now an N-place edit. Vendoring the gateway constants is the accepted price of isolation (the keys are browser-public, so no new secret exposure).

How to get to a well-integrated, robust launch

The architecture work is done; what remains is sequencing. The recommended order:

1. Give the go for REQ-573 and open the A/B gate at a small percentage — the only remaining decision is yours; every dependency is met. Watch declines, PayPal completion, and analytics labels (cp10 3DS, version field). During this window, run the REQ-582 pre-rollout check: live-capture real PayPal decline bodies and confirm they report the PayPal banner. Rollback is one config change back to the cp9 URL.
2. REQ-574: add the page to Feroot monitoring during the proving window.
3. REQ-575: publish the cached versioned artifact and cut over. From then on, rollback is a previous ?v= — and the dist/ deploy trap is gone for good.

Verify it yourself

# Isolation gate — must print nothing
grep -rn "\.\./\.\./\.\./shared\|\.\./\.\./shared\|shared/common" \
  web/checkout-eet/p/static/checkout-eet-engine-cp10/src/

# cp8/cp9 engines untouched — must print nothing
git -C web/checkout-eet diff --stat -- \
  p/static/checkout-eet-digital-inline-form p/static/checkout-eet-digital-inline-form-cp9

# Independent build + unit suite (135 tests)
cd web/checkout-eet/p/static/checkout-eet-engine-cp10
npm run build && npm run test:unit

# The load-contract e2e (4 tests; auto-starts PHP on :8100, needs network)
npm run test:e2e

# Serve the engine standalone (what the screenshot shows)
php -S localhost:8123   # then open http://localhost:8123/index.php

# Trace any REQ to its commit
git show ec3ff728   # REQ-564 scaffold; see the table for the other twelve SHAs