Stripe go live workflow

Stripe go-live workflow

A working test-mode Stripe integration is not a working live-mode Stripe integration. The API calls are the same; the operational sequence around them is different. This skill is the playbook for the second half.

For the API design half (Checkout Sessions vs PaymentIntents, dynamic payment methods, RAK permissions, webhook signature verification, deprecation migrations), load stripe-best-practices. This skill assumes the integration is already designed correctly and needs to ship.

The single safety rule

The agent must never see, paste, log, or store the live Stripe key. The user types it directly into wrangler secret put (or equivalent) from their own machine.

Concretely:

• The agent never accepts an rk_live_… or sk_live_… value in chat, even if the user offers.
• The agent's .env, shell history, log output, and tool transcripts must not contain live keys.
• If the user accidentally pastes one, the agent must (a) refuse to store it, (b) tell the user to roll the key immediately in the Stripe Dashboard, and (c) not echo the value back.

The Worker itself should have a runtime guard: refuse to start if the key prefix does not match a configured live-mode flag (Offline Helper's keyMatchesLiveFlag pattern is the model: a live key with the flag off, or a test key with the flag on, both refuse to start with a clear 412 error).

Sequenced workflow

Phase 0: The hidden blocker — assume nothing, audit first

The skill's default mental model is greenfield go-live: Worker not yet deployed, key not yet pushed, webhooks not yet wired. That is often wrong. A common case — and the one this skill must handle well — is the integration was set live in a prior session, the user has come back months later, and the catalog and Operator-agent data file may have drifted apart while the Worker kept running. The two failure modes:

• Worker is already live (/api/health returns live_approved: true), secrets are already pushed, the "go live" work was done before. In that case, the right action is audit + verify, not rebuild.
• Worker is not yet live (live_approved: false or flag missing entirely), the Operator-agent data file has different live price_… IDs than the Worker's CATALOG constant, the user is in the wrong Stripe mode, or some mix. In that case the work below is the real Phase 0.

A pre-flight audit is fast and saves the entire conversation from going down the wrong path. The recipe lives in references/live-state-audit.md; the short form is:

# 1. What mode is the Worker actually in?
curl -s --max-time 5 https://<worker-url>/api/health
# or use the browser tool if curl hangs (see pitfall below).
# Look for: "live_approved": true | false

# 2. What does the Worker think the catalog is? (compare to Operator data file)
grep -E "price_" /path/to/worker/src/index.js    # Worker's CATALOG
grep -E "price_" /path/to/data/products.json     # Operator data file
# These MUST agree on the live price_… IDs. If they don't, you have catalog
# drift and the user has to decide which one is canonical before pushing.

# 3. Are the policy pages live on the domain? (real URLs, not example.com)
for p in /terms/ /privacy/ /refund-policy/; do
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 5 "https://${DOMAIN}${p}")
  echo "  https://${DOMAIN}${p} -> HTTP $code"  # all three must return 200
done

If the audit shows the Worker is already live and the catalog is consistent, skip Phase 1–5 and go straight to Phase 6 (real-card test charge) and Phase 7 (verify the charge lands in Live mode in the Dashboard). The session-level rule: never re-litigate a deploy the user has already paid for; verify it.

Phase 0a: The hidden blocker — policy pages

Before the user can complete Stripe's Live-mode onboarding form, they need three real URLs on their own domain:

• Terms of Service
• Privacy Policy
• Refund Policy

The Stripe form defaults these to https://example.com/.... Saving those placeholders is technically allowed but creates real legal exposure: every Checkout receipt and confirmation email will link to a generic Stripe docs page, and there will be no real privacy policy at all. Multiple US states (CA, VA, CO, CT, UT, …) require a real, accessible privacy policy before a business can collect payment data.

Do this before the user starts the Dashboard walkthrough. Hand them three freshly-shipped URLs on their domain and have them paste those into the Stripe form. See ai-visibility-for-small-sites/references/policy-page-templates.md for the templates and the ~90 minute build.

