Stripe’s Collison Brothers and a Simple Test for Reliable Payments
In Stripe’s 2025 annual letter, published on 24 February 2026, cofounders Patrick and John Collison wrote: “Checkout, payments, and fraud protection continue to work predictably underneath.” 1
They were describing Stripe’s AI shopping tools. Our concern here is one basic requirement behind that promise: a customer who pays once should have that payment counted once and receive the service they bought.
That becomes harder when a job stops halfway. In the example below, the payment is recorded but internet access is not restored. The software has to try again. It must recognize the completed payment and finish the missing access step.
This is our practical example of predictable payment handling, drawn from a FyberPay code review and a small teaching test.
One payment, two messages
Imagine a customer pays 1,000 for an internet package. The software has two jobs: record that payment against the bill, then add the access the customer bought.
The first job succeeds. The second fails.
A moment later, the same payment message arrives again. It is a reminder about the original payment. The customer has still paid only 1,000.
If the software starts everything again, it may add another 1,000 to its records. The bill now shows 2,000 received, even though only 1,000 came in.
But ignoring the whole message creates another problem: the customer has paid, and their access is still missing.
Remember what is done. Finish what is waiting.
Keep a separate record for each job:
- Payment recorded? Yes. Leave that amount alone.
- Purchased access added? No. Try that part again.
Think of a shop order. You would not ask a customer to pay again because the delivery van broke down. You would keep their receipt and arrange the delivery.
The software needs the same separation. “We received the money” and “we delivered the service” are different facts.
The access step also needs protection against being repeated. If it succeeds and the reply gets lost, a later attempt should recognize the completed job rather than add extra access.
We tried three ways to handle it
On 23 October, we used a small local test program to send the same payment message twice. We made the access step fail once.
The results were easy to compare:
- Start everything again: 2,000 recorded from one payment.
- Stop because the payment is recorded: 1,000 recorded, but no access added.
- Check each job separately: 1,000 recorded and the access added once.
These were invented amounts in a teaching test, not customer transactions. The test showed this one recovery problem. It did not test a live payment provider, router, or several payments arriving together.
We also reviewed this two-job approach in FyberPay’s payment code and an existing test for a payment recorded before an access failure.
A saved task list can still send the same message twice
Developers often use a transactional outbox. Think of it as saving a business update and its follow-up task on the same durable checklist.
It helps prevent the follow-up work from being forgotten. It still needs a way to recognize repeated messages. AWS warns that outbox messages can arrive more than once. 2
The useful rule is simple: remember the completed work, then continue with the unfinished work.
Three questions to ask your developer
Can the payment and its “done” record be saved together?
If the amount is saved but the “done” record is lost, the next attempt may count it again. If only “done” is saved, the software may skip a payment it never recorded.
What if two genuine payments arrive at the same time?
Those are two payments and both must count. They need different references. Developers can also use database locks to make conflicting updates wait until the current transaction finishes. 3
What if another company’s system does the work?
Your database cannot tell you everything that happened elsewhere. Some providers offer a reference that helps them recognize a repeated request. Stripe documents this kind of retry protection. 4 Use the provider’s rules, and check uncertain results before trying again.
You do not need to know every technical term to ask for a demonstration. Ask the team to interrupt a job after the payment is recorded, then show what happens on the next attempt.
The result to look for is straightforward: one payment counted once, the purchased service delivered once, and unfinished work able to continue.