Stripe is unusually good at the thing most business software is bad at: telling you, reliably and immediately, that something happened. Every meaningful event — a payment succeeded, a card was declined, a subscription is about to renew, a customer disputed a charge — is available as a webhook you can act on. Most businesses use approximately none of this, which means they are handling by hand a category of work that is entirely mechanical, and quietly losing revenue to failed payments nobody chased.
The pricing shape
Stripe's standard plan has no monthly fee. You pay a percentage of each successful charge plus a small fixed amount, with additional percentages for international cards and currency conversion. The exact rate depends on the country you bill from, and Stripe serves country-specific pricing.
What Stripe costs
| Tier | Listed price | What you get |
|---|---|---|
| Standard (pay-as-you-go) | A percentage of each charge plus a fixed per-transaction fee | Exact rate varies by country |
| International cards | Additional percentage on top of the standard rate | As listed on the pricing page |
| Currency conversion | Additional percentage when conversion is required | As listed on the pricing page |
Stripe’s pricing page serves country-specific rates, so we do not quote a single figure here — open the pricing page from the country you bill in and read your own rate. There is no monthly platform fee on the standard plan. Source: the vendor’s own pricing page, read August 5, 2026. Prices change — verify before you commit.
The webhook events that actually matter
Stripe emits a long list of events. For a small business, a handful carry nearly all the value.
checkout.session.completed— a customer completed a payment. This is the workhorse: fulfil the order, create the record, send the welcome, notify the team.invoice.payment_failed— the highest-value event in the list, discussed below.customer.subscription.updatedand.deleted— plan changes and cancellations. Downgrades and churn should trigger something, and in most businesses they trigger nothing.invoice.upcoming— fires ahead of a renewal. The window in which you can prevent a surprise, or notice a card is about to expire.charge.dispute.created— a chargeback, which has a response deadline. This one should wake someone up, because missing the deadline means losing by default.
Route the ones needing a human decision to Slack and let the rest run silently. Disputes and repeated payment failures need eyes; successful payments do not.
Failed payment recovery: the automation that pays for the project
For any business with recurring revenue, this is where the money is, and it is almost always neglected.
Cards fail constantly for entirely mundane reasons — they expire, they get reissued after fraud, the balance is briefly short. The customer has not decided to leave. They usually have no idea anything happened. But without a recovery process, a failed payment becomes a cancelled subscription, and you lose a customer who wanted to stay.
A recovery flow that works looks like this:
- The failure event fires. Retry on a schedule — Stripe's own retry logic handles much of this if configured.
- Email the customer immediately, in plain language, with a direct link to update the card. Not a dunning notice: a helpful message. Most people fix it in under a minute if you make it easy.
- If the card expires soon, prompt before the failure using the upcoming-invoice event. Prevention beats recovery.
- After a set number of failures, create a task for a human. For any customer worth real money, a personal message recovers accounts an automated sequence will not.
- Only then downgrade or cancel — and record why, so the reporting distinguishes genuine churn from payment friction.
Businesses that build this reliably recover a meaningful share of payments that would otherwise have become cancellations. It is the clearest example in this whole guide of an automation that directly returns money rather than time.
The idempotency trap
This catches essentially every first webhook implementation, so it is worth stating before you build rather than after.
Stripe may send the same event more than once. This is by design — it guarantees at-least-once delivery, not exactly-once. If your endpoint is slow to respond, times out, or errors, Stripe retries. Your handler will legitimately receive duplicates.
Handled naively, that means the customer gets two confirmation emails, the order is created twice, and the commission is paid twice. All of these have happened to real businesses.
Record the Stripe event ID of everything you process, and check it before doing any work. If you have seen that ID, acknowledge and stop. This is three lines of logic and it is the difference between a webhook handler that is correct and one that is merely usually correct.
Two related habits: verify the webhook signature so you are certain the request came from Stripe rather than someone who guessed your URL, and acknowledge fast, process after — return a success response immediately and do the real work asynchronously, so slow downstream systems do not cause retries and thus duplicates.
What to automate beyond the payment itself
- Payment to accounting. Push transactions into your books automatically. This removes a genuinely tedious reconciliation job and makes the books current rather than monthly.
- Payment to fulfilment. A successful charge triggers whatever delivering the thing requires — scheduling, provisioning, dispatch — with no manual handoff.
- Payment to CRM. Mark the deal won, record the amount, start the onboarding sequence. Sales and finance stop disagreeing about what closed.
- Payment link generation. Quote approved generates a Stripe payment link and sends it. Removing friction between "yes" and "paid" measurably shortens the gap.
- Refunds with a paper trail. Refunds requested through an approval step in Slack, executed via the API, logged with who approved and why.
Where Stripe is not the answer
Stripe is a developer-oriented platform, and its power assumes someone who can work with an API. If you want invoicing with built-in bookkeeping and no integration work, an accounting platform may serve you better. If you are selling products online, a store platform includes payments and handles inventory, tax and shipping you would otherwise build. And if you take payment in person, the calculation involves hardware and in-person rates rather than the online ones.
But if you are charging customers programmatically and want events in your business to follow automatically from money moving, Stripe's webhook model is the best available foundation — and the failed-payment flow alone usually justifies building on it. That is exactly the kind of workflow we scope during a free audit.