Verify on the live site before the user pastes into Stripe:

for p in /terms/ /privacy/ /refund-policy/; do
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 5 \
    "https://example.com${p}")
  echo "  https://example.com${p} -> HTTP $code"
done
# all three must return 200

Phase 0.5: Pricing-table alternative to a custom Worker

Stripe has a no-code stripe-pricing-table component (<stripe-pricing-table pricing-table-id="prctbl_…" publishable-key="pk_…">) that lets the user list their three products on a static page with a Stripe-hosted checkout, with zero backend code. If the user pastes one of these snippets into chat, they have already built the storefront in the Dashboard.

Three options. Always ask which they want before continuing:

Option	Worker role	Trade-off
(a) Pricing table only, kill the Worker	None	Simplest. Loses fit-check metadata, Telegram-bot routing, KV fulfillment queue.
(b) Pricing table for marketing, Worker for confirmed-fit buyers	Captures fit_check_id + setup_window metadata, routes through to fulfillment queue	Preserves the funnel you designed. Slightly more code to maintain.
(c) Pricing table for v1, retire the Worker, re-introduce custom checkout later	None for now	Cheapest v1. Fastest to learn from real data.

Option (b) is the right answer for most solo-founder service businesses — pricing tables for cold traffic, custom checkout for buyers the founder has already qualified.

If the user goes with (a) or (c), the Worker code can be archived, not deleted — leave a one-line note in the repo README explaining when to revive it.

Phase 1: Confirm test mode is genuinely clean

Run a 4242 4242 4242 4242 test card through the full path. Verify every step before flipping to live:

• Checkout Session creation returns a url.
• Browser redirect (303) lands on Stripe's hosted Checkout.
• Webhook endpoint receives checkout.session.completed and HMAC signature verification passes.
• Fulfillment record is written to the Worker datastore (KV, D1, Postgres, etc.).
• Success URL renders the right page on the user's domain.
• Cancel URL renders the right page on the user's domain.
• /api/health returns the expected catalog and live_approved: false.

If any step is broken in test, do not flip live. Fix the test path first. The live path will have the same bugs plus a real bank and a real customer.

Phase 2: User-only steps in Stripe Dashboard

Five things only the human operator can do. Be explicit about the division of labor:

Step	Who	Notes
Switch toggle to Live mode	Human	Agent cannot do this.
Complete Branding + connect bank/payouts	Human	Required for live settlement. Bank verification is usually 1–2 business days.
Replicate products + prices in Live	Human	Prices have separate IDs in test vs live. The user copies the new price_… IDs and pastes them back to the agent.
Create Restricted API Key (Live)	Human	Name it after the integration (e.g. offline-helper-payments-live). Resources: minimum needed — usually Checkout Sessions: write + read and Webhooks: read. Copy the rk_live_… value into the user's password manager. Never paste it in chat.
Create webhook endpoint in Live	Human	Use the new Worker URL (or existing one if not renamed). Events: checkout.session.completed, checkout.session.async_payment_succeeded. Copy the new whsec_… signing secret. Same secret-isolation rule.

Phase 3: Agent's "bump on go-live" audit

While the user is in the Dashboard, audit the Worker for go-live correctness:

