Stripe

Stripe is the payments infrastructure most modern software runs on. It handles the part of a business that has to work every single time: taking money. You wire it in once and it processes card payments, manages subscriptions and recurring billing, stores customer and payment-method data, runs the checkout flow, sends invoices, and handles the messy real-world parts of getting paid (failed cards, retries, refunds, disputes, tax). It is API-first, so the developer integration is the product, and most teams build their whole billing layer on top of it.

Where it fits

Stripe is built for software companies and online businesses that charge money through code rather than through a card terminal. If you sell a SaaS product, run a subscription, take payments on a marketplace, or need recurring billing that you do not want to build yourself, this is the default choice. It scales from a solo founder taking a first payment to a large platform processing serious volume, and the same account grows with you.

It is less of a fit if your business is offline-first (a physical shop wanting a simple card reader and nothing else), if you want a fully no-code setup with zero developer involvement, or if you operate in a region or industry Stripe does not support well. For those cases a payment provider built around the till, or a local specialist, often fits better than Stripe's developer-led model.

The honest take

The strength is reliability and breadth. Stripe rarely goes down when it matters, the documentation is genuinely good, and the API is clean enough that engineers like working with it, which is rare for a payments tool. The product surface keeps widening (billing, tax, invoicing, fraud tooling), so you can keep more of your money stack in one place as you grow.

The trade-offs are real too. Pricing is transparent but not cheap, and the per-transaction cut adds up as you scale, so high-volume businesses do eventually shop around. It is developer-led by design, which means a non-technical founder usually needs help to get past a basic setup. And consolidating your billing on one provider is convenient until you want to leave, at which point the lock-in is felt. None of this makes it the wrong call for most software businesses, but going in clear-eyed about cost and dependency is the honest move.

INTERVIEW EWOUD: What is your overall verdict on Stripe, and what is your star rating out of five?

INTERVIEW EWOUD: Is Stripe in your own stack, and if so what do you actually use it for and why did you pick it?

INTERVIEW EWOUD: What is the one line you would tell a peer who is deciding whether to build on Stripe?

Founders, finance and data teams analysing payments, subscription and billing data already in 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.

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.

INTERVIEW EWOUD: How is your own Stripe set up across the portfolio: one account per venture, or one account with separate products, and how do you keep the Customer model mapped to your tenants?

INTERVIEW EWOUD: What is the one Stripe workflow you rely on most for getting paid (Checkout, Payment Links, invoicing, the Customer Portal), and why that one?

INTERVIEW EWOUD: What is your hard-won tip with Stripe, the thing that bit you once and you now do automatically (webhooks, idempotency, dunning, tax)?

Stripe is a payments platform whose Sigma add-on provides analytics on a business's Stripe data, queried with SQL or AI-generated natural-language prompts inside the Stripe Dashboard. It exposes cleaned tables for payments, subscriptions, invoices, customers and refunds, and turns queries into saveable charts, dashboards and scheduled email reports. It is aimed at founders, finance and data teams that run revenue and billing analysis on Stripe transaction data.