All About Pentesting & Securing Checkouts and Transactions

In this article, I’ll walk you through my approach to pentesting payment gateways and securing checkouts. I will talk about my approach toward pentesting any features which require some monetary transactions. I am going to talk more like an attacker and at the end.

let's understand how payment gateways work or how any e-commerce application accepts payments.

Let’s assume you selected a T-shirt to buy, added it to the cart, and clicked on checkout. You then select “Credit Card” as the payment method and enter your credit card details. Since this is sensitive information, the data will be encrypted to maintain confidentiality.

Once you submit the payment, the encrypted data is sent to a payment gateway. The payment gateway then sends the data to a payment processor, which communicates with the issuing bank (the bank that issued your credit card).

On the bank’s side, the system verifies the card details and checks your account for balance, card validity, and other factors. Based on these checks, the bank decides whether to approve or decline the transaction:

If approved: The bank sends an authorization code back through the payment processor to the payment gateway, which then notifies the e-commerce platform. You will see an “Order Placed” confirmation message on your screen.If declined: You will see a “Transaction Declined” message, along with a reason for the decline, such as insufficient funds or an expired card.

Note - A payment gateway is basically like an online cashier - it gathers up your payment info and sends it off securely. Then there's the payment processor, which does all the behind-the-scenes work to move money from your bank to the merchant's bank.

Now that we’ve got the payment flow down, let’s jump into what to look out for, the potential vulnerabilities, and the best mindset to have while digging into these features.

Improper Validation of Payment Amounts / Price Tampering

So basically, what we’re doing here is changing the price parameter value to a lower or any arbitrary amount. For example, let’s say a product is listed at $100, and by intercepting the request via a proxy tool, you modify the price of this product to $1 and are able to purchase it for that amount.

What people often miss is that they only try to manipulate the primary price, but there are other parameters involved in calculating the total amount, like delivery charges, handling & platform fees, discounts, and possibly additional service fees like gift wrapping, etc.

Additionally, while trying to manipulate price check if you can make it a negative value.

what I am trying to say is that most of the developers implement strict validation on the primary amount, but they most of the time forget to implement proper validation on other parameters. so it's always worth validating other parameters too.

When we’re ordering services like food, movie tickets, etc., have you ever wondered how the application calculates the price? For example, when you choose 1 seat, it costs you $10, and when you add another seat, the price increases, right?

Well, there’s some logic written behind that to calculate the total price. While doing pentesting, it’s important to understand what that logic is, so we can try to abuse it.

A straightforward calculation might look like this:
Quantity × Price per Seat = 3 × 10 = $30
So, if you select 3 seats, you should pay $30. However, if you intercept the request and change the quantity parameter to 0.3, the application might still book 3 seats, but the bill could be calculated as 0.3 × 10 = $3.

There are other possibilities, depending on the application’s price calculation logic.

Most of the time, apps offer discounts or let users apply coupons — maybe something like 10% off the cart or a discount on specific items. Sometimes, they even let you use cashback coins or rewards. So, there are a lot of different factors that come into play when calculating the final price. Our goal here is to understand how it all works so we can try to abuse it.

Some common logic developers implement to handle discounts, coupons, and rewards

Expiration Date Check: The system verifies the current date against the expiration date of the coupon. If the coupon is expired, it won’t apply.Usage Limit: For single-use or limited-use coupons, the system checks a database flag to see if the coupon has been redeemed. Once marked as used, it shouldn’t work again.User Eligibility: Checks if the user meets the requirements (e.g., first-time user, loyalty program member, specific user group).Item-Level and Cart-Level Discounts: If an item-specific discount is applied, only eligible items get the discount. For cart-wide discounts, the total is reduced based on the cart value.Reward Points Deduction: The system reduces the total price by applying reward points or cashback, typically capped by a maximum allowed.

Some possible vulnerabilities to look at here include increasing the discount amount or applying discounts to items they’re not meant for. If there’s a first-user-only discount, see if you can still claim it even if you’re not a new user.

You can try brute-forcing coupon codes to check if they’re predictable, using expired or already-used coupons to see if they still work, stacking multiple discount tokens for extra benefits, injecting wildcard characters like * or % to manipulate the logic, or even test for a race condition to use the same coupon more than once.

Another area worth exploring is reward points manipulation. For example, see if you can use more reward points than you actually have in your account. There’s a lot you can test here, as these reward systems often have multiple possibilities of vulnerabilities.

I would always recommend you to always check some common logics of implementation and then craft your attacks, and find some business logic vulnerabilities.

Some web applications may accept testing cards, but the actual intention behind this is to use this testing card for the development test cases or debugging in a non-production environment like UAT. However, the developer may forget to disable this in the production environment.

So we should always give a check, The First thing is to identify the payment gateway that you can easily get by seeing the logo or name on the payment gateway itself. Then just google “Stripe Test Card” and read the documentation you will find the test card details, try to use it, and see if your transaction is successful.

Note - Do not report such issues if they are identified in a UAT or non-production environment, as these are often intentional configurations for testing purposes.

Still, there are multiple areas that are directly and indirectly related to payment gateways like Inventory Management, Refunds, and Rewards. I will talk in another article. The only mindset keep right now, that always to understand the backend logic keep yourself ahead of a developer, and build an attack mindmap.

I hope this is informative to you, and if you have any doubts or suggestions, reach out to me over Twitter; I’ll be happy to assist or learn from you.

Happy Hacking !

Twitter handle :- https://twitter.com/Xch_eater