Stripe Test Mode Wiring Verification

Date: 2026-05-13 UTC Author: sre-agent Scope: Staging environment — TEST MODE ONLY T-minus: 10 days to v1 launch (2026-05-23 UTC) Related issues: #2020, #2021, #1682 (pre-launch-blocker)

Executive summary

The Stripe test-mode integration is NOT ready for end-to-end smoke testing on staging. Phase 1 (configuration verification) failed on every check. Phase 2 (smoke test) and Phase 3 inventory are blocked by Phase 1 gaps. Three structural gaps exist: (1) Stripe test keys are absent from vault staging environment and both staging Heroku apps, (2) Queue staging has no deployed application slug and an empty database, (3) the webhook handler (#1682) is not yet shipped. This is consistent with the pre-launch punch list (#2003) which marks Stripe billing as AT RISK / HIGH.

The billing path is a pre-launch-blocker. At current velocity (webhook handler unstarted, Queue staging undeployed, schema not applied), a full staging soak requires 4–6 dev-days plus ops setup time before the 2026-05-23 UTC deadline.

Phase 1 — Configuration verification

1.1 Vault paths — FAIL

Live vault audit run at 2026-05-13 20:06 UTC via scripts/vault/audit_coverage.py.

Stripe keys are present in the dev vault environment under /MooseQuest/stripe/. They are absent from the staging vault environment entirely. No /MooseQuest/stripe/ secrets exist in staging.

Key mode confirmation: all dev keys have sk_test_, pk_test_, rk_test_, and whsec_ prefixes. TEST MODE confirmed. No live keys found anywhere in vault.

Note: the architecture doc (stripe-customer-billing.md §7.6) names the var STRIPE_RESTRICTED_KEY, but the vault stores it as STRIPE_SECRET_KEY. Operator action required to confirm which name Queue/Raptor application code reads before setting Heroku config vars.

Vault path for the Raptor billing design: docs/architecture/stripe-customer-billing.md §7.6 specifies /Raxx/Raptor/Billing/Stripe/ for v1. This path does not exist in any vault environment. The keys at /MooseQuest/stripe/ are the actual location. These paths need reconciliation before the live transition.

1.2 Heroku config var wiring — FAIL

heroku config -a raxx-api-staging | grep -i stripe — no output (zero Stripe vars set).

heroku config -a raxx-queue-staging — only DATABASE_URL is set. Zero other config vars.

Neither STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, STRIPE_PUBLISHABLE_KEY, nor any Stripe-adjacent var is present on either staging Heroku app.

1.3 Webhook endpoint reachable — FAIL

Queue staging (raxx-queue-staging) has no deployed application slug. The app was provisioned on 2026-05-11 (Heroku release v4) but no container image has been built or released. Probe result:

curl https://raxx-queue-staging-403c1aa5941f.herokuapp.com/health
→ Heroku default "Welcome to your new app!" HTML (no queue-server running)

Raptor staging (raxx-api-staging) is running (health check returns {"status":"ok"}). However, Raptor does not have a Stripe webhook receiver — the webhook handler (POST /api/billing/webhook) is scoped to Queue per the v3 architectural decision (ADR-0071, ADR-0075). The existing Raptor billing routes (/api/billing/summary) are for the operator-facing vendor spend dashboard, not the customer Stripe webhook path.

Raptor staging probes returned {"error":"direct_origin_blocked"} — CF Access origin-guard is active, which is correct. These are not the target webhook endpoints.

1.4 Webhook secret match — CANNOT VERIFY

Stripe dashboard verification is not possible without a running webhook endpoint registered in Stripe. Since 1.3 failed (no running Queue staging instance, no registered webhook URL), this check is blocked.

Phase 2 — End-to-end smoke test

Status: BLOCKED

All Phase 2 scenarios are blocked by Phase 1 failures. Specific blockers:

No test data was created in Stripe dashboard. No cleanup required.

Phase 3 — Gap inventory

What IS shipped (Queue service layer)

Pre-launch-blocker assessment (9 days to 2026-05-23 UTC)

Critical path to minimal-viable billing soak

1. Operator — provision Stripe test keys to vault staging + Heroku staging (issue #2020). 30 min.
2. Operator — deploy Queue staging container (issue #2021 has commands). 2–4h.
3. Operator — apply sqitch billing schema to Queue staging DB (issue #2021). 30 min.
4. Feature-developer — implement #1682 (webhook handler + HMAC util). 2–3 days.
5. Operator — register staging webhook URL in Stripe dashboard, set STRIPE_WEBHOOK_SECRET from Stripe dashboard whsec_ value.
6. Sre-agent — re-run Phase 1 + Phase 2 verification after above complete.
7. 48h soak with FLAG_QUEUE_BILLING=true on staging before enabling on prod.

Earliest possible live-mode swap: 2026-05-21–22 UTC, assuming steps 1–4 start immediately and feature-developer begins #1682 today. This is zero-slack against the 2026-05-23 UTC launch gate.

Action items

Vault path discrepancy (escalation note)

The architecture doc (stripe-customer-billing.md §7.6) specifies secrets should live at: - /Raxx/Raptor/Billing/Stripe/STRIPE_RESTRICTED_KEY (v1) - /Raxx/Queue/Billing/Stripe/STRIPE_RESTRICTED_KEY (post-migration)

The actual vault path is /MooseQuest/stripe/STRIPE_SECRET_KEY. The var name also differs (STRIPE_RESTRICTED_KEY vs STRIPE_SECRET_KEY). Before the live-mode transition, the operator must confirm: 1. Which path does the running application code actually read from? 2. Which var name does the code read (STRIPE_RESTRICTED_KEY or STRIPE_SECRET_KEY)? 3. The restricted key (rk_test_...) is separate from the secret key (sk_test_...) — which one gates Raptor vs Queue?

This is a misconfiguration risk, not a live-key exposure. Documenting here for resolution before live transition.

References

• Architecture: docs/architecture/stripe-customer-billing.md
• Issues: #1682 (webhook handler — OPEN/blocked), #2020 (vault/Heroku config), #2021 (Queue staging deploy + schema)
• Pre-launch punch list: #2003
• Vault snapshot: docs/ops/2026-05-12-vault-coverage-snapshot.md
• ADR-0071, ADR-0073, ADR-0075 (billing architecture decisions)