• Stripe API version. Update Stripe-Version header to the current latest. Older versions may not support current payment method types, fraud signals, or Checkout features.
• No payment_method_types in any API call. Walk every Checkout Session / PaymentIntent / SetupIntent / Subscription creation site. Omit the parameter entirely; let Stripe pick dynamically. Only exception: Terminal (payment_method_types: ['card_present']).
• No automatic_payment_methods on Checkout Sessions. Stripe returns 400 parameter_unknown for it. Dynamic payment methods are the default for Checkout and require no parameter. automatic_payment_methods: { enabled: true } is only valid on PaymentIntents.create / SetupIntents.create on API version 2023-08-16+. If you copy-pasted a PaymentIntent snippet into your Checkout flow, the same call will 400 in production. The fix is to delete the line; do not "set it to null" or "set it to false" — Stripe still rejects unknown keys. See references/headless-cloudflare-deploy.md for the Stripe request-log URL pattern that surfaces the exact failing parameter.
• No deprecated Charges or Sources API calls. Migrate to Checkout Sessions / PaymentIntents / Setup Intents.
• Webhook signature verification present and correct. HMAC with the raw request body, constant-time compare. Never trust the event payload without verifying.
• All secrets in platform secret store, not in source code. wrangler secret put for Cloudflare. Env vars set in the platform dashboard for Vercel / Netlify / Heroku. Never in .env committed to the repo, never hardcoded.
• Catalog price_… IDs updated to live values. Do not assume the test IDs will work in live (they will not). User pastes the live IDs; agent edits the Worker's CATALOG.

Phase 4: User pushes the secrets

From the user's own machine (not the agent's VPS), the user types:

# 1. Push the live RAK. User pastes rk_live_… directly.
read -rs RAK_LIVE
echo "$RAK_LIVE" | npx wrangler secret put STRIPE_SECRET_KEY
unset RAK_LIVE

# 2. Push the webhook signing secret.
read -rs WH_SECRET
echo "$WH_SECRET" | npx wrangler secret put STRIPE_WEBHOOK_SECRET
unset WH_SECRET

read -rs reads without echo; the variable is unset immediately after, so it does not linger in shell history or environment. Wrangler writes the value directly to Cloudflare's encrypted secret store. The agent never sees the value.

Phase 5: Provision resources + deploy

From the Worker directory (on the user's machine, with their authenticated wrangler session, or via the agent's CLOUDFLARE_API_TOKEN pattern if running on a headless VPS):

# 1. Provision the KV namespace if not already done.
npx wrangler kv namespace create OFFLINE_HELPER_QUEUE
# Paste the returned id into wrangler.toml [[kv_namespaces]] block.

# 2. Flip the live flag in wrangler.toml.
sed -i 's/STRIPE_LIVE_APPROVED = "0"/STRIPE_LIVE_APPROVED = "1"/' wrangler.toml

# 3. Deploy.
npx wrangler deploy

Phase 6: Verify the live Worker is actually live

This is the gate. Local validation, screenshots, and "I ran wrangler deploy" are not the same as "it's live."

• curl -I https://<worker-url>/api/health returns 200.
• /api/health JSON contains "live_approved": true.
• Run one real-card test charge at the smallest available amount. This proves end-to-end: key works, bank accepts, webhook fires, KV record writes, success page renders.
• Refund the test charge immediately if it was a non-real product.
• Confirm the charge appears in Stripe Dashboard → Live mode → Payments. (Not Test mode — a common mix-up.)
• Fast check for which mode a Checkout Session opened in: the URL's cs_live_… prefix (vs cs_test_…) and the browser tab title (set to the business name from Dashboard Branding on a live session, with no "Test mode" banner). This is faster than asking the user to re-check the Dashboard toggle.

Phase 7: Then and only then, report "live."

Same discipline as ai-visibility-for-small-sites: "built and ready to ship" is not the same as "live." The user will check.

Pitfalls specific to go-live

• Same Worker code, but different price IDs. Test and live prices have separate price_… IDs. Updating CATALOG is mandatory.

• The <stripe-pricing-table> prctbl_… ID is not a price_… ID. The pricing-table ID is a container that groups multiple products; it works in the embedded <stripe-pricing-table> element on a static page but is rejected by the Worker's line_items[].price field. The Worker (and any custom Checkout integration) needs each product's individual price_… ID, not the container. If the user pastes a prctbl_… ID and the Worker is wired to it, every checkout returns 404 from Stripe. Same shape applies to CSV product imports, which return a v2.commerce.product_catalog_import object with status: "awaiting_upload" — useful internally to Stripe, not an artifact the integration consumes. Always ask for the individual price_… IDs when you need them, and verify the price_… IDs the integration uses by re-fetching the deployed bundle (GET /accounts/<id>/workers/scripts/<name> from the Cloudflare API returns the raw source) before declaring the catalog wired.

