While modern fintech startups default to RESTful JSON APIs like Paystack, enterprise corporations in Nigeria—airlines, universities, government parastatals, and tier-1 betting platforms—heavily utilize legacy integration patterns like Interswitch WebPAY and GT Pay. These integrations operate on older HTTP POST redirect paradigms, relying heavily on MAC (Message Authentication Code) hashing strings (like SHA-512 hashes of concatenated product IDs, transaction references, and amounts) rather than simple API bearer tokens.
These redirect-heavy integrations shift an immense amount of security responsibility directly onto the merchant's backend server. If the merchant implementation miscalculates a hash, fails to query the gateway directly, or trusts browser-supplied data, attackers will manipulate the transaction state to extract free value.
Start with the integration you run today
We record the exact provider product, version, payment initiation request, browser redirect flow, server-to-server verification call, webhook notification path, local order record, and ledger settlement record. We use the current provider documentation as our strict testing contract. We do not assume every Interswitch product uses the exact same parameters or verification method.
The provider platform itself (the Interswitch or GT Bank servers) stays completely outside the pentest scope unless you have written authorization from the gateway operators. Our penetration test targets your merchant application, your backend logic, your credentials, your configuration, and your transaction state machine.
1. Payment redirect hash validation testing
In older integration models, after the user completes payment on the Interswitch or GT Pay hosted page, their browser is redirected back to the merchant's website. The redirect URL contains transaction parameters (like `resp=00`, `amount=50000`, `txnref=AB123`). The merchant server is supposed to take these parameters, concatenate them with a private secret key, hash them, and compare the resulting hash to the one provided in the redirect.
We routinely attack this flow by removing the hash entirely, changing the amount, and replaying the browser return values. We deliberately corrupt the hash. The merchant backend must reject any missing or invalid integrity checks immediately. Furthermore, browser text alone must never complete an order. The merchant server must independently verify the final result by initiating a direct server-to-server query against the Interswitch/GT Pay transaction query endpoint.
2. Transaction reference enumeration and replay
A transaction reference (`txnref`) must be globally unique and single-use. We aggressively test reference handling logic. We capture a successful reference from a ₦100 test payment. We attempt to reuse that successful reference on a new ₦5,000,000 order. We attempt to swap references between two different user accounts.
We repeat the final callback webhook multiple times in rapid succession. A passing architecture requires one reference to settle one intended order exactly once. If the database lacks strict unique constraints, a single ₦1,000 payment can be replayed to credit a wallet twenty times in one second.
3. Amount manipulation between order creation and gateway redirect
When the user clicks "Pay", the merchant server generates a form that POSTs data to the gateway. We intercept this POST request in Burp Suite before it leaves the browser. We change the amount from `500000` (₦5,000) to `100` (₦1). We change the currency code. We manipulate the product item IDs.
If the hash generation happens entirely on the client-side, we simply generate a new valid hash for the ₦1 payment. We complete the ₦1 payment on the gateway. The gateway redirects back indicating success. The merchant backend must compare the verified provider result (₦1) with the server-held, tamper-proof order record (₦5,000). A pass requires an exact integer match before fulfilling the service. If the server only checks `resp=00` (success) and ignores the settled amount, the attacker just purchased a premium service for one Naira.
4. Merchant and product binding
Many enterprise gateways require a `mac` or `product_id` to route funds to the correct merchant account. We change merchant IDs, institution codes, and product identifiers when the integration exposes them. If an attacker replaces your Interswitch `product_id` with their own, the customer completes the payment, the funds are routed to the attacker's bank account, but your application still receives a "Success" callback and fulfills the service. The server must use an approved, hardcoded configuration for the intended product and reject any result that does not cryptographically match the order's intended merchant context.
5. Race conditions in callback and redirect handling
In many Interswitch and GT Pay architectures, the merchant receives a server-to-server webhook callback confirming payment, while simultaneously receiving the user's browser redirect confirming payment. Both endpoints update the transaction state.
We exploit this by triggering both endpoints at the exact same millisecond. If the database update logic is not wrapped in a strict transactional lock (like `SELECT ... FOR UPDATE`), both threads read the order state as "Pending", both threads process the success logic, and both threads credit the user's wallet, resulting in double-spending. Concurrency testing is a mandatory component of our payment audits.
6. Handling partial settlements and refunds
Payment architectures often break when the user pays an incorrect amount. If an invoice requires ₦50,000, but the user modifies the gateway request to pay ₦500, the gateway processes the ₦500 successfully. When the webhook arrives, the merchant backend sees a "Success" status code from the gateway.
If the backend simply updates the invoice to `Status: PAID` without verifying the settled amount against the invoice total, the attacker clears their debt for pennies. We test partial payments extensively. The correct architectural response is to mark the invoice as `PARTIALLY_PAID` or automatically initiate a refund via the provider's reversal API. Furthermore, we test refund logic to ensure attackers cannot initiate refunds for transactions they did not originate, or refund the same transaction multiple times.
Fulfillment strictly follows a verified server record
The penetration test report must show the original order, the provider reference, the verified result from the direct API query, the settled amount, the currency, the merchant context, the prior state, and the final state. A changed, replayed, failed, pending, or mismatched result must absolutely never deliver goods, credit a wallet, issue a receipt, or mark an invoice as paid. All trust must reside on the backend.
Share your gateway product, payment flow, staging environment, test merchant credentials, and order states with our engineering team.
Book an Enterprise Payment Security AuditFrequently asked questions
Why are Interswitch and GT Pay integrations more common in enterprise Nigeria than Paystack or Flutterwave?
Enterprise merchants often require direct connections to the core national switching infrastructure (Interswitch) or prefer direct bank acquirer relationships (GT Pay) for lower transaction fees on massive volumes. These legacy integrations often rely on older MAC hashing and redirect paradigms rather than modern JSON APIs.
What is a payment redirect manipulation attack?
A redirect manipulation attack changes or replays values returned through the browser after a payment completes. The merchant server must cryptographically verify the provider response, transaction reference, expected amount, currency, order owner, and final state before it delivers value.
Do Interswitch integrations require a separate security assessment from Paystack or Flutterwave integrations?
Yes. Test each integration against its actual payment flow and current provider rules. A redirect product like WebPAY needs rigorous browser return and server verification tests. Modern JSON API products need authentication, signature, replay, and state testing.
Related reading
Blog: Webhook security in Nigerian payment platforms · Securing payment gateway integrations · Business logic flaws in payment platforms
Services: Penetration testing · API security