#payments

Pay by bank looks like two taps in the pitch deck. In production it's five hand-offs across three companies, and every one of them loses people.

Your ledger says a payment succeeded. The provider's settlement report, days later, disagrees. Which one is right?

Save to the database, then publish an event: two lines, two systems, and nothing that makes them agree. What happens when the process dies in between, and why every obvious fix still leaves a gap.

A checkout handler that calls the ledger, the warehouse, the email service and analytics in a row is as slow as all of them added together and as fragile as all of them multiplied. And every team that cares about payments makes it a little worse.

Two requests read the same row, both do their maths, both write back. One of them silently disappears. How the system should resolve that isn't one answer: it depends on whether the write is a delta, a quick piece of logic, or a human edit made minutes after the read.

Your checkout logs a line at every step, which looks like good observability. Then a customer says their payment failed, and you find out what those logs can't tell you.

You tap your card, the machine freezes, you tap again. Were you charged twice? An HTTP payment endpoint faces the same question on every retry, and without an idempotency key it gets it wrong.

A third of customers who chose pay by bank never finished paying, and most of them were lost inside their own bank's login. App-to-app redirects, a QR hand-off on desktop, a smarter bank picker and a return page that survives a lost session took completion from 64% to 82%.