Read Stripe payments, invoices and events from a Sazabi investigation

Last verified on Nov 8, 2026.

A failed charge rarely announces itself in your application logs. The checkout service logs a 402, a retry, maybe a timeout. The reason (an insufficient-funds decline, a missing webhook, a subscription that was already cancelled) sits in Stripe. When you investigate from a Sazabi thread, the agent can read both sides, so you do not paste a payment ID into a second dashboard and then paste the answer back.

What the Sazabi agent can do with Stripe

Sazabi offers Stripe two ways, and each is connected on its own.

The MCP connector points at Stripe's remote server at mcp.stripe.com. Authorization uses OAuth 2.1 with PKCE, and the connection has a read-only toggle that governs write operations. Stripe's tool list is short on purpose:

• stripe_api_search finds an API method by keyword, and stripe_api_details returns its parameters.
• stripe_api_read calls any supported GET method. That covers customers, charges, PaymentIntents, SetupIntents, Checkout Sessions, invoices, subscriptions, disputes, events and webhook endpoints.
• stripe_api_write calls the POST, PATCH, PUT and DELETE methods.
• search_stripe_documentation answers questions about Stripe itself, such as what a decline code means.
• stripe_analytics runs reports in natural language, and Stripe notes it requires Sigma.

Some writes need a person. Creating a refund, for example, carries a Human confirmation badge in Stripe's docs: the agent hands back a URL, you approve it in the Dashboard within 24 hours, and then the agent retries.

The sandbox CLI puts the stripe command in the agent's sandbox. Sazabi stores a STRIPE_SECRET_KEY and injects it when the agent runs. Sazabi's docs recommend a restricted key scoped to what the agent needs, which is the safer default for an investigation tool.

Questions it answers

• What did Stripe record for the PaymentIntent behind this checkout error?
• Did the invoice.payment_failed event fire, and did it reach our endpoint?
• Which webhook endpoints are enabled, and which events do they subscribe to?
• Is this customer's subscription active, past due or cancelled?
• What does this decline code mean, per Stripe's documentation?

A worked example: checkout errors with no webhook

Your logs show POST /api/checkout/confirm returning 502 for a handful of customers, and support says the customers were charged anyway. In the thread you ask:

Between 14:00 and 14:20 UTC, checkout/confirm returned 502 for orders from
example.com customers. Find the PaymentIntents created in that window, tell me
which succeeded, and check whether payment_intent.succeeded events were
delivered to our webhook endpoint.

The agent searches your logs first for the failing requests and extracts the order IDs and timestamps. It then uses stripe_api_search to find the list-PaymentIntents method and stripe_api_read to call it with a created-at range. For each PaymentIntent it reads status, and for the succeeded ones it lists events and retrieves the matching payment_intent.succeeded event. Finally it lists webhook endpoints to see whether one is enabled for that event type.

Read the result as two timelines. If the PaymentIntents succeeded and the events exist, Stripe did its job and the 502 happened in your service, so the next step is a look at the failing deploy. If the events exist but your logs show no inbound webhook calls, the endpoint URL or its enabled events are the lead. Ask the agent to stay on read tools here. Fixing the endpoint is a decision for you.

How it fits with other integrations

Stripe data is most useful beside other context the agent already has. Pair it with Slack to run the investigation where support raises it, with Linear to file the follow-up, and with PostHog for the user's session. Billing layers built on Stripe, such as Autumn, have their own pages. Browse the whole catalog under integrations and see pricing for plans.