What payment gateway testing covers
Payment security failures happen at integration boundaries, not inside the gateway itself. The gateway is secure. The code connecting your product to the gateway is where attackers find gaps. We test every boundary in that connection.
Webhook signature verification
Paystack, Flutterwave, and Stripe sign webhook payloads with HMAC-SHA256. We test whether your backend actually enforces the signature check on every inbound webhook — not just the first time you implemented it. We test unsigned payload acceptance, expired timestamp windows, missing event ID deduplication, and whether test-mode webhooks can be replayed against your production endpoint. A missing or misconfigured signature check means anyone on the internet can trigger a payment confirmation on your platform by sending a forged POST request.
Payment amount manipulation
In most fintech integrations, the transaction amount travels from the client — browser or mobile app — to your backend before your backend initiates the payment with the gateway. If your backend trusts the amount supplied by the client without comparing it against a server-side order record, an attacker can modify the amount in transit and pay ₱100 for a ₱10,000 order. We test every step between client initiation and gateway call to find where amounts are controlled and whether they can be tampered with.
Race conditions in concurrent payments
Two requests arrive at the same millisecond, carrying the same idempotency key and the same transaction reference. Does your ledger process one or both? Race conditions in payment endpoints are notoriously hard to detect with normal testing — they require concurrent request firing timed to hit your server within the same database transaction window. We use Burp Suite's Turbo Intruder and custom timing scripts to exploit race conditions in wallet funding, withdrawal processing, and referral bonus crediting.
Callback URL manipulation
Some gateway integrations allow the client to pass a callback URL in the payment initiation request. If your backend uses the caller-supplied URL without validating it against a pre-registered allowlist, an attacker can redirect the post-payment callback to their own server. They receive the confirmation event. Your backend never sees it. We test whether the callback URL is validated, whether the allowlist is enforced server-side, and whether the redirect destination can be manipulated through URL encoding or subdomain tricks.
Settlement and payout authorization
Can any user trigger a payout request, or only a merchant with a verified, approved settlement account? Does your system check payout eligibility at the time of the request, or only at account creation? We test payout initiation endpoints for missing authorization checks, the ability to change the destination account number in transit, and whether payout limits can be exceeded through parameter manipulation or concurrent requests.
Refund and reversal abuse
Can a merchant issue a refund for more than the original transaction amount? Can a customer trigger a chargeback through direct API manipulation, bypassing the dispute review process? Can refund tokens be reused? We test refund endpoints for missing upper-bound validation, broken object-level authorization between merchant and transaction records, and whether your refund processing applies the same signature and authorization checks as the original payment flow.
Paystack-specific vulnerabilities
Paystack is the most common payment gateway for Nigerian fintech products. Its webhook architecture uses the X-Paystack-Signature header containing an HMAC-SHA256 hash of the raw request body, signed with your Paystack secret key. The correct implementation validates this header on every inbound request before acting on the event. We consistently find integrations that skip this check entirely, check only on some event types, or validate the signature after already acting on the event data.
Paystack's split payment feature introduces additional attack surface. Subaccount configurations determine how settlement is divided between a primary merchant and a sub-merchant. If the subaccount ID or bearer field can be manipulated in the payment initiation call, an attacker can redirect a portion of every settlement to an account they control. We test the full subaccount permission model and verify that split percentages are enforced server-side, not client-side.
Paystack's transfer API — used for disbursements and payouts — requires a recipient code tied to a verified bank account. We test whether the recipient code can be swapped for an unverified or attacker-controlled recipient, whether transfer authorization (OTP or link) can be bypassed, and whether the transfer amount is validated against an authorized ceiling before the API call is made.
Flutterwave-specific vulnerabilities
Flutterwave uses the verif-hash header for webhook authentication. We test hash validation implementation, currency conversion handling in cross-border payments, and idempotency enforcement on their event system. Flutterwave's event architecture means the same payment event can be delivered multiple times if the initial webhook delivery fails. If your backend does not deduplicate on the transaction reference and event type, it will credit the user for every delivery attempt.
Flutterwave's Pay with Bank Transfer feature uses dynamic virtual accounts. We test whether the virtual account creation is properly isolated per user session, whether the amount expected can be manipulated after the virtual account is issued, and whether incoming bank credit notifications are verified against the expected amount or simply trusted and processed.
Webhook replay attack on Nigerian fintech settlement endpoint
We tested a payment platform that processed settlements based on incoming Paystack webhook events. The backend received the charge.success event, verified the transaction reference against its database, and credited the merchant's wallet. The problem: no timestamp validation. No event ID deduplication. No signature verification.
We captured a single legitimate webhook using Burp Suite. We replayed it 50 times against the production endpoint over 90 seconds. The backend processed all 50 events. The merchant was credited 50 times the original transaction amount. Total potential loss from a single captured webhook: 50x the transaction value, with no rate limiting or deduplication to stop it.
Fix priority: immediate. The remediation required enforcing HMAC signature validation, adding a processed event ID table, and implementing a 5-minute timestamp window check — three separate controls that should have been there from day one.
Testing methodology
We run payment gateway tests in three phases.
Phase 1 — Integration mapping. We review your gateway documentation, API calls, webhook handlers, and business logic. We map every event type your integration handles, every endpoint that initiates or confirms a payment, and every point where money moves or a balance changes. We also identify all third-party dependencies — payment SDKs, mobile libraries, serverless functions — that participate in the payment flow.
Phase 2 — Active manipulation. We run tests against your staging environment with full gateway sandbox access. We craft forged webhooks, replay captured events, fire concurrent requests, manipulate amounts in transit, attempt callback URL substitution, and test all refund and payout endpoints across every user role. We use Burp Suite Professional, Turbo Intruder for race conditions, custom Python scripts for webhook replay, and ngrok for callback manipulation.
Phase 3 — Impact proof and reporting. Every confirmed vulnerability gets a reproduction script you can run yourself. We show the exact HTTP request that exploits it, the exact response that confirms it works, the account state before and after, and the maximum financial impact of the flaw at scale.
What you receive
The report covers everything we tested and everything we found.
Verified findings with proof. Every finding includes the exact cURL or Python script used to trigger the vulnerability, the raw HTTP request and response logs, and the account state change that demonstrates financial impact. No theoretical findings. Every issue is proven exploitable before it goes in the report.
Gateway-specific remediation code. We write remediation guidance in the language and framework your backend runs. If you use Node.js with Express, you get the exact middleware code to validate Paystack signatures. If you use Django REST Framework, you get the decorator. If you use Go, you get the handler function. Copy-paste implementation.
Idempotency and race condition design review. Beyond the specific bugs, we provide a design review of your idempotency implementation — including database schema recommendations for event deduplication tables and transaction locking strategies to prevent race conditions at the database level.
Retest after fixes. Once your team deploys the fixes, we retest every confirmed vulnerability. We confirm the fix is correct, not just present. We update the report with retest status and issue a final sign-off letter suitable for compliance or partner review.
Executive summary. A one-page summary of findings, severity, and business risk written for your CEO, CFO, or banking partner — not your backend team.