built around what couldn't move

// payment middleware · fintech · south africa
// client details anonymised

---

I designed the architecture. The constraints were the interesting part.

When payment terminals stop working people get upset quickly. The queue at the supermarket getting longer, the restaurant that can't take your card, the golf club that has to wave you through. People don't have patience when their money is involved, and payment service providers don't have patience for a startup full of excuses.

We were brought in to build the merchant-facing layer of a payment system. The portal, the apps, the receipts, the reporting. All of it on top of infrastructure that was already running and couldn't be changed. The constraints arrived with the brief.

• An existing switch with its own APIs that couldn't change
• Thousands of terminals already in the field that couldn't be disrupted
• Cross-company app teams who needed stable APIs before they'd build against them
• A PCI DSS compliance surface that had to stay small
• No tolerance for missed transactions, with the reputational stakes immediate
• Merchants routinely run multiple providers at once, so you're only as good as your last transaction

The job wasn't to build something new. It was to introduce something better without anyone noticing the transition. A new API layer sat alongside the switch rather than replacing it. Queue-based webhooks made sure transactions couldn't disappear in transit. Tenant management with rights and roles meant PSPs could log in and manage their own terminals, and the switch could onboard new PSPs without manual intervention every time. The new app version gave merchants electronic receipts and a portal. Enough reason to migrate, nothing to break on the way.

The system was designed to keep running when parts of it failed. By the time we finished, the question "what happens if the database goes down?" had a boring answer.