• Webhook endpoint URL changes when the Worker redeploys. If the Worker is renamed, moved, or its account_id changes, update the webhook endpoint URL in Dashboard or events will silently 404.

• Old test webhook still firing. Either delete the test webhook in Dashboard after the test dry run, or accept that you'll see duplicate test events during the transition.

• Bank account not yet verified. Stripe lets you create charges before bank verification, but payouts are held (usually 1–2 business days for micro-deposits). Warn the user.

• Tax settings. If the user is selling in multiple states or countries, Stripe Tax + Registrations API is mandatory. For a US-only small service business, the default is usually fine, but flag it.

• Statement descriptor. Set in Branding settings. Appears on the customer's card statement. Default is the business name, shortened to 22 chars. Tell the user about it; do not silently leave the default.

• Mixing test and live modes. Mode toggle is in the top-left of Dashboard. Easy to miss. Always confirm "this is Live mode" before creating the RAK or webhook.

• Policy pages still at https://example.com/.... If the user has been sitting on the Dashboard form for more than a day, re-check that they have not saved the example.com placeholders. Pasting real https://offlinehelpers.com/... URLs into the form requires the pages to be live on the user's domain first. See Phase 0.

• Catalog drift between Operator data file and Worker CATALOG. The operator-agent pattern stores the live catalog in a JSON data file (e.g. data/offline-helper-products.json) and the Worker stores the same catalog as a JS const CATALOG = { … } in src/index.js. The two must agree on the live price_… IDs at all times. A common failure mode: a prior session updated the data file (after recreating a live price in the Dashboard) but the Worker was not redeployed, or vice versa. Symptom: --check and --plan print one set of price IDs, curl /api/health and the live Checkout Session use a different set. The two must reconcile before any live test charge. Run the static comparison (Phase 0 above) and ask the user which one is canonical. The fix is mechanical: edit the stale side to match, then redeploy. Do not let the discrepancy ride into a real-card test or the audit trail will not match what the customer was charged.

• Confusing "ready to ship" with "live." The same deployment-discipline failure as ai-visibility-for-small-sites: you update the Worker's CATALOG, commit locally, and tell the user "Worker updated." They ask "is it deployed and live?" and you realize nothing has been pushed, the Worker is not running the new code, and the live-mode test charge will fail. The fix is mechanical: after every Worker edit during a go-live flow, run the full ship sequence — git add, git commit, git push, then npx wrangler deploy (or confirm the user runs it on their machine) — before reporting progress. Local file edits and a clean git status are not the same as "the Worker is running this code in production." The "committed and live?" question from the user is a cue to verify, not to re-claim progress. Re-curl the live Worker URL, re-check the deployed cat against the local source, re-confirm the catalog price IDs are the live ones, then answer.

