Fintech pentest: what a security assessment of a money-moving product actually covers

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

What makes fintech different from other web apps

Every web application has authentication and authorisation issues. Fintech applications have all of those plus a category of vulnerabilities that only exist because money moves through them: race conditions that let an attacker spend the same balance twice, business logic flaws that let users escalate their own KYC tier, webhook replay attacks that credit accounts without actual payment, and API parameter manipulation that changes transaction amounts before server-side validation.

A scanner cannot find any of these. They require a tester who understands how payment flows work, knows what NIBSS and Paystack callbacks look like, and thinks like an attacker who wants money, not just data.

The attack surfaces we test on a fintech engagement

1. Payment flow logic

We test every step of your payment flow for manipulation. This includes testing whether the amount in your frontend request is validated server-side, whether your backend verifies payment status against the gateway API rather than trusting the callback body, and whether concurrent requests can bypass balance checks:

# Race condition test: fire concurrent transfer requests
# to see whether the balance check is atomic

import asyncio, httpx

async def attempt_transfer(client, token, amount):
    return await client.post("/api/v1/transfers", json={
        "amount": amount,
        "recipient": "acc_attacker"
    }, headers={"Authorization": f"Bearer {token}"})

async def race_condition_test(token, balance):
    # Fire 10 requests simultaneously, each for the full balance
    async with httpx.AsyncClient() as client:
        tasks = [attempt_transfer(client, token, balance) for _ in range(10)]
        results = await asyncio.gather(*tasks)
    return results

If multiple requests return success, your balance lock is not atomic. We have found this on loan disbursement APIs, wallet transfer endpoints, and cashback redemption flows.

2. KYC tier and permission escalation

Nigerian fintech products almost always have tiered KYC: Tier 1 (BVN only), Tier 2 (ID document), Tier 3 (full verification). Transaction limits, product access, and withdrawal caps are tied to these tiers. We test whether a Tier 1 user can manipulate API requests to access Tier 2 or Tier 3 functionality:

# Test: attempt to access Tier 3 endpoint with a Tier 1 token
curl -X POST https://api.yourapp.com/v1/transfers/bulk \
  -H "Authorization: Bearer TIER1_USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"transfers": [...], "kyc_tier": 3}'

# If this returns 200 instead of 403, your tier check
# is on the client, not enforced server-side

3. Webhook signature verification

Payment gateways send webhooks to notify your server of successful payments. If your server does not verify the webhook signature, an attacker can send a forged webhook crediting any amount to any account without making a real payment. We test every inbound webhook endpoint for signature verification, idempotency handling, and replay tolerance:

# Forged webhook test against an unprotected endpoint
import requests

forged_payload = {
    "event": "charge.success",
    "data": {
        "reference": "txn_attacker_ref",
        "amount": 50000000,  # NGN 500,000
        "customer": {"email": "attacker@example.com"},
        "status": "success"
    }
}

# No x-paystack-signature header. If this credits the account,
# signature verification is absent or bypassable.
response = requests.post(
    "https://yourapp.com/webhooks/paystack",
    json=forged_payload
)

4. API authorisation between roles

Most fintech products have multiple user roles: customer, merchant, agent, support, and admin. We test every sensitive API endpoint from every role that should not have access. Broken Object Level Authorisation (BOLA) is the most common critical finding in fintech APIs: a customer can access another customer's transaction history by changing a transaction ID in the request URL.

5. Mobile application security

For mobile-first fintechs, we test the mobile app separately from the API. This includes: certificate pinning bypass to intercept traffic, root detection bypass to run on a jailbroken device, extraction of hardcoded API keys and secrets from the app binary, and deep link hijacking for OAuth flows. We use Frida for dynamic instrumentation on Android and iOS builds.

6. Third-party integrations

NIBSS, Paystack, Flutterwave, Mono, Okra, Smile ID, YouVerify, BVN providers, telco billing APIs. Each integration is a trust boundary. We test how your application handles unexpected responses, error states, and whether integration credentials are properly protected in your infrastructure.

What we deliver

At the end of the engagement you receive: a detailed technical report with every finding, its CVSS severity score, a proof-of-concept demonstration, business impact, and an engineering-ready fix recommendation. You also get a report walkthrough call with your engineering team where we walk through every finding and answer technical questions. After your team ships fixes, we retest every finding to verify remediation. The retest is included, not an upsell.

Related reading

Blog: Business logic flaws in Nigerian payment platforms · BOLA in payment APIs · Webhook race conditions

Blog: Application security testing for fintech · How a Simpa Labs pentest works · Fintech API security steps

Services: Penetration testing · API security testing · Live fintech security review