Stripe
Stripe
Definition: The leading developer-first payments platform, known for its clean API and being the default choice for adding payments to a software product, with standard pricing around 2.9% + $0.30 per successful card charge in the US. Founded in 2010 by brothers Patrick and John Collison, it grew from “seven lines of code to accept a payment” into a full financial infrastructure company spanning payments, billing, tax, fraud, and banking-as-a-service.
Core Services & Concepts
- Idempotency keys — Idempotency, Stripe is the textbook example used to explain this concept: pass the same
Idempotency-Keyheader on a retried request and Stripe guarantees it won’t double-charge the customer, even if your network call timed out and you genuinely don’t know whether the first attempt succeeded - Webhooks — Webhook, Stripe is also the textbook example used to explain webhooks; events like
payment_intent.succeededorinvoice.payment_failedare signed with a secret so your endpoint can verify authenticity before trusting them, and Stripe explicitly documents that events can be delivered more than once - REST API — REST API, versioned by date (e.g.
2024-06-20) rather than a simple v1/v2 scheme, so integrations keep working on their pinned version even as Stripe ships changes — an account can run on a 2019 API version indefinitely if nobody upgrades it - PaymentIntents / SetupIntents — a stateful object model that walks a payment through multiple steps (requires confirmation, 3D Secure authentication, capture) instead of a single fire-and-forget charge call, because modern card payments in the EU/UK legally require a customer-facing authentication step that a single API call can’t represent
- Stripe Connect — the platform/marketplace product for routing payments to multiple sub-accounts (e.g. splitting a marketplace sale between the platform and a seller), available as Standard, Express, or Custom account types depending on how much of the onboarding/compliance burden the platform wants to own
- Test mode — every account has a fully parallel test environment with fake card numbers (
4242 4242 4242 4242succeeds, others simulate specific decline reasons), so an entire billing flow can be built and CI-tested without moving real money
How Pricing Works
- Standard US card rate is 2.9% + $0.30 per successful charge, with no monthly fee, setup fee, or minimum for the base product
- International cards and currency conversion add extra percentage points on top of the base rate
- Stripe Billing (subscriptions), Stripe Tax, and Radar (fraud) are separate paid add-ons layered on top of the core payments fee, not included by default
- Custom/negotiated pricing kicks in at meaningful volume — the public rate card is really a small-business default, not what large customers actually pay
- Refunded transactions don’t get the processing fee back, only the disputed/refunded amount, which surprises teams doing the math on refund-heavy businesses
Pros
- Best-in-class developer experience and documentation, widely considered the reference implementation for a payments API
- Handles complex billing (subscriptions, proration, invoicing, tax via Stripe Tax) out of the box instead of building it in-house
- Extremely reliable infrastructure with strong uptime and clear status reporting
- Built-in fraud tooling (Radar) and strong-customer-authentication (3D Secure) support for EU regulatory requirements
- Excellent test-mode tooling (fake cards, CLI event forwarding via
stripe listen) makes local development and CI genuinely pleasant compared to most payment providers
Cons
- Transaction fees (roughly 2.9% + $0.30 per charge domestically, more for international cards and currency conversion) add up meaningfully at high volume compared to negotiated enterprise processor rates
- Payouts can be delayed or accounts frozen for risk review with little warning, a common complaint from marketplaces and high-risk-category businesses
- Connect’s fee structure and account types (Standard, Express, Custom) add real complexity for platforms splitting payments across many sellers
- Support is largely self-serve/ticket-based unless paying for a premium support plan, which frustrates businesses used to a dedicated account manager
Comparison: Stripe vs PayPal vs Square
| Stripe | PayPal | Square | |
|---|---|---|---|
| Primary strength | Developer experience, API design | Consumer trust and recognition | In-person + online in one system |
| Typical rate | 2.9% + $0.30 | ~3.49% + fixed fee | ~2.6% + $0.10 (in-person) |
| Best fit | Software products, online-first businesses | Cross-border consumer checkout | Retail/restaurants with a physical counter |
| API style | REST, versioned, widely praised | Modern v2 API, but legacy NVP/SOAP still lingers | REST, unified with POS/inventory |
Best For
- Any software product needing to accept online payments, especially developer-led companies that want to move fast without building billing infrastructure
- Marketplaces and platforms needing to split payouts between themselves and third-party sellers via Connect
Real Examples
- Used by Shopify, Amazon (for some flows), and a huge share of SaaS/e-commerce startups for checkout and subscription billing
- Lyft, DoorDash, and many marketplace apps use Stripe Connect to pay out drivers/merchants directly from the platform
Use Cases
- Subscription billing
- One-time payments
- Marketplace payouts via Stripe Connect
- Usage-based/metered billing for API and infrastructure products
- Embedded finance features (e.g. issuing cards, holding balances) via Stripe Treasury and Issuing
Integration Notes & Common Pitfalls
- Always verify webhook signatures against the raw request body — most frameworks parse JSON automatically before your handler sees it, which breaks signature verification (see Webhook)
- Treat every webhook as potentially delivered more than once; store the event ID and check it before applying an update
- Don’t rely solely on the synchronous API response to know a payment “worked” — for redirect-based methods (3D Secure, many local payment methods) the webhook is the actual source of truth
- Pin your API version explicitly rather than silently riding “latest,” so a Stripe-side change doesn’t alter your integration’s behavior without warning
Code Example
// Creating a PaymentIntent server-side, then confirming it client-side
const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);
const paymentIntent = await stripe.paymentIntents.create({
amount: 2000, // smallest currency unit — cents, not dollars
currency: 'usd',
automatic_payment_methods: { enabled: true },
});
// Return paymentIntent.client_secret to the frontend, which uses
// Stripe.js to confirm the payment without your server ever touching
// raw card details.
Code Example: Verifying a Webhook
// Express endpoint verifying a Stripe webhook signature before trusting it
app.post('/webhooks/stripe', express.raw({ type: 'application/json' }), (req, res) => {
let event;
try {
event = stripe.webhooks.constructEvent(
req.body, // raw Buffer, not JSON-parsed
req.headers['stripe-signature'],
process.env.STRIPE_WEBHOOK_SECRET,
);
} catch (err) {
return res.status(400).send(`Webhook signature verification failed: ${err.message}`);
}
if (event.type === 'payment_intent.succeeded') {
// Mark the order paid — idempotently, since Stripe can redeliver this event
}
res.json({ received: true });
});
FAQ
Why does Stripe warn against using the response from paymentIntents.create as proof of payment?
Because many payment methods (3D Secure, bank redirects, several local European methods) finish asynchronously after the customer leaves your page — the webhook, not the initial API response, is the actual source of truth for final status.
Is Stripe PCI compliant out of the box? Using Stripe.js/Elements or a hosted Checkout page keeps raw card numbers off your servers entirely, which meaningfully reduces your own PCI compliance scope (SAQ A) compared to handling card data directly.
Can I use Stripe without Stripe Billing for subscriptions? Yes — some teams build custom recurring-billing logic on top of one-off PaymentIntents, but most find Stripe Billing’s built-in proration, dunning, and invoice handling cheaper to adopt than to reimplement correctly.
History
- Founded in 2010 in Palo Alto by Patrick and John Collison, launched with the pitch of adding payments in a handful of lines of code
- Grew from a pure payments API into a broader financial infrastructure company: Billing (2018), Terminal for in-person payments, Treasury and Issuing for embedded finance
- Reached a peak private valuation around $95B in 2021 before markdowns during the 2022-2023 tech downturn, remaining one of the most highly valued private fintech companies
- Has not IPO’d as of this writing, unusual for a company of its size and age, running periodic tender offers for employee liquidity instead
Related Terms
Referenced by