• Stale account_id in wrangler.toml. If the config was copied from a different Cloudflare account, or the account was re-created, wrangler whoami succeeds (uses the token's default account) but wrangler deploy errors with account_id … does not match any of your authenticated accounts and a 10000 auth code. Fix: run npx wrangler whoami, paste the Account ID into wrangler.toml's account_id = "…" line, or remove the line entirely. Verify with wrangler deploy --dry-run before any --live push. See references/headless-cloudflare-deploy.md for the full headless-VPS pattern (~/.cloudflare_token, deploy.sh, set-secrets.sh).

• CLOUDFLARE_API_TOKEN does not persist across shells. Setting export CLOUDFLARE_API_TOKEN=… in one shell, then running wrangler from a different shell (e.g., a fresh terminal, a backgrounded process, a cron-style command), silently loses the variable. Either run all wrangler commands from the same shell, or stash the token in ~/.cloudflare_token (chmod 600) and load it via a one-line export at the top of every deploy script. The template scripts in templates/deploy.sh and templates/set-secrets.sh already do this.

• Strict LIVE_APPROVED gate blocks the test dry run. A Worker that hard-rejects (HTTP 412) when the Stripe key prefix mismatches the LIVE_APPROVED flag is safer in theory but makes the test-mode dry run impossible: you cannot load a live rk_live_… key with the flag off to test the live catalog, and you cannot load a test key with the flag on to test the production path. The two-step dry run (test-key-then-swap) is the textbook answer but doubles the key-swap dance. The pragmatic middle ground: relax the gate to a console.warn for the live_approved=0 + live key combination (still production-safe because the flag still controls real charges), and keep the hard reject for the impossible live_approved=1 + test key combination. Document the relaxation in the code so a future maintainer does not reintroduce the strict gate and re-block testing.

• Browser automation cannot reliably fill the Stripe Payment Element form during the dry run. The form is React-controlled with hidden iframes for the card field. browser_type + browser_click of "Pay with card" works for card number / expiry / CVC, but JS-injected values for ZIP and phone number get cleared on the blur event the browser tools emit, leaving the form in the "incomplete" state. Spend at most 5 minutes on automation before handing the Checkout URL to the human user to complete in their own browser, or fall back to a real $0.50 charge with refund. See references/stripe-checkout-automation.md for the full failure modes.

• Cloudflare's workers.dev subdomain doubles up if the script name is the only Worker in the account. When wrangler deploy is the first deploy in an account, the account-level workers.dev subdomain gets auto-set to the script name. The published URL is then https://<script-name>.<script-name>.workers.dev (e.g. offline-helper-payments.offline-helper-payments.workers.dev). Three ways to handle it: accept the doubled URL as-is (it works, just long), set a shorter account subdomain via the API (PUT /accounts/<id>/workers/subdomain with {"subdomain": "pdbjork"}), or route a custom domain instead. Verify the chosen URL responds 200 from a browser, not just curl — some VPS curl builds fail TLS handshakes to doubled-prefix hostnames even when the browser gets through cleanly, which is a local cert / SNI issue, not a real outage. **Right reflex when curl https://<doubled>.workers.dev/api/health hangs from a VPS: open the URL in the browser tool (browser_navigate

  • browser_snapshot) and read the JSON body from the accessibility tree. A 30-second hang in curl is not a Worker problem; it is the doubled-prefix SNI issue and the Worker is almost certainly fine.**

• wrangler 4.99 (and later) prompts to install Cloudflare skills for detected AI agents. The first time a user runs npx wrangler deploy on a new machine, wrangler scans for gemini-cli, antigravity, hermes-agent and offers to install Cloudflare's cloudflare/workers skill pack. This is interactive — a non-TTY context (backgrounded process, nohup, cron) will block. Either pre-install the skills via npx skills add cloudflare/skills, or run wrangler from a real TTY once to dismiss the prompt before any non-interactive deploys.

• read -rs returns empty and you write a 1-byte token file. If the paste to read -rs CLOUDFLARE_API_TOKEN captures only a trailing newline (common in some terminal emulators), the subsequent echo > ~/.cloudflare_token writes a single newline, wc -c prints 1, and wrangler fails with a confusing auth error later. Always verify wc -c ~/.cloudflare_token shows 40+ (Cloudflare tokens are 40 chars) immediately after the read -rs block, before any wrangler command.

• The agent's tool chain can rewrite $(cat …) in shell scripts. If the script you intend to write contains a command-substitution token, the file on disk may end up with the $() stripped and a stray ) left over, producing a bash syntax error. Symptom: bash -n the script → syntax error near unexpected token ')' on the line that looks correct in the source. The fix is mechanical: use bash input redirection instead of command substitution (read -r VAR < file plus a separate export VAR), which has no $() to filter. This is the right default for any token-loading helper script that may be authored or re-saved through an agent tool chain.

