A story about curiosity, business logic flaws, and the painful ending of a duplicate report π
Bug bounty hunting always starts the same way for me: I open the target, explore the visible features, and click around like a normal user. Sometimes the most interesting bugs don't hide deep inside the application. They're sitting right at the front page at the bottom, waiting for someone curious enough to notice them π
And that's exactly how this story began.
π The Front Page Recon
While checking all the functions available on the front page, I found a button called "Group-Discount."
At first, it looked like a normal feature for customers who wanted to buy premium items in bulk. Nothing too suspicious. But features involving discounts, pricing, subscriptions, or bulk purchases always catch my attention, because business logic bugs often love to hide there.

So I decided to test it.
I filled in all the required information and started adding products into the order. Since this feature was clearly meant for bulk purchases, I inserted more than 5 premium products to simulate a realistic group purchase.
Everything still looked normal on the surface.
But then I decided to go one step deeper.
π οΈ Intercepting the Flow with Burp Suite
Once I had gone through the form, I intercepted the traffic using Burp Suite and started reviewing the requests one by one.
I wasn't rushing. I slowly checked each request and response, looking for anything unusual.
Then I found one response that immediately stood out.
It contained information about the endpoint for processing order if purchase successful

That was the moment things started getting interesting π
π Opening the URLsβ¦ and Finding Something Strange
Naturally, I opened the URLs that were returned in the response.
And to my surprise, one of them led me to a page that looked very unusual and very surprising. It didn't feel like a normal customer-facing step in the purchase process. It looked like I had reached part of the workflow that wasn't supposed to be accessed this way.

At this point, I knew I had to keep following the flow carefully.
A few minutes later, I received an email containing codes for purchasing the products.

The email also included some notes and rules, including a reminder that I needed to untick auto-renewal. So I followed the instructions exactly as provided and continued the process.
And then came the moment that made me stop and stare at the screen.
π³ Waitβ¦ The Total Became $0
After I entered the code from the email into the checkout page, the system showed that I only needed to pay: $0

That was the moment I realized this might actually be a payment bypass.
I was honestly shocked.
A premium product. A real checkout flow. And somehow⦠no payment required.
It felt unreal for a second.
π³ No Card Details. No Payment. Still Successful.
I moved to the next page expecting the platform to ask for card details or some kind of payment verification.
But nothing appeared.
No card information. No payment prompt. No billing confirmation.
So I completed the checkout.
And it worked.
A confirmation email arrived, telling me that the purchase had been completed successfully. When I checked my account's purchase history, the platform showed the item as paid.

That was it.
I had managed to get access to a premium course/product for free through a flaw in the application's business logic.
And honestlyβ¦ that feeling was wild π€―
π Writing the Report
As soon as I confirmed the impact, I started writing the report.
I documented:
- the affected functionality.
- the flow I tested.
- the impact of the issue.
- and the evidence showing that the premium product could be acquired without payment.
I submitted everything and waited for a response, feeling pretty excited.
Because let's be real β finding a bug that affects payment logic is always a great feeling π₯
π© The Twist: It Was a Duplicate
A few days later, I received the response.
And that's where the story changed.
The report was marked as a duplicate.
Someone else had already reported the exact same issue about one month earlier.
That part hurt π
After all the excitement of finding the bug, validating it, and writing everything up⦠it ended with the classic bug bounty heartbreak:
"Thanks for your report, but this issue has already been reported."
Pain. Pure pain.
π― What I Learned from This Bug
Even though the report ended as a duplicate, this finding still taught me a lot.
1. π§ Business logic bugs are everywhere
You don't always need a complex exploit chain. Sometimes the most impactful vulnerabilities come from simply understanding how the product is supposed to work β and then noticing where the logic breaks.
2. π° Pricing and discount features deserve extra attention
Any feature involving:
- discounts
- coupons
- bulk purchases
- subscriptions
- promo codes
- or checkout logic
can become a goldmine for high-impact vulnerabilities.
3. β³ Timing matters in bug bounty
Finding the bug is one thing. Reporting it before anyone else does is another battle entirely.
That's the reality of bug bounty hunting.
π Final Thoughts
This bug started with nothing more than a button on the front page: "Group-Discount."
What looked like a simple bulk-purchase feature turned into a payment bypass that allowed me to purchase a premium product for free.
Even though the report was ultimately marked as a duplicate, the experience was still worth it. Every bug teaches something. And this one reminded me that sometimes the most valuable findings come from the most ordinary-looking features.
The bug was real. The impact was real. The lesson was real too. In bug bounty, skill matters β but timing matters just as much. β°
Thanks For Reading!
Connect me: