Stripe
Stripe API
MCP server
Checked on 2026-10-10 in the developer documentation.
How to use Stripe
This guide gets you from a blank Stripe account to a billing system you can actually run a B2B business on: subscriptions that renew, invoices that get paid, webhooks that keep your own database honest, and a tax setup that does not blow up at year end. It is written for founders and operators who are wiring Stripe into a SaaS or services business themselves, not for engineers who already live in the API docs. If you sell software on a recurring basis, this is the order I would do things in.
Getting set up
Start with the account decisions that are expensive to change later, because most of Stripe's pain comes from getting these wrong early.
The first decision is your data model, not a setting in the dashboard. Stripe thinks in Customers, Products, Prices, and Subscriptions, and you want to mirror that vocabulary in your own database from day one. A Customer is the billing identity for an account (in B2B that is usually the company, not the individual user), a Product is the thing you sell, and a Price is a specific amount and interval attached to that Product. You almost never edit a Price: you create a new one and migrate to it, which keeps historical billing intact. Decide now that the Stripe Customer ID lives on your account record, because everything downstream keys off it.
Read the full guideShow less
Second, turn on test mode and stay there until the whole flow works end to end. Stripe gives you a complete parallel environment with its own keys and its own test cards, and there is no excuse for testing billing against live money. Build, break, and prove the flow in test, then flip to live.
Third, get your business profile, tax registrations, and bank payout details in properly before you take a single real payment. This is the boring part people skip, and it is the part that holds up your first payout. If you sell across borders, decide early whether you are using Stripe Tax to calculate VAT and sales tax automatically, because retrofitting tax onto live subscriptions is miserable.
Finally, set up webhooks before you think you need them. Stripe is the source of truth for what happened to a payment, and a webhook is how your own system finds out. Treat "we will add webhooks later" as a decision to have inconsistent data later.
How to actually use it
The core loop for a B2B SaaS is: define what you sell, attach a checkout, listen for the result, and reconcile your own records. Do it in that order.
Begin by modelling your Products and Prices to match your real pricing. If you sell a monthly and an annual plan, that is one Product with two Prices. If you have tiers, that is usually separate Products or separate Prices depending on whether the value proposition differs. Keep this clean, because a messy product catalogue shows up later as confusing line items on a customer's invoice.
Next, get money in with Stripe Checkout or Payment Links rather than building your own card form first. Checkout is a hosted page Stripe maintains, it handles card entry, wallets, and a lot of compliance you do not want to own, and it is the fastest honest path to a working purchase. Payment Links are even simpler when you just need a URL to send. Build a custom in-app flow only once the hosted version has proven the business case.
Then wire the subscription lifecycle. When a customer subscribes, Stripe generates invoices on each renewal, attempts payment, and emits events for success, failure, and cancellation. Your job is to react to those events: grant access on a successful payment, start a dunning and grace process on a failure, and revoke access on a final cancellation. The Customer Portal is worth turning on here, because it lets customers update their card, switch plans, and cancel without emailing you, which removes a whole category of support work.
The last step in the loop is reconciliation. Your application database and Stripe will drift unless something keeps them in sync, and the webhook handler is that something. Treat Stripe's event as the truth and update your own record to match, never the other way around.
Power moves
Use idempotency keys on every write request. If a network call times out and you retry, the idempotency key stops you charging a customer twice, and it is the single most important habit that separates a robust integration from a fragile one.
Lean on metered and usage-based billing when your pricing is consumption-led. Stripe can aggregate usage you report and bill it at the end of the period, which means you do not have to build a billing engine yourself.
Master proration. When a customer upgrades mid-cycle, Stripe can charge the difference automatically, and understanding how proration behaves on plan changes lets you offer flexible upgrades without manual credit notes.
Use the dashboard's revenue reporting and Sigma (or exported data) to watch churn, failed payments, and MRR honestly. Smart retries and dunning recover a surprising share of failed renewals, and turning these on is close to free money.
Where it fits your stack
Stripe is the billing core, and it earns its place by connecting cleanly to everything around it. Push subscription and revenue events into your CRM so sales and success see who upgraded, downgraded, or churned without asking finance. Feed the same events into your analytics so MRR and churn are measured from the source of truth rather than a spreadsheet. Connect Stripe to your accounting tool so invoices and payouts reconcile against your books automatically. In a growth stack it sits downstream of your acquisition tools and upstream of your reporting: ads and content bring people in, Checkout converts them, and Stripe's events become the revenue numbers everything else reports on.
Pitfalls to avoid
Do not treat your own database as the source of truth for payment state. Stripe is. If you decide locally that a subscription is active, you will eventually be wrong.
Do not edit Prices in place or delete Products that have live subscriptions. Create new Prices and migrate, so your billing history stays intact.
Do not ship without testing failed payments and cancellations. The happy path always works in a demo; the value is in handling the card that declines on renewal.
Do not skip webhook signature verification. An unverified webhook endpoint is a way for anyone to tell your system a payment succeeded when it did not.
Do not ignore tax until an auditor asks. Decide your tax approach before you go live, because backfilling correct VAT and sales tax across historical invoices is painful.
How to automate Stripe
API and webhooks
Stripe has a documented REST API and SDKs. Webhooks push events to your HTTPS endpoint when payments, subscriptions or disputes change, and you can register up to 16 endpoints. Events can also go to Amazon EventBridge or Azure Event Grid. The Stripe CLI lets you test locally.
An idea: on a successful payment event, create the customer and the deal in HubSpot, and grant access in your app. Keep the webhook handler idempotent, because events can be delivered more than once.
Built-in automation
Stripe Workflows is a visual builder in the Dashboard. A workflow starts with a trigger, such as a Stripe event, and runs steps with conditions, loops and custom actions. An idea: when a high-value payment is disputed, tag the customer and alert your team without writing code.
MCP server
There is an official remote MCP server at mcp.stripe.com, in public preview. It uses OAuth or API keys, and the docs recommend agent API keys with limited permissions for autonomous clients. Per the vendor, from 31 October 2026 it only accepts agent API keys or OAuth. An idea: ask Claude in a sandbox to list failed payments from the past week and draft follow-up emails. Test in a sandbox first and give the key as few permissions as possible.
No-code automation
Zapier lists a Stripe app, so you can connect payments to other tools without code. An idea: each new Stripe customer creates a row in a sheet and a welcome task for your team.