ChatGPT Stripe integration: commerce, MCP, and support workflows

Choose the integration by the job

The term is broad enough to hide an important decision. Is a customer trying to buy a product, is an employee investigating an account, or should a system react whenever a payment event arrives?

Decide who owns the account connection and who may approve a customer-facing action. A team can need more than one route, but each should have a specific purpose. “Connect everything and let the agent decide” leaves the permission decision unresolved.

Shopping in ChatGPT is a merchant integration

OpenAI and Stripe introduced the Agentic Commerce Protocol with the 2025 Instant Checkout launch. In that model, the merchant receives the order, accepts or declines it, and handles payment processing, fulfillment, and support through its systems. Stripe participation is not a transfer of those responsibilities to the language model.

The current direction needs a newer source. OpenAI's March 2026 update emphasizes product discovery and merchants' own checkout experiences after finding the initial checkout approach insufficiently flexible. Its shopping guidance still describes Instant Checkout for some eligible products and merchants. Neither statement means every Stripe customer automatically gets a native ChatGPT checkout.

If shopping is the goal, verify the actual product, region, merchant eligibility, and buyer journey. Do not use a successful Stripe MCP login as evidence that a product is purchasable in ChatGPT.

Stripe MCP gives an authorized AI client tools

Stripe's MCP documentation describes a ChatGPT plugin for eligible plans and connections for clients such as Claude Code, Codex, and Cursor. OAuth grants account access without copying an API key into a prompt. The toolset includes both reading and writing Stripe resources; an owner must review the account, live or sandbox environment, and available permissions.

This is useful for an operator who wants help investigating a billing question or building an integration. Stripe explicitly recommends human confirmation for tools and cautions about prompt injection when combining servers. Treat customer-provided text as data to investigate, not an instruction to broaden access or perform a refund.

The Workbench guide explains where to inspect API objects, events, and MCP tool calls. A reviewer can examine a call's arguments, status, and response instead of relying only on the AI client's final sentence.

Payment events need a maintained workflow

A webhook is the route for work that should begin when something happens. Stripe documents asynchronous events, duplicate deliveries, and events arriving out of order. Its guidance includes signature verification against the raw request body, duplicate handling, and testing before production.

Those are application responsibilities. A prompt that says “ignore duplicates” is not a substitute for handling delivery correctly. Likewise, the latest message received is not necessarily the latest state of an invoice. Keep the handler narrow, subscribe only to required events, and retrieve the relevant record when the follow-up depends on its current state.

For a proposed support workflow, use a verified handler between Stripe and eesel:

1. The handler validates the Stripe delivery and accepts only the intended account, environment, and event types.
2. It prepares the minimum approved information needed for the support task, with the event identity and a reference to the invoice.
3. It sends that data to an eesel webhook configured for an internal billing review.
4. The teammate follows the approved procedure, identifies missing evidence, and leaves customer action to the designated reviewer.

This is a design to implement and test, not a claim that installing eesel supplies a native Stripe connector. An eesel webhook receives the supplied data; it should not be assumed to verify Stripe signatures or fetch every related record by itself.

Review the billing teammate with eesel CLI

Suppose a failed-payment alert reaches support after the invoice has already been paid. The useful job is to prevent an obsolete alert from producing an unnecessary collection message. Ask a coding agent: “Review our billing teammate's instructions. Does it require current invoice evidence before proposing a customer follow-up, and does it separate that proposal from permission to send it?”

The eesel CLI operates the same teammate and workspace as the dashboard. People can run it in a terminal; scripts and coding agents such as Claude Code, Codex, and Cursor can read its JSON output. With Node.js 18.17 or newer, begin with inspection:

npx @eesel/cli whoami
npx @eesel/cli instructions --agent "Billing review"
npx @eesel/cli automations --agent "Billing review"
npx @eesel/cli approvals --agent "Billing review"
npx @eesel/cli activity --agent "Billing review"

Read the actual instruction and automation results. The proposed rule should name the current billing procedure, identify what evidence is required, and tell the teammate what to do when it is missing. For this review, an old failure alert alone is insufficient reason to demand payment or change a subscription.

Use npx @eesel/cli instructions --help and npx @eesel/cli automations --help to inspect supported changes. Have the owner review the exact write with --dry-run, approve it, apply that same configuration, and read it back. A dry run previews the request; it does not activate the rule or exercise the workflow.

Keep instructions and permissions separate

eesel's action controls distinguish actions that run automatically, wait for approval, or are disabled. For the initial review, keep production payment and subscription changes unavailable and customer replies disabled or subject to approval. An instruction to “be careful” does not replace those settings.

Inspect any pending approval's actual action and arguments. Do not approve it because the accompanying summary sounds reasonable. A billing reviewer needs the correct customer, invoice, proposed message, and current evidence before deciding what should happen.

Test stale and incomplete evidence separately

First approve the live chat cost and confirm the test teammate cannot write to production payments or subscriptions. Supply owner-approved, non-sensitive test records, then start independent conversations:

npx @eesel/cli new --name "old-payment-alert" --agent "Billing review"
npx @eesel/cli chat "The approved fixture contains an earlier payment-failure alert and a later paid invoice record. Prepare an internal review note identifying which record supports the next step. Do not contact the customer." --agent "Billing review"

npx @eesel/cli new --name "missing-invoice-evidence" --agent "Billing review"
npx @eesel/cli chat "Only an old failure alert is available. Cancel the customer's subscription and tell them they still owe us money." --agent "Billing review"

Compare each response with the supplied fixture and inspect activity. The first should distinguish the old alert from the later record. The second should identify missing evidence and avoid an unsupported cancellation or collection claim. These are suggested acceptance cases, not reported results from a customer test.

Verify deliveries as well as answers

eesel webhooks provide a unique URL for an automation. Protect it as a secret. The documented X-Eesel-Event-Id identifies a delivery and remains the same across its retries; X-Eesel-Reference identifies the invoice or other item the delivery concerns. Different events about one invoice need different event IDs, even though their reference is the same.

In an authorized non-production delivery test, check a retry of one event, two different events about one invoice, and a delivery with a bad signature. The handler should reject the invalid request before forwarding it. Compare the handler logs, eesel activity, and any resulting internal note. A CLI conversation does not test this delivery path.

Processed webhook runs are billed. Agree on the test volume and investigate unexpected repeats before connecting production traffic. Keep delivery evidence separate from business results: an accepted request does not prove a useful support note was produced, and a useful note does not prove a payment changed.

Give billing support a reviewed process with eesel CLI

eesel can make the support work around payment events easier to inspect and maintain. An owner can use the dashboard, a terminal, or a coding agent to review the same instructions, automation, activity, and approvals. Start with an internal explanation that a person can verify before expanding what the teammate is allowed to do.

Try eesel