Stripe tells you its events arrive out of order and sometimes twice. Believe it.

What the Stripe API does and does not allow

Card payments and the money side of everything else. The best-documented API in this register by a wide margin.

Everything in the strip above is Stripe’s own published documentation, fetched 1 September 2026 and linked to the page it came from. We have not paraphrased it into something friendlier, because the exact wording is what you need when a limit bites at four in the afternoon.

What follows is what those facts mean for a build — the constraints that change a design decision rather than the ones that are merely true. If you want the same treatment for the other eight systems side by side, that is the capability register. If you want to know whether we have built against both sides of a particular pairing, the integration checker answers that specific question.

Unordered, at-least-once, and why that is good news

Stripe does not guarantee event order. Distinct events can even share a created timestamp, so that field cannot be used to sequence them. Stripe also says endpoints might occasionally receive the same event more than once, and that in some cases two separate Event objects are generated for one thing that happened.

Most platforms have these properties. Stripe is unusual in writing them down, and writing them down is what lets you build correctly. The handler has to be idempotent — track event IDs, ignore ones you have seen — and it has to derive state from the object rather than from the sequence of notifications. A payment handler that says "if I see succeeded after refunded, something is wrong" is a handler built on an assumption Stripe never made.

The verification discipline matters just as much. Verify the raw body before parsing it, because any manipulation of the bytes breaks the signature. Ignore any signature scheme that is not v1 — Stripe deliberately sends a fake v0 in test to catch downgrade handling. And do not set the replay tolerance to zero, which Stripe explicitly warns against.

Idempotency has a 24-hour memory, and minimum charges are real

Stripe supports idempotency keys on every POST, and saves the status code and body of the first request — including failures. Retry with the same key and you get the same answer back rather than a second charge. It is the right mechanism and we use it on every write.

The limit is that keys are only guaranteed for 24 hours. After that a key may be pruned, and the same request executes again as new. Any retry queue that can be down for longer than a day needs its own duplicate protection on top of Stripe’s, because Stripe’s has expired.

The other one that bites in practice is the minimum charge amount: fifty cents in Australian dollars, and different in every currency. Automations that charge a computed remainder — a rounding adjustment, a small part-payment, a final balance of thirty cents — fail on the small ones. That failure is correct behaviour and it always arrives as a surprise, so put a floor check in the flow and decide up front what happens below it.

• Idempotency key on every write A V4 UUID, stored with the intent that produced it, so a retry is provably the same request rather than a similar one.
• Floor check before charging 0.50 AUD is the minimum. Decide whether a smaller balance is written off, rolled forward or flagged — before the first one appears.
• Never search-then-confirm Stripe’s search is eventually consistent and filters on a cached status. Read the object directly for anything a decision depends on.

Rate limits and what breaks at scale

One hundred requests a second in live mode, twenty-five in a sandbox, twenty-five a second on individual endpoints, plus targeted limits — a thousand updates per PaymentIntent per hour, twenty new invoices per subscription per day, twenty reads a second on search. When you hit one, the 429 carries a Stripe-Rate-Limited-Reason header naming exactly which, which is the most helpful rate-limit response in this register.

The limit almost nobody knows about is the read allocation: an average of 500 read requests per transaction over a rolling 30 days, with a floor of 10,000 reads a month. Write requests have no allocation at all. The shape that trips it is a reporting or reconciliation integration polling hard against an account that does not process many payments — which is exactly the shape a small business builds first.

Concurrency is counted separately from rate, and list requests and requests with expansions are what drive it. So the fix for a concurrency 429 is not to slow down, it is to stop expanding things you do not need. Two different problems that return the same status code, distinguished only by that header.

What Stripe does not publish

2 of the thirteen fields we track are simply absent from Stripe’s documentation: where your client’s data physically sits and whether API access itself costs anything.

This is the part of an integration page that competitors leave out, and it is the part that costs money. An undocumented rate limit is not an academic gap — it means the first time you find the ceiling is in production, on someone else’s business, usually on the busiest day of their month.

We are not going to fill these in with figures from a forum thread. Numbers circulate for most of them, and some are probably right, but we cannot show you where they came from and neither can the person who posted them. When we have measured Stripe properly under load, those figures will appear here with the date we measured them and the conditions we measured them under. Not before.

What we have built, and what we have not measured

We have implemented against Stripe in production. That is a real fact and it is also a limited one — it tells you we have solved this system's problems before, and it does not tell you how fast, how reliably, or at what volume.

The honest position is this. Everything on this page above the line is the vendor's published documentation, which we fetched, dated and linked rather than paraphrased. Nothing on this page is a Kindra measurement, because our measured register is not finished and publishing half of it dressed up as all of it would make this page less useful, not more.

What we would do on an engagement is measure the specific things that matter for your build — the endpoints you depend on, at your volume, with your data — and hand you those numbers whether or not they suit us. If they say the integration is harder than we quoted, you get told that too. Start with a Leak Check, or read how we work first if you would rather know the shape of it before talking to anyone.