Threat Intelligence · June 2026
Warning signs your payment gateway is being exploited
Payment gateway exploitation does not announce itself with alarms. It shows up as statistical anomalies buried in transaction logs - anomalies your team is not looking for because nobody told them what to look for. Here are eight indicators, how to verify each one, and what to do the moment you confirm it.
Eight red flags: rising transaction reversal rates without business reason, micro-transactions ($0.50-
The numbers behind Nigerian payment fraud
NIBSS reported ₦53.4 billion in confirmed fraud losses across Nigerian electronic payment channels as of Q2 2024. That figure only counts what was reported and confirmed - actual losses are estimated at two to three times higher when accounting for unreported incidents and indirect costs like customer churn, regulatory penalties, and legal fees.
The Central Bank of Nigeria's Cybersecurity Self-Assessment Tool (CSAT) now explicitly requires financial institutions to demonstrate continuous transaction monitoring capabilities. If your team cannot articulate what exploitation looks like in your specific payment flow, you are already non-compliant.
What follows are the eight indicators we see most frequently during penetration testing engagements and incident response work with Nigerian payment platforms.
1. Transaction reversal rate climbing without business reason
Every payment platform has a baseline reversal rate - the percentage of transactions that get reversed, refunded, or voided. For healthy Nigerian fintechs processing card and bank transfer payments, this typically sits between 1.5% and 4%. When that number starts climbing to 6%, 8%, or higher without a corresponding business change (new product launch, pricing change, seasonal pattern), something is wrong.
What it means
Attackers use your platform to test stolen card details or manipulate transaction flows. Successful charges get reversed when the actual cardholders dispute them. Alternatively, an attacker may be exploiting a business logic flaw - initiating transactions, receiving the value (airtime, credits, transferred funds), then triggering reversals to get the payment amount back.
How to verify
Pull your reversal rate by week for the past 90 days. Calculate the standard deviation. Any week where the reversal rate exceeds two standard deviations above the mean warrants investigation. Cross-reference the reversals with the originating accounts - are they concentrated in a small number of user accounts or IP addresses?
Containment
Flag accounts exceeding three reversals in a 30-day window for manual review. Implement velocity checks: if a single account triggers more than two reversals in 24 hours, freeze outbound transactions on that account pending investigation. Log everything - you will need this data for your CBN breach notification if the pattern turns out to be systemic.
2. Micro-transactions testing stolen card numbers
A sudden cluster of transactions between ₦100 and ₦500 (roughly $0.50-$2.00) from accounts with no prior transaction history is a textbook card testing pattern. Fraudsters validate stolen card numbers by running small charges that are unlikely to trigger the cardholder's attention or your platform's fraud thresholds.
What it means
Your platform is being used as a card validation service. The attacker has a batch of stolen card numbers (sourced from dark web marketplaces, phishing campaigns, or previous breaches) and needs to determine which ones are still active. Each successful micro-charge confirms a valid card. The attacker then sells the validated numbers at a premium or uses them for larger fraudulent purchases elsewhere.
How to verify
Query your transaction database for all transactions under ₦500 in the past 7 days. Group them by: source IP address, device fingerprint, user account age (created within the last 48 hours), and BIN (Bank Identification Number - the first six digits of the card). If you see 20 or more sub-₦500 transactions from a single IP, device fingerprint, or from accounts all created within the same hour, you are looking at card testing.
Containment
Implement minimum transaction thresholds for new accounts (first 72 hours). Add CAPTCHA or step-up verification for transactions from accounts less than 24 hours old. Set up real-time alerts when more than five sub-₦500 transactions originate from a single device fingerprint within a one-hour window. Report the BINs to your payment processor - they may already be tracking the same card batch.
₦2.3 million in chargebacks from a single weekend
During an incident response engagement for a Lagos-based payment platform, we traced ₦2.3 million in chargebacks to a card testing campaign that ran over a Saturday and Sunday. The attacker validated 1,400 stolen card numbers through micro-transactions averaging ₦200 each, then sold the validated batch. The platform had no velocity controls on new accounts and no minimum transaction threshold.
3. Chargebacks from customers who deny making purchases
When legitimate customers contact your support team saying they see charges they never authorised, and the volume of these complaints exceeds your normal baseline (typically under 0.5% of transactions), your payment flow has been compromised. Either the customer's card details were stolen and used on your platform, or your platform itself is leaking card data to attackers.
What it means
This is the downstream effect of card testing (indicator 2) succeeding, or a separate attack vector where compromised credentials from social engineering or credential stuffing are used to make purchases through legitimate accounts. In the worst case, it indicates that your payment integration has a vulnerability that allows an attacker to charge arbitrary cards.
How to verify
Aggregate all chargeback and dispute cases from the past 30 days. For each, pull the full transaction record: IP address, device fingerprint, session ID, geolocation, and the time gap between account login and transaction. If the chargebacks cluster around transactions where the geolocation or device fingerprint differs drastically from the account holder's historical pattern, the accounts were compromised.
Containment
Enforce step-up authentication (OTP, biometric) for transactions exceeding ₦10,000 or when the device fingerprint is new. Implement real-time geolocation checks - a user who has only ever transacted from Lagos suddenly making payments from a Tor exit node in Eastern Europe is not legitimate. Notify affected customers immediately and reset their credentials.
4. Webhook callbacks from unrecognised IP addresses
Your payment processor (Paystack, Flutterwave, Monnify, Squad) sends webhook callbacks to your server to confirm transaction status. Each processor publishes a documented list of IP addresses from which these callbacks originate. If your webhook endpoint receives callbacks from IPs outside this documented range, someone is spoofing payment confirmations.
What it means
An attacker has discovered your webhook endpoint URL and is sending fabricated "successful payment" notifications to your server. If your webhook verification is weak or nonexistent - if you do not validate the signature hash or verify the source IP - your application will credit the user's account or fulfil an order without any actual payment being made.
How to verify
Enable access logging on your webhook endpoint. Extract all source IPs that hit the endpoint in the past 30 days. Compare them against your payment processor's published IP allowlist. Any IP not on the list that sent a request your system processed as a valid webhook is evidence of spoofing. Also check for webhook payloads where the transaction reference does not exist in your payment processor's dashboard when you look it up via their API.
Containment
Implement IP allowlisting at the firewall or reverse proxy level for your webhook endpoints. Always validate the webhook signature hash using the secret key provided by your processor. Never rely solely on the webhook payload - always make a server-to-server verification call to the processor's API to confirm the transaction status independently.
Not sure if your payment integration is properly secured? We test webhook verification, parameter tampering, and business logic flaws in Nigerian payment platforms every week.
Get a Payment Security Review5. Successful transactions with mismatched BVN or account holder details
If your KYC process collects and verifies Bank Verification Numbers (BVNs) but your transaction logs show successful payments where the card or bank account used does not match the verified identity on the account, that is a direct indicator of account takeover or identity fraud.
What it means
An attacker has either taken over a verified account and is using their own (or stolen) payment instruments, or your KYC verification is not properly linked to your transaction authorisation flow. In the Nigerian context, BVN verification through NIBSS is supposed to prevent exactly this scenario - but many fintechs only verify the BVN at signup and never check whether the payment instrument used at transaction time belongs to the same identity.
How to verify
Run a reconciliation query: for all transactions in the past 14 days, compare the name on the payment instrument (card name, bank account holder name) against the verified name on the user profile. Flag any mismatch exceeding basic variations (middle name presence, abbreviations). Check whether the mismatched transactions are concentrated in specific user cohorts or time windows.
Containment
Implement real-time name matching between the payment instrument and the KYC-verified identity. For any mismatch, require step-up verification before completing the transaction. This does add friction, but it eliminates one of the most common vectors for SIM swap and account takeover fraud in Nigerian fintechs.
6. Duplicate transaction reference IDs in your logs
Transaction references should be unique. If your logs contain two or more transactions with identical reference IDs, either your reference generation has a collision problem or an attacker is replaying transaction requests to double-credit an account.
What it means
Transaction replay attacks exploit idempotency failures in your payment processing logic. The attacker captures a legitimate, successful transaction request and replays it - submitting the exact same payload to your API endpoint. If your backend does not enforce idempotency (checking whether this reference has already been processed), it processes the transaction again, crediting the user's account twice for a single payment.
How to verify
Query your transaction table for any reference ID that appears more than once. For each duplicate, compare timestamps, source IPs, and response codes. If both entries show a successful status with different timestamps, you have confirmed a replay. Also check your rate limiting logs - replay attacks often show as rapid successive requests to the same endpoint with identical payloads.
Containment
Enforce unique constraints on transaction reference IDs at the database level. Implement idempotency keys: any API request with a previously seen reference ID should return the original response without reprocessing. Add a server-side timestamp window - reject any transaction request where the timestamp in the payload is more than 60 seconds old.
7. API calls with manipulated amount parameters
Your payment API accepts an amount parameter in the request body. If you find transactions in your logs where the amount charged to the customer differs from the amount your business logic should have calculated (the product price, fee structure, or transfer amount), an attacker is tampering with request parameters.
What it means
Parameter tampering is one of the most common and most damaging attacks against payment APIs. The attacker intercepts the API request (by decompiling your mobile app, using a proxy, or calling your API directly) and modifies the amount field. A ₦50,000 purchase becomes ₦500. A ₦1,000 fee becomes ₦0. If your server does not independently calculate and validate the amount, the tampered value goes through.
How to verify
For a sample of recent transactions, compare the amount in the API request log against the amount your pricing engine or business logic should have generated for that specific product, plan, or transfer. Any discrepancy - even ₦1 - is evidence of tampering or a bug. Both need immediate investigation. Cross-reference with the authorization checks on the endpoint.
Containment
Never accept the amount from the client. Calculate it server-side based on the product ID, quantity, and applicable fees. If your architecture requires the client to send the amount (for display consistency), validate it server-side against the expected value and reject any mismatch. Log every rejection - the pattern of rejected amounts reveals the attacker's methodology.
8. Transaction spike from a single device fingerprint
A sudden surge of transactions - ten, twenty, a hundred - all originating from the same device fingerprint within a short window, is not a power user. It is automated fraud. Device fingerprinting collects browser or device attributes (screen resolution, installed fonts, timezone, language, hardware concurrency) to create a semi-unique identifier. When one fingerprint generates anomalous volume, the device is running a script.
What it means
The attacker has automated transaction submissions using a bot or script. They may be testing stolen cards (indicator 2), exploiting a BOLA vulnerability to transact on behalf of other users, or draining promotional credits across multiple accounts they control. The single device fingerprint ties all the activity to one physical device, even if the requests come from different user accounts or IP addresses.
How to verify
Group all transactions from the past 7 days by device fingerprint. Sort by count, descending. Any fingerprint with more than 50 transactions in a single day (adjust this threshold to your platform's normal usage patterns) warrants investigation. Cross-reference with the number of distinct user accounts associated with that fingerprint - a single device operating 15 different accounts is a fraud ring.
Containment
Implement per-device transaction velocity limits. When a device fingerprint exceeds the threshold, trigger CAPTCHA challenges for subsequent transactions. For confirmed abuse, block the fingerprint entirely and investigate all associated accounts. Feed the fingerprint data into your fraud scoring model so future transactions from similar device profiles receive elevated scrutiny.
Most Nigerian fintechs lack real-time monitoring for these indicators
In our experience testing payment platforms across Lagos, Abuja, and Port Harcourt, fewer than 20% have real-time alerting configured for any of these eight indicators. Most rely entirely on their payment processor's fraud detection, which does not cover application-layer vulnerabilities. The average time to detect exploitation is 72 hours - by which point the damage is done and the attacker has moved on.
Building a detection baseline
Detection requires a baseline. You cannot identify anomalies if you do not know what normal looks like. For each of the eight indicators above, establish your platform's normal range using 90 days of historical data. Document the thresholds. Set up automated alerts that fire when any metric exceeds the threshold. Review the alerts weekly - monthly is too slow for payment fraud.
- Reversal rate: Track weekly. Alert at two standard deviations above the 90-day mean.
- Micro-transactions: Alert when more than five sub-₦500 transactions share a device fingerprint or IP within one hour.
- Chargeback rate: Track weekly. Alert when exceeding 0.5% of total transactions. Your card network will penalise you above 1%.
- Webhook source IPs: Allowlist your processor's published IPs. Alert on any request from an unlisted IP.
- BVN mismatches: Flag and queue for manual review any transaction where the payment instrument name does not match the verified identity.
- Duplicate references: Database-level unique constraint plus application-level idempotency check. Alert on any collision.
- Amount discrepancies: Server-side calculation with client-side comparison. Log and reject every mismatch.
- Device fingerprint velocity: Alert when a single fingerprint exceeds your daily transaction threshold or operates more than three distinct accounts.
What to do when you confirm exploitation
When you have confirmed one or more of these indicators, the response sequence matters. Panic-driven shutdowns cause more damage than measured containment.
- Isolate: Block the specific attack vector (IP, device fingerprint, account) without shutting down the entire gateway.
- Preserve evidence: Snapshot your logs, database state, and WAF records before making any changes. You will need these for forensic analysis, regulatory reporting, and potential law enforcement involvement.
- Assess scope: Determine how many transactions, accounts, and funds are affected. This determines whether you need to notify CBN and NDPC under the NDPA breach notification requirements.
- Notify your processor: Paystack, Flutterwave, and other processors have fraud and incident response teams. They may already have intelligence on the same attack pattern.
- Remediate: Fix the underlying vulnerability. If it is a webhook verification failure, implement proper signature validation. If it is parameter tampering, add server-side calculation. Do not just block the attacker - fix the flaw they exploited.
- Review and harden: Commission a penetration test focused on your payment flow to find any related vulnerabilities the attacker might have discovered but not yet exploited.
If you are seeing any of these indicators in your payment logs, do not wait. A targeted payment security review identifies the vulnerability, quantifies the exposure, and delivers a remediation plan.
Request an Urgent Payment ReviewRelated reading
Blog: Webhook Security for Payment Platforms · Rate Limiting for Payment APIs · Business Logic Flaws in Payment Platforms · Securing Payment Gateway Integrations
Guides: Fintech Security Checklist · After a Breach · CBN Compliance Guide
Services: Penetration Testing · API Security · Payment Gateway Security
Frequently asked questions
How quickly should I respond to payment gateway exploitation signs?
Immediately. Card testing attacks can escalate from micro-transactions to large-scale fraud within hours. The moment you identify anomalous patterns - unusual reversal rates, micro-transactions from unknown sources, or webhook callbacks from unrecognised IPs - you should activate your incident response plan. Delay costs money: NIBSS data shows the average exploitation window before detection in Nigerian fintechs is 72 hours.
What is the first thing to do if I suspect my payment gateway is compromised?
Isolate and observe. Do not immediately shut down the gateway unless active fund theft is confirmed, as this disrupts legitimate customers. Instead, enable enhanced logging on all payment endpoints, block the suspicious IP ranges or device fingerprints at the WAF level, and engage a security team to perform forensic analysis on the anomalous transactions.
Can Paystack or Flutterwave detect exploitation on my behalf?
Payment processors like Paystack and Flutterwave have their own fraud detection systems, but they primarily protect themselves and the card networks. Your application-layer vulnerabilities - parameter tampering, broken authorization, webhook spoofing - are your responsibility. The processor cannot see business logic flaws in your code.
How much does payment gateway fraud cost Nigerian fintechs annually?
NIBSS reported ₦53.4 billion in confirmed fraud losses across electronic payment channels in Nigeria as of Q2 2024. This figure covers card fraud, mobile money fraud, and internet banking fraud. Individual fintech losses vary, but mid-sized payment platforms report average incident costs between ₦15 million and ₦80 million when including chargebacks, regulatory penalties, and remediation.