Payment gateway penetration testing in Nigeria

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs Comprehensive Security Partner (CSP)

Every week a new fintech startup launches in Lagos. They use modern tools. They use fast frameworks. They connect to Paystack or Flutterwave. They assume they are secure because the gateway is secure. This assumption destroys companies. The criminals in Nigeria do not attack Paystack directly. They attack how your specific app talks to Paystack.

We specialize in payment gateway penetration testing. We hunt for the flaws in your business logic. We manipulate the data moving between your server and the payment provider. We find the exact bugs that cause double crediting and unauthorized wallet funding.

The gateway is not the vulnerability. Your integration is.

Paystack, Flutterwave, Interswitch, Monnify, and every other major Nigerian payment gateway have been through extensive security reviews. Their infrastructure is not where attacks happen. Attacks happen at the boundary between your application and the gateway.

A boundary is a trust gap. When your app receives a webhook, do you trust it immediately? When your mobile app says a payment is complete, does your backend trust the mobile app? When a user asks for a refund, do you trust that they paid the original amount? We attack these boundaries. We test how you verify payments. We test how you process webhooks. We test how you handle errors. We test what your backend does with client submitted data.

The six attack classes we test on every payment integration

Generic vulnerability scanners look for SQL injection and cross site scripting. They do not understand money. We manually test your payment flows. Here are the six exact attack classes we test during a payment gateway security assessment.

1. Server-side payment verification bypass

This is the most common critical finding in Nigerian fintech. Your payment flow looks like this: the user pays on the gateway. The gateway redirects the user back to your app with a reference. Your backend receives the reference and credits the user.

The critical question is this: does your backend verify that reference against the gateway API before crediting? Many startups just take the reference from the mobile app and assume it is valid. An attacker uses a proxy tool. They capture a failed payment reference. They change the status code in the proxy from "failed" to "success". They send it to your backend. Your backend credits them with fake money. We test this exact scenario.

// VULNERABLE: trusting the client-submitted reference
app.post('/payment/callback', async (req, res) => {
  const { reference, amount } = req.body;
  // NO verification against gateway API
  await wallet.credit(req.user.id, amount);
  res.json({ status: 'credited' });
});

// CORRECT: verify against the gateway before crediting
app.post('/payment/callback', async (req, res) => {
  const { reference } = req.body;
  // Verify with Paystack API
  const verification = await paystack.transaction.verify(reference);
  if (verification.data.status !== 'success') {
    return res.status(400).json({ error: 'Payment not confirmed' });
  }
  const verifiedAmount = verification.data.amount / 100; // kobo to naira
  await wallet.credit(req.user.id, verifiedAmount);
  res.json({ status: 'credited' });
});

2. Webhook signature verification

Webhooks are server to server callbacks. The gateway sends them when a payment event occurs in the background. If your webhook endpoint does not verify the cryptographic signature, anyone can send a forged webhook. We test this by sending forged payloads to your webhook URL. We do not include a valid signature. We observe whether the endpoint processes the fake webhook.

If your server accepts our fake webhook, we can fund our own wallet with millions of Naira. We do not even need an account. We just need to know your webhook URL. We hunt for missing signatures. We also hunt for poorly implemented signatures where the server checks the signature but fails to reject the request if the signature is missing entirely.

import hmac, hashlib, requests

# What your backend should check
def verify_paystack_signature(payload_bytes, signature, secret):
    expected = hmac.new(
        secret.encode('utf-8'),
        payload_bytes,
        hashlib.sha512
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

# Our test: send without a signature at all
response = requests.post(
    'https://yourapp.com/webhooks/paystack',
    json={"event": "charge.success", "data": {"amount": 50000000}},
    # No x-paystack-signature header
)
# If this returns 200 and credits the account: critical finding

3. Idempotency and replay attacks

A legitimate payment webhook can be replayed. Gateways sometimes send the same webhook multiple times. This happens because of network retries or delivery guarantees. If your backend does not check whether a webhook reference has already been processed, you have a massive vulnerability.

We test idempotency on every webhook endpoint. We capture a real webhook that credits a user with NGN 1,000. We copy it. We replay it 100 times in five seconds. Does your server credit the user NGN 100,000? We see this constantly. Your database must lock the transaction row. It must flag the reference as processed. It must reject all future webhooks with that exact same reference.

4. Amount manipulation in payment initiation

When your frontend initiates a payment, it often sends an amount to your backend. Your backend then creates the charge on the gateway. We test whether that amount is taken from client input directly. We test whether your backend recalculates it from the authenticated session state.

For example, your app sells a premium subscription for NGN 50,000. The mobile app sends a request to your server asking for a payment link for NGN 50,000. We intercept that request. We change the amount to 1 kobo. We forward it to your server. Your server asks Paystack for a 1 kobo payment link. We pay the 1 kobo. The webhook fires. Your server gives us the premium subscription. We test this exact attack path on every single checkout flow.

5. Refund and dispute logic

Refund endpoints are frequently undertested. Developers spend months perfecting the payment flow. They spend one afternoon writing the refund flow. We test whether the refund amount is bounded by the original transaction amount. We test whether a user can request a NGN 10,000 refund on a NGN 1,000 purchase.

We test whether a refund can be initiated by a user who did not make the original payment. We test whether refunds can be initiated multiple times for the exact same transaction. A broken refund system drains your company bank account directly. We treat refund logic with the same severity as payment logic.

6. API key and credential exposure

Live secret keys leak everywhere. We find them in frontend JavaScript bundles. We find them in mobile app binaries. We find them in public GitHub repositories. We find them in CI/CD environment variables logged to output. We check all of these places.

A live Paystack secret key gives an attacker full API access. This includes the ability to initiate transfers from your company account to any bank account in Nigeria. We decompile your mobile apps. We scrape your javascript bundles. We hunt for hardcoded credentials. If you accidentally compiled a staging key into your production app, we will find it and report it.

The Simpa Labs guarantee

When we test your payment gateway integration, we bring years of adversarial engineering experience. We know exactly how Nigerian payment systems are built. We know exactly how they fail. We test every edge case. We test every API boundary. We do not stop until we have mapped every possible attack path.

You receive a technical report that actually helps your engineers. We include the exact curl commands to reproduce the bug. We include the exact code snippet required to fix it. We schedule a walkthrough call to ensure your team understands the risk. We retest the fixes for free. We ensure your payment flow is bulletproof.

Related reading

Blog: Webhook security for payment platforms · Webhook race conditions · Business logic flaws in Nigerian payment platforms

Blog: Virtual card issuance security audit · How to secure a payment gateway integration · Rate limiting for payment APIs

Services: Penetration testing · API security testing