React when a payment comes in

A Stripe event starts a routine immediately. Build the read-and-draft path first, test it with Stripe test data, and add customer-facing effects only when their authorization boundary is real and observable.

• What you'll build — A connector-event trigger on Stripe's Checkout completed event and a routine that validates the event, prepares a client update and thank-you draft, and writes an internal sale summary. Sending and record updates are a separate promotion step.
• Who it's for — Anyone taking Stripe payments who wants a tested path from an event to an operational workflow.
• Time & plan — About 25 minutes. You need an Agents balance, a Stripe test key, and an email connector only if you later add delivery.

Claude Code or Codex authors the routine through the Agents MCP. MyChatBot stores it and runs it when Stripe fires the enabled trigger.

Ingredients

#	Resource	How it is configured	Needed for
1	A routine-capable Agent	Claude or Codex inspects and reuses one from inventory	Reading the event and drafting output
2	Stripe connector	Enter the API key in Agents → Connectors	Receiving checkout events
3	Sales Platform or CRM connector	Claude or Codex inspects existing account configuration	Looking up or eventually updating the customer
4	Gmail or another delivery connector (optional)	OAuth URL from Claude/Codex, or Agents → Connectors	Sending only after the effect path is approved
5	Checkout-completed trigger	Staged disabled by Claude/Codex when the source permits; otherwise created in the app	Starting the routine

Stripe credentials never go through Claude or Codex

Stripe uses a secret key rather than OAuth. Enter a least-privilege test key in the MyChatBot app. Never paste it into Claude or Codex, an MCP argument, routine YAML, a skill, or a document. The Agents MCP intentionally has no credential field.

1. Connect Claude or Codex and configure Stripe

Open any Agent's Tasks tab and choose Connect Claude or Codex. Follow Build routines with Claude or Codex if this account is not connected yet.

In Stripe, use test mode and create the narrowest key that supports the event and reads you intend to exercise. Enter it on Agents → Connectors. Return to your coding agent and ask it to refresh get_account_authoring_inventory.

2. Describe a draft-only first version

Build a Stripe checkout-completed routine. Version 1 must validate the event,
look up any matching client read-only, draft a short thank-you email, and write
an internal summary of the proposed client fields. It must not send, update,
create, or delete anything.

Inspect my account, trigger catalog, Agents and routine docs first. Validate the
complete YAML and show it to me before saving. Run readiness and a billed
tool-free preview only after asking. Stage the checkout-completed trigger
disabled if the MCP supports this source; otherwise tell me exactly what must be
created in the app. Do not enable it.

Ask Claude or Codex to make the event contract explicit in the first prompt: expected event id, checkout id, customer id/email, amount, currency and test/live mode. The routine should stop or report a malformed event rather than inventing missing payment details.

3. Validate and preview the workflow

The coding agent calls validate_routine, shows the canonical YAML, and waits before saving. After get_routine_readiness has no blockers, a separately approved start_routine_dry_run can test a representative event such as:

{
  "event_id": "evt_test_sample",
  "type": "checkout.session.completed",
  "livemode": false,
  "checkout_id": "cs_test_sample",
  "customer_email": "sample@example.invalid",
  "amount_total": 4900,
  "currency": "usd"
}

Use synthetic values only. The preview runs the workflow and models but removes Stripe, email, Sales Platform, CRM and every other tool. It proves event parsing, prompt hand-offs, branching and draft quality—not that Stripe or a customer record was contacted.

4. Stage the trigger disabled

The coding agent inspects the trigger catalog and uses the exact source slug and typed source_config it reports. The Agents MCP creates connector-event triggers disabled and rejects unknown fields. If Stripe's source requires credential material during subscription setup, the coding agent directs you to the routine's Automations panel instead; the secret still never enters MCP.

Review:

• Checkout completed, not a similar invoice or subscription event;
• test-mode scope and any source filters;
• target routine and message template;
• deduplication field based on the stable Stripe event id;
• maximum fires per hour and expected Agents cost;
• trigger state: disabled.

5. Test the read-and-draft path live

The Agents MCP cannot start a live run. In Stripe test mode, complete a test checkout and enable the staged trigger only for this narrow check. Because version 1 has no external write or send instruction, its live routine should:

1. receive the test event;
2. read the permitted context;
3. draft the thank-you;
4. describe the proposed client change;
5. record an internal summary in its routine conversation.

Inspect the history, then disable the trigger while changing the routine. Verify the event id is retained so duplicate delivery can be identified.

A trigger keeps one operational thread

Repeated fires use the trigger's own conversation, so its history remains together instead of creating a new Agents Platform chat for every payment.

6. Promote external effects separately

There are two distinct effects:

• updating or creating the client record;
• sending a customer-facing thank-you.

Add and test them one at a time. Require stable ids and idempotent update logic; an event can be delivered again after an ambiguous failure. Use a provider test recipient before any real customer address.

Routines never pause for approval

A routine that starts runs every step to the end. There is no approval card, no review pause, and no switch that turns one on — the mechanism was removed, not disabled.

approval, approval_message, requires_iteration_review and requires_output_review are still accepted so existing YAML keeps loading and saving, but none of them stops a run. If a routine of yours was written around a gate, treat that step as fully live and re-read its prompt.

So an owner-authored step does whatever its task says, including effects that reach real people — messages, calls, outreach, publication, deletion, live record changes. Writing the step is the authorization; there is no second checkpoint before a customer is contacted. Scope each prompt to exactly the action you want, and rehearse with a dry run (tools switched off) before you attach a schedule or trigger.

(Router requires_user_input is unrelated and still works: it supplies a branch choice the workflow needs, not permission to act.)

When the effect boundary is acceptable, have Claude or Codex validate the changed YAML, show the full canonical version, update the routine, run readiness again, and stage/enable automation through separate approvals.

Variations

• Use Invoice paid for recurring invoices.
• Use Payment failed to draft an internal recovery task without contacting the customer.
• Add a condition that separates test and live events.
• Add a router for one-time purchase, renewal and high-value order handling.
• Add a second internal-only summary routine on a daily schedule instead of expanding the per-payment path.

See also

• Build routines with Claude or Codex — complete authoring and promotion sequence
• App-event triggers — connector events and source setup
• Triggers — queuing, deduplication, limits and self-protection
• Routine YAML reference — condition, router and approval fields
• Usage & billing — how each trigger fire is metered