• Workers that depend on a paid LLM will 500 the day the account runs out of quota. A 429 insufficient_quota from OpenAI / Anthropic is not a key-push problem — it is a billing problem on the LLM account. Common with brand-new accounts whose free credits expired, or accounts with no payment method on file. The Stripe payment path is independent of the LLM billing path, so the rest of the live integration (Checkout Session creation, webhook → KV, fulfillment) can be fully live while the chat funnel is dead. Build the form-fallback before the chat. A 5-field static form that POSTs to the same complete endpoint preserves the fit_check_id round-trip and the Stripe metadata chain with no LLM call. See references/ai-fit-check-chat.md for the full pattern and the "form is load-bearing, chat is polish" framing.

• The "two-machine problem" — assuming the user means the wrong shell. When the project lives on both the user's laptop and the agent's VPS (or two agents, or a CI runner and a dev box), and the user says "you do it" or "push the key" or "deploy it," the agent has to pick a machine. Wrong default: assume the user's laptop. Right default: assume the machine the agent has been working on, which is usually the VPS, and state the machine out loud and confirm before running. The cost of getting this wrong is a secret bound to the wrong Worker, a 500 the user can't diagnose, and 10 minutes of "I pushed it but it's not working" debugging. The reflex is the same as the "committed and live?" pitfall: verify, don't assume.

• "I need money" / "verify the live Stripe pipes" is NOT a go-live request. When the user says that, the default action is not to rebuild or flip modes — it's to prove the existing live plumbing works end-to-end. This is the Express-served verify-the- pipes ritual (or Phase 6 + Phase 7 of this skill for Workers): start the existing server, hit /api/health, fire real cs_live_… checkout sessions, cross-verify each with Stripe REST (livemode=True), expire any orphan sessions left by prior runs, kill the servers. Six steps, ~3 minutes. See references/express-live-smoke-test.md for the full ritual and scripts/live-smoke-test.sh for the one-shot executable. The Worker equivalent is wrangler tail + a real-card charge. Always run the orphan-cleanup loop at the end. Smoke sessions accumulate in the Stripe Dashboard's open-sessions view across runs that never cleaned up; a single unrun cleanup over months can produce 10+ orphan sessions that look like abandoned carts and skew the "recent activity" view. Treating the smoke test as just "fire some sessions" without the cleanup is the same shape of failure as treating "go live" as just "flip the toggle."

