Nigerian Fintech Security — Fixing Webhook Bypass, Race Conditions & Amount Manipulation

Nigerian fintech platforms face a unique attack surface — the vulnerabilities here don't just expose data, they enable direct financial theft. Here are the three most critical issues and how to fix them.

1. Paystack Webhook Bypass

// VULNERABLE — no verification
app.post('/webhook/paystack', async (req, res) => {
  if (req.body.event === 'charge.success') {
    await creditWallet(req.body.data.metadata.userId,
      req.body.data.amount / 100);
  }
  res.sendStatus(200);
});

// SECURE — verify signature
app.post('/webhook/paystack',
  express.raw({ type: 'application/json' }),
  async (req, res) => {
    const hash = crypto
      .createHmac('sha512', process.env.PAYSTACK_SECRET)
      .update(req.body)
      .digest('hex');

    if (hash !== req.headers['x-paystack-signature']) {
      return res.status(401).send('Invalid signature');
    }

    const event = JSON.parse(req.body);
    if (event.event === 'charge.success') {
      await creditWallet(event.data.metadata.userId,
        event.data.amount / 100);
    }
    res.sendStatus(200);
  }
);

2. Race Condition in Balance Updates

// VULNERABLE — race condition allows double withdrawal
const user = await User.findByPk(userId);
if (user.balance < amount) throw new Error('Insufficient');
await User.update({ balance: user.balance - amount }, { where: { id: userId } });

// SECURE — atomic update with row locking
const transaction = await db.transaction({
  isolationLevel: Transaction.ISOLATION_LEVELS.SERIALIZABLE
});

try {
  const user = await User.findByPk(userId, {
    lock: transaction.LOCK.UPDATE,
    transaction
  });

  if (!user || user.balance < amount) {
    await transaction.rollback();
    throw new Error('Insufficient funds');
  }

  await User.update(
    { balance: db.literal(`balance - ${amount}`) },
    { where: { id: userId, balance: { [Op.gte]: amount } }, transaction }
  );

  await transaction.commit();
} catch (err) {
  await transaction.rollback();
  throw err;
}

3. Server-Side Amount Validation

// VULNERABLE — trusting client amount
app.post('/api/purchase', async (req, res) => {
  const { productId, amount } = req.body; // Never trust this amount
  await processPayment(req.user.id, amount);
});

// SECURE — validate against database
app.post('/api/purchase', async (req, res) => {
  const { productId } = req.body;
  const product = await Product.findByPk(productId);

  // Use the server's amount — not the client's
  await processPayment(req.user.id, product.price);
});

The Pattern

All three vulnerabilities share a common root: trusting external input without verification. Webhooks must be signed. Balances must be locked. Amounts must be server-validated. None of these are complex fixes — but all three are commonly missing in Nigerian fintech codebases.

---

ZikarelHub LTD is Nigeria's #1 software and digital agency — secure fintech built from the ground up.

What fintech security issues have you encountered in Nigerian products? 👇

Comments

[Rahul S]

Solid list, and the shared root you name — trusting external input — actually has a fourth face the signature fix doesn't close: replay. A correctly-signed Paystack charge.success is valid forever, so anyone who can capture one (a log line, a misbehaving proxy, a retried delivery) can POST it again and creditWallet fires twice — the HMAC proves the event is authentic, not that it's fresh or that you haven't already processed it. The fix that pairs with your signature check is idempotency on the event reference: store data.reference (or the event id), and make the credit a no-op if you've seen it, ideally inside the same locked transaction from your #2 so two concurrent deliveries can't both win. And since the webhook body is still attacker-shaped once past the signature on some setups, treating amount as advisory and re-reading the settled charge from Paystack's verify endpoint before crediting closes the last gap where the number and the signature disagree.