The payment page showed ₹1.00. I had not touched the price field. I had only touched one number in one request.

I was not looking for a vulnerability that day.

I was clicking around a government website — an official portal where students could buy books published by government bodies. Study material, reference texts, the kind of dense, official content you’d find in competitive exam prep stacks. The kind of website that nobody thinks to test because it’s government, it’s boring, and what’s the worst that could happen with a bookstore?

I had Burp Suite running in the background. Force of habit.

I picked a book. Added it to the cart. Clicked checkout. Filled in fake billing details — Lord, Hello World, 9999999999, a pincode that doesn’t exist, an email with a typo in the domain. The kind of information you enter when you’re testing a flow and have no intention of completing the purchase.

Then I clicked Pay Now.

Burp caught the POST request before it hit the server.

The endpoint was /ccavRequestHandler. The request body had sixteen parameters: order_id, billing_name, billing_tel, billing_email, billing_address, billing_city, billing_state, billing_zip, billing_country, merchant_id, language, currency, redirect_url, success_url, cancel_url — and one more.

amount=1599

I stared at that for a moment. Then I changed it to 1.

Not ₹100. Not ₹10. ₹1. I wanted to see how far this would go.

I forwarded the request.

The payment page loaded.

In the top-left corner, in blue text:

INR 1.00 (Total Amount Payable)

The payment gateway had received a transaction request for ₹1. It had no reason to question this. As far as the gateway was concerned, a legitimate merchant server had just told it: this order costs one rupee. Process it.

The “Make Payment” button was right there. Accepting American Express, Mastercard, RuPay, Visa.

I turned off the intercept and refreshed the page. ₹1.00 was still showing. This was not a rendering artifact. The transaction session had been created at ₹1. The gateway was waiting for me to pay one rupee for a ₹1,599 book.

I did not proceed with the payment. I had enough.

Here is the architecture failure underneath this:

The government portal was treating the amount field in the checkout POST request as a trusted user-supplied value. The merchant ID, the order ID, the item itself — all server-side. But the price? Client-side. Passed through the browser. Interceptable. Modifiable. No validation on the server before it was handed to the payment gateway.

This is a business logic vulnerability — not an injection, not a bypass, not a CVE with a complicated name. No payload. No encoding. I opened Burp Suite, found a number, and changed it. That was the entire attack.

The assumption the developers had made — one that gets made constantly on Indian e-commerce platforms — was that a normal user would never look at the raw HTTP request. And they are right about normal users. Normal users do not run Burp Suite. But an attacker does.

Think about what this looks like at scale.

This was a government portal that sold books to students — students preparing for government exams, students buying prescribed reference material, students on tight budgets who were likely the exact demographic this portal existed to serve.

Every book in that catalog. Any user with a proxy tool. Any price they chose.

The gateway had no way to cross-reference the amount it received against the actual product price on the backend. There was no order validation webhook, no server-to-server price confirmation, no check that said: “Wait — this order was created for ₹1,599. Why are you asking us to collect ₹1?”

In a commercial platform, that’s a revenue leak. In a government portal distributing official study material, that’s a publicly funded resource being made freely exploitable. Not hypothetically. Actually, directly, by anyone willing to spend five minutes with an intercept proxy.

I reported it.

The address was [email protected] — the Responsible Vulnerability Disclosure Program run by India's National Critical Information Infrastructure Protection Centre. I wrote up what I'd found: the endpoint, the vulnerable parameter, the steps to reproduce, the screenshot of the ₹1 payment page. I sent it off.

I wasn’t sure what to expect. Government VDPs in India have a reputation for silence. Not because no one cares — but because the pipeline from researcher inbox to development team is long, and the process isn’t always visible from the outside.

A reply came.

They acknowledged the finding. The vulnerability was taken seriously. The fix was deployed.

That was it. No bounty — this was a responsible disclosure program, not a bug bounty program. No CVE. No hall of fame that I was aware of. But the issue was fixed, and the portal was no longer accepting arbitrary amounts from the client side.

That’s the complete story. And I keep the screenshots.

I’m writing this in 2026. The original finding was in 2024.

This was one of the first vulnerabilities I ever found on a real system. The reason I’m writing it now is not to demonstrate technical sophistication — the technique is not sophisticated. It’s to demonstrate what is possible when you simply look at what is being sent.

Most beginners spend months learning injection techniques, bypass methods, escalation chains. They overlook the simplest question: is the server trusting something it shouldn’t? A price. An account balance. A discount code. A session duration. Any value that the application treats as authoritative but originates from the client is a candidate for this exact test.

I found this because I had Burp running as a habit. Not because I had a methodology document open. Not because I had targeted this site specifically.

If you’ve been testing web applications for more than a few months, you have almost certainly seen a parameter that controls value — price, quantity, role, discount percentage, account tier — passed through the browser. Did you test it?

And if you find something like this in 2026: India’s national bug disclosure is at cert-in.org.in