Most software engineers have never built in payments.
This is probably good for their mental health. But it means they’ve never been forced to confront what software actually is: a set of promises to the real world, where the real world pushes back.
”It works” isn’t a state
In most domains, you can ship something, see it work, and move on. In payments, “it works” is a temporary observation. It means nothing until you’ve survived:
- Chargebacks from buyers who claim they never got what they paid for
- Fraudsters probing your checkout with stolen cards at 3am
- A processor changing their rules mid-quarter
- Reconciliation drift that you don’t notice until accounting asks why the numbers don’t match
Payments forces you to think in failure modes, not happy paths. And that’s a skill most engineers never develop.
The fraud never sleeps
Fraud is not a bug. It’s a business model on the other side of your API.
There are people whose job is to find the cracks in your system. They’re often better funded and more motivated than your team. They iterate faster because they don’t have standups.
This changes how you think about software. You stop asking “does this work?” and start asking “how will this be exploited?”
Constraints are the feature
In payments, you can’t just do what you want. Banks have rules. Card networks have rules. Regulators have rules. Your processor has rules about the rules.
At first, this feels limiting. Then you realize: constraints force clarity.
When you can’t just add a feature because “it’s technically possible,” you have to actually think about whether it’s a good idea. Payments taught me that the best products aren’t the ones with the most flexibility—they’re the ones with the right constraints.
The reconciliation problem
Every payments company eventually discovers the reconciliation problem: the money you think you have is not the same as the money you actually have.
This sounds trivial. It isn’t. Reconciliation failures compound. A small drift today becomes an accounting nightmare in six months. The systems that survive are the ones that assume they’re wrong and build in continuous checking.
This is a generalizable lesson: any system that can get out of sync with reality will eventually get out of sync with reality. Build the feedback loops early.
What you learn
Building in payments teaches you:
- The happy path is a lie
- “It works” means nothing without durability
- Adversaries are part of the system
- Constraints force good decisions
- Reconciliation is a feature, not an afterthought
If you’ve never built in payments, find an excuse to. It’ll make you better at everything else.