The specific attack surface of legacy payment gateway integrations
Interswitch Webpay and GT Pay use a payment model that is architecturally different from modern REST API gateways. Instead of webhook callbacks with HMAC signatures, they use form-based redirect flows: the merchant's website constructs a payment form that redirects the user to the gateway's hosted payment page. When the payment completes, the gateway redirects back to the merchant with a result encoded in URL parameters and protected by a hash. The merchant validates the hash and fulfills the order.
This redirect-and-hash model has specific vulnerabilities that do not apply to webhook-based modern gateways. The hash protects against parameter tampering — but only if it is correctly computed and verified. If the merchant validates the hash incorrectly, skips validation, or trusts parameters that are not covered by the hash, the entire security of the transaction result verification collapses.
1. Payment redirect hash validation testing
After a Webpay or GT Pay transaction, the gateway redirects back to the merchant's redirect URL with parameters including the transaction reference, amount, response code, and a hash value. The hash is computed over a subset of these parameters using a shared secret key. We test whether the merchant's backend: (a) validates the hash at all, (b) validates the hash using the correct algorithm and parameter order as specified in the gateway documentation, (c) uses the amount from the redirect URL to determine whether a payment was successful rather than from their own database, and (d) accepts successful-looking redirect parameters even when the response code indicates a failure.
2. Transaction reference enumeration and replay
Interswitch transaction references follow predictable formats in many older integrations. We test whether the merchant's backend accepts a previously used transaction reference in a new order fulfillment request, whether transaction references from other merchants' transactions can be submitted to claim goods on a different merchant's platform, and whether the gateway's own transaction query API can be called with an enumerated reference to obtain another customer's payment details.
3. Amount manipulation between order creation and gateway redirect
In a Webpay integration, the merchant constructs the payment form with the order amount and sends the user to the gateway. We test whether the amount field in the form is a hidden field that can be modified by an attacker before the form is submitted. If the amount is in a client-side form field without server-side validation of what the actual order total should be, an attacker modifies the amount field downward, completes a payment for the lower amount, and the gateway redirects back with a successful payment for the manipulated amount. The merchant sees a successful payment response and fulfills the order.
4. GT Pay institution code and merchant ID exploitation
GT Pay integrations use an institution code and product ID to identify the merchant and the payment product. We test whether these identifiers can be manipulated to route a payment intended for one merchant to a different merchant's settlement account, whether the product ID controls which bank account the settlement goes to, and whether a valid session on one merchant's GT Pay integration can be used to initiate payments credited to a different merchant's settlement account.
5. Interswitch Quickteller API authentication testing
Beyond the web redirect interface, Interswitch provides a Quickteller API for direct bill payment, airtime top-up, and utility payment integrations. We test this API for: authentication token entropy and expiry enforcement, whether the API returns transaction data for reference numbers not belonging to the authenticated client, and whether the bill payment API can be used to query customer account balances on utility platforms by enumerating account numbers.
Amount field modified client-side, gateway accepted reduced payment as successful
During a penetration test of a Nigerian e-commerce platform using Interswitch Webpay for payment processing, we identified that the payment amount was passed to the gateway as a hidden form field in the merchant's checkout page. We modified the hidden field value from the order total of 150,000 naira to 1,500 naira using browser developer tools before submitting the form. The Webpay gateway processed the payment for 1,500 naira, returned a success redirect with a valid hash for the 1,500 naira transaction, and the merchant's backend — which validated only the hash and the success response code, not the amount against the original order — fulfilled the full 150,000 naira order for a payment of 1,500 naira. Fix priority: critical. Remediated by storing the expected order amount server-side at order creation, then comparing the amount in the gateway redirect response against the server-stored amount before fulfilling any order, rejecting the fulfillment if the amounts do not match.
Running an Interswitch Webpay, Quickteller, or GT Pay integration in Nigeria? Book a security audit of your payment validation logic before a redirect manipulation causes a financial loss.
Book an Enterprise Payment Security AuditFrequently asked questions
Why are Interswitch and GT Pay integrations more common in enterprise Nigeria than Paystack or Flutterwave?
Interswitch and GTBank's GT Pay are deeply embedded in Nigerian enterprise and government payment infrastructure. Large corporations, government agencies, and institutions that began accepting card payments in the 2000s and 2010s built on Interswitch Webpay and the Quickteller network. Many of these integrations have never been updated and run on older security configurations. GT Pay is particularly common for payments to government agencies, utilities, and large institutional merchants.
What is a payment redirect manipulation attack?
Interswitch Webpay and similar gateway integrations redirect users from the merchant's website to the gateway's payment page and back. The redirect carries a transaction result and a hash that is supposed to prevent tampering. If the merchant's backend validates the hash incorrectly, or uses the transaction amount from the redirect URL rather than from their own database, an attacker can manipulate the redirect to make a failed or partial payment appear successful — claiming goods or services without full payment.
Do Interswitch integrations require a separate security assessment from Paystack or Flutterwave integrations?
Yes. The attack surface of Interswitch Webpay and Quickteller is different from REST API gateways. Interswitch uses a form-redirect model with hash-based result verification. The vulnerabilities are in hash computation, redirect parameter trust, and merchant-side result validation — not in webhook signature verification. An assessor who only knows modern REST gateway patterns will not know what to look for in a Webpay integration.
Related reading
Blog: Webhook security in Nigerian payment platforms · Securing payment gateway integrations · Business logic flaws in payment platforms
Services: Penetration testing · API security