Verify on the server, every time

Ikole Ballon d'Or is a football awards night. For a few weeks a year, it's also a payments business: fans pay to vote, buy tickets and purchase award packages, and every one of those payments has to turn into exactly one vote, one ticket or one award, with a claim code to prove it.

It processed over ₦950,000. Here's what it taught me.

The browser is the least reliable participant

A payment has three participants: the customer's browser, the payment provider and your server. Only one of them can be closed by accident.

So nothing is issued because a browser says "success". Every purchase is verified with Paystack on the server first, and only then does a claim code exist. A transaction that's already marked paid is never processed again, so a repeated notification can't produce a second code or a second email.

Free tiers sleep at the worst moment

The backend ran on a free hosting tier that sleeps when idle. That's fine on a quiet Tuesday and fatal ten minutes before a voting deadline. A scheduled job now pings the service every ten minutes, with a frontend fallback, so a fan never meets a cold start at the moment it matters most.

Fix it live, then write it down

During the live window, dashboard statistics and the winner-tag logic were wrong. Both were fixed the same day they were reported. But the more useful thing was what came after: a written list of everything that could have gone wrong next. Logout token handling. Inconsistent payment-callback references. CORS that was too open, TypeScript that was too loose, thin webhook tests, email without retries, and secrets that needed rotating.

That list became the backlog for the next edition. Written while it was fresh, it was specific. Written a month later, it would have been vague.

Three rules I keep

1. Verify on the server. Always.
2. Small events still need real infrastructure. Peaks are sharp and deadlines don't move.
3. Write the post-mortem the same week, and turn it into tickets, not regrets.