Back to all posts

Why I Hunt Bugs in Payment Systems

January 12, 2025
Ahmad Mohamed Yoosuf
Security
8 min read

Most security researchers go after authentication bypasses or XSS vulnerabilities. I hunt payment bugs. Not because they're technically complex (they're often embarrassingly simple), but because they reveal something profound about how we build systems.

The €366 Lesson

When I found that Dropbox would give you €366 worth of premium features just by entering any IBAN, I wasn't surprised. When Stripe's implementation had the same flaw across multiple merchants, I wasn't surprised either. What surprised me was that these weren't bugs. They were features.

The systems were working exactly as designed. The designers just never asked: "What if someone lies?"

The Trust Assumption

Payment systems are built on a fascinating assumption: people won't commit fraud for small amounts. This isn't naivety. It's economics. The cost of preventing every €10 fraud might be €50 in engineering time and user friction.

But this calculation breaks when:

  • The "small amount" is €366 (not so small anymore)

  • The fraud is automated (scale changes everything)

  • The regulatory environment shifts (EU's new instant payment rules)

Why SEPA Is a Beautiful Mess

SEPA Direct Debit is particularly interesting because it's asynchronous by design. When you enter an IBAN, the merchant doesn't know if it's valid. They won't know for days. Sometimes weeks.

So they have three choices:

  1. Wait weeks to activate your service (terrible UX)

  2. Activate immediately and eat the losses (terrible business)

  3. Activate immediately and hope you're honest (terrible security)

Most choose option 3. Then they're shocked when someone posts about it in a Telegram group with 10,000 members.

The Real Vulnerability

The technical vulnerability is trivial: missing IBAN validation. But the real vulnerability is deeper. It's the assumption that payment systems can be trusted to work like payment systems.

When you swipe a credit card, authorization is instant. When you send a wire, it's (mostly) final. But SEPA? SEPA is built on the assumption that everyone has a European bank account, everyone is traceable, and everyone fears consequences.

Remove any of those assumptions. VPN to Italy, fake details, disposable email. The whole system collapses.

The Pattern

After finding the same vulnerability in multiple systems, I've noticed a pattern:

  • Day 1: "We need to accept European payments"

  • Day 30: "SEPA integration is working!"

  • Day 90: "Why is our chargeback rate 40%?"

  • Day 91: "Oh."

Why This Matters

By October 2025, the EU's new instant payment regulation requires IBAN-name verification. Every payment system built on trust-assumptions will need to be rebuilt on verify-assumptions. The companies that understand this early will save millions. The ones that don't will learn why I hunt these bugs.

The beautiful irony? The same companies spending millions on AI-powered fraud detection can't implement basic IBAN validation. They're so focused on complex threats that they miss the simple ones.

The Uncomfortable Truth

Here's what nobody wants to admit: these vulnerabilities exist because fixing them would hurt conversion rates. Every additional verification step loses customers. Every friction point costs money.

So companies make a calculated bet: the fraud losses will be less than the conversion gains. Usually, they're right. Until someone like me shows up and explains why they're not.

I don't hunt payment bugs because they're hard to find. I hunt them because they're hard to fix. Not technically, but economically. And that gap between what's possible and what's profitable? That's where the real vulnerabilities live.