• The "live" may already be live — audit before you build. When the user says "ship Offline Helper payments live" or "Phase 1: Stripe live," the default assumption is "build it from test mode to live mode." That is the wrong default. The previous session (or a prior workflow) may have already pushed the live key, set STRIPE_LIVE_APPROVED = "1", and deployed. The very first thing the agent should do is verify the current state before any "go live" planning:

  1. curl -sS https://<worker-url>/api/health from a browser (VPS curl often fails TLS on doubled workers.dev subdomains) and read the live_approved field. If it's true, the Worker is already in live mode.
  2. Read the Worker's wrangler.toml to confirm STRIPE_LIVE_APPROVED and the [[kv_namespaces]] binding.
  3. Read the Worker's CATALOG and the operator agent's data/*.json and reconcile price IDs. A divergence between the two is the canonical "deployed but stale" tell. The Worker is what buyers see; the data file is what the operator script will reach for if you run --apply. They must match.
  4. Confirm policy pages are 200 on the user's domain (/terms/, /privacy/, /refund-policy/).
  5. Confirm the live webhook endpoint is wired in the Dashboard (ask the user — this is user-only).

  Only then should you and the user talk about what's actually left: a real-card end-to-end test, a refund, the catalog reconciliation, or — if everything checks out — "Phase 1 is done, you are live, here is your $0.50 refund receipt." The build-from-scratch plan is the contingency, not the default. Defaulting to it is the same "committed and live?" reflex in reverse: you assume work that doesn't need doing and create work for the user that may not be necessary.

• "The doc says X" is not "the live site does X." Generalize the audit reflex beyond deploy state. The previous pitfall covers Worker/server deploy state. The closer pattern that bites even when the integration is greenfield: a brief, design doc, yesterday's YOLO summary, or a prior session's hand-off states a fact about the product surface (not the deploy state), and the agent treats that fact as ground truth. Examples observed in 2026-07-05 Offline Helper work:

  • "The landing page has no payments" — true on the intent layer, false on the deploy layer: the Worker with full Stripe Catalog existed in the repo but had never been deployed; the confirmed-fit-payment page referenced a doubled-subdomain Worker URL that would 404 even after deploy. The doc was describing the intent, not the deployed reality.
  • A new navigation link on index.html to a page that exists locally but isn't on origin's main yet → 404 on the live site. Local repo state ≠ GitHub Pages state.
  • "The Capture endpoint returns 500 with body X" stated in a brief → the live endpoint returns 200 with body Y because a different upstream worker has been swapped in. Briefs are snapshots of intent, not live state.

  Right reflex before designing against any doc premise about product behavior: for each stated fact, run a 30-second live probe and cite the response in your plan. The minimum probe set for "Stripe on landing" / "checkout on marketing page" requests is:

  • Worker URL or server port reachable? curl -s --max-time 5 <url>/api/health from the VPS, or browser_navigate + browser_snapshot to read JSON. Read both live_approved and the catalog id list.
  • Hardcoded Stripe URLs in the live HTML actually point to a deployed Worker? curl -s https://<domain>/<page>.html | grep -Eo 'https?://[^\"'"'"' ]*' | grep -i 'stripe\|workers.dev'. (A doubled-subdomain URL is a deploy signal even if curl returns 200; the URL is the wrong URL.)
  • Pages referenced by nav actually 200? for p in /nav-page-a /nav-page-b; do curl -s -o /dev/null -w "%{http_code} $p\n" https://<domain>$p; done.
  • Endpoints cited in the brief — /api/stats, /api/interest, etc. — match the endpoints the live page actually calls? grep -Eo 'api/[a-z_-]+' index.html and compare.

  The docs describe what should be true; the live site describes what is. When they disagree, the work is to converge them — not to assume the doc is right. "I shipped the deploy the brief described" against a doc that didn't match live state creates a parallel checkout path next to the existing-but-broken one. Probing first costs 30–120 seconds; rebuilding on a wrong premise costs an entire session.

Signals that should trigger this skill

• Greenfield go-live: "Go live," "launch payments," "flip to live," "we're ready for real cards," "real money now," "production time," or similar.
• Already-live verification: "I need money," "verify the live Stripe pipes," "smoke test the checkout," "show me money," or any request to prove an existing Express/Worker Stripe integration is healthy end-to-end. Use the Express ritual in references/express-live-smoke-test.md (or the Worker Phase 6
  • Phase 7 path) for this branch.
• A working test-mode Stripe integration that needs to ship.
• Questions about RAKs, restricted API keys, rk_live_, the difference between test and live prices, or webhook signature verification in production.

Signals that should NOT trigger this skill

• "How do I use Checkout vs PaymentIntents?" → stripe-best-practices
• "Is my Worker code PCI-compliant?" → stripe-best-practices
• "Should I use Subscriptions or one-time charges?" → stripe-best-practices
• Pure code review with no production-deploy intent.

Related skills

• stripe-best-practices — API design, RAK permissions, dynamic payment methods, webhook signature verification, deprecation migrations. Load first for any design question; this skill assumes the design is correct.
• stripe-live-rollout has been consolidated into this skill. Its unique material — the AI fit-check chat pattern and the cs_live_… browser-title trick — now lives in references/ai-fit-check-chat.md and the "Live-mode verification" section below, respectively.
• ai-visibility-for-small-sites — closing the "AI says nothing about you" gap. Companion workstream that often ships alongside go-live: the JSON-LD on the live site should reflect the live-mode Stripe catalog, not the test-mode one.
• wrangler and workers-best-practices — for the Cloudflare Worker deploy mechanics.
• github-pages-product-landing — for the static-site side of the integration (success/cancel pages, FAQ, schema.org).

Support files

• templates/deploy.sh — wrangler deploy wrapper that reads CLOUDFLARE_API_TOKEN from ~/.cloudflare_token and defaults to dry-run (use --live to actually push).
• templates/set-secrets.sh — wrangler secret put wrapper for STRIPE_SECRET_KEY + STRIPE_WEBHOOK_SECRET with hidden prompts. No values written to disk.
• references/headless-cloudflare-deploy.md — full headless-VPS pattern, the account_id mismatch pitfall, the token-persistence pitfall, and the empty-read -rs / 1-byte token file gotcha.
• references/live-state-audit.md — the 60-second pre-flight audit: Worker mode (live vs test), catalog drift between Operator data file and Worker CATALOG, policy pages, Stripe-mode sanity, and what the audit does not cover (webhook URL, bank verification, statement descriptor). Read this before the "go live" request to route greenfield-vs-already-live correctly.
• references/page-state-probe.md — the probe playbook for verifying any design-doc premise about the product surface (live HTML, hardcoded URLs, nav links, endpoint citations) before designing against it. Companion to live-state-audit.md; together they cover deploy-state and page-state. Read before any "Stripe on landing" / "checkout on marketing page" request where a brief, design doc, or yesterday's YOLO summary has stated a fact about user-visible behavior.
• references/stripe-checkout-automation.md — what works and what doesn't when the agent uses browser_* tools to fill the Stripe Payment Element during the test dry run. Read this before spending time on browser-form automation.
• references/ai-fit-check-chat.md — the AI fit-check chat pattern (gpt-4o-mini → [READY_TO_SCORE] token → scoring function → fit_check_id round-trip into Stripe Checkout metadata), the per-service set-openai-key.sh sibling pattern, the $(cat ...) tool-filter pitfall, the 429-insufficient-quota failure mode with the static-form fallback, the "which machine am I on?" reflex for two-machine sessions, and the "Failed to fetch" CORS + opaque-redirect trap on the buyer's checkout click (the Response.redirect() gotcha
  • the fetch(..., { redirect: 'manual' }) gotcha, with the native-form-submit fix).
• references/user-communication-cadence.md — the one-word-prompt-during-known-flow handling, the hybrid-storefront (pricing table + Worker) framing, the "placeholder values are a STOP signal" rule, and the cs_live_… browser-title live-mode verification trick. Consolidated from the archived stripe-live-rollout skill.
• references/express-live-smoke-test.md — the Express/Node verify-the-pipes ritual for when the integration is already live (env file at /etc/<product>.env, Express server.mjs) and the user says "show me money" or "verify the live Stripe pipes" rather than "go live." Six steps: find env + port, background-start server with set -a; . /etc/...env; set +a, hit /api/health, fire live-mode checkout sessions via curl, cross-verify each with Stripe REST (livemode=True), expire every orphan session on the account, kill the servers. Includes the test-key- masquerading-as-live-key pitfall, the localhost-only binding convention on this VPS, and the "always expire orphans — they accumulate" housekeeping rule. The Cloudflare Worker equivalent is Phase 6 + Phase 7 of the main SKILL.md.
• scripts/live-smoke-test.sh — one-shot executable that runs the six-step ritual for a list of products in one invocation. Read each /etc/<product>.env, start each server on its port, fire one session per price tier, cross-verify, expire orphans across all touched accounts, kill all servers, print a green/red summary. Usage: live-smoke-test.sh chromebloom 3017 cart seed-red-anthurium-planter hermosskills 3019 plan sponsor hermosskills 3019 plan commission.