“The Transaction Count Is Correct, Approval Logs Are Normal, But the Total Settlement Amount Keeps Being Wrong”
Payment & Settlement API Manipulation
One day after completing the monthly settlement, an accounting manager carefully raises a concern.
“Transaction counts are correct, and approval logs are normal, but the total settlement amount still does not match.”
Even after checking server logs, nothing appears abnormal.
Payment approvals are normal.
No cancellations.
No errors.
However, the numbers are gradually drifting apart.
A few hundred won, a few thousand won per day.
A tiny difference that is almost impossible to notice.
This is exactly what makes payment and settlement API manipulation attacks so dangerous.
Why Is Payment & Settlement API Manipulation the ‘Worst’ Type of Attack?
The reason this attack is critical is simple.
✔ The server continues to say everything is “normal” until the very end
• Approval requests appear normal
• Payment responses appear normal
• Logs and statistics appear normal
✔ The damage is small, slow, and accumulates over time
• Repeated theft of small amounts
• Remains unnoticed for months
• Impossible to recover once discovered
Money quietly leaks out.
Unnoticeable, but certain.
How Did the Actual Attack Happen?
The affected service was a business application integrated with POS systems, settlement processes, and tax invoice management.
The attack flow was:
1. Securing a Risky Application Environment
o Rooted devices
o Emulators
o Hooking tools running
2. Network Hooking
o HTTPS itself remains intact
o Internal app requests and responses are intercepted
3. Fine Manipulation of API Parameters
o Payment amount
o Commission rate
o Settlement amount
4. Repeated Small-Amount Theft
o A few hundred won per transaction
o Dozens of transactions per day
o Accumulated over months
From the server’s perspective, it looked like:
“A normal user made a normal payment.”
What Was the Real Security Problem?
The core issue was clear.
“The API was protected, but the application calling the API was trusted.”
Specific Security Gaps
• API calls were allowed from modified applications
• Network hooking environments could not be detected
• Request parameter integrity was not verified
• Any user with a valid login session was allowed to complete payments
In other words:
The server was secure, but the client side was exposed.
How Did LIAPP · LIKEY Defend Against It?
This problem cannot be solved simply by making server logic more complicated.
The first step is verifying:
“Under what environment was this request created?”
• Detecting rooted and emulator environments
• Detecting network hooking tools
• Verifying app memory and code integrity
• Blocking app execution in modified environments
Payment authority is determined not by login status, but by environment trust.
Changes After Security Implementation
After applying security:
• Payment and settlement mismatches were immediately stopped
• Monthly accumulated losses were prevented
• Accounting and audit risks decreased
• Settlement-related customer disputes significantly decreased
The biggest change was this:
A shift in awareness that “payment incidents may not be a server problem.”
Lessons Learned from This Case
Payment and settlement incidents usually do not look like hacking.
• No alerts
• No system failures
• Normal logs
That is why they are even more dangerous.
80% of security incidents in business applications begin not from the server, but from:
the app execution environment, inputs, and screens.
The most realistic way to protect payment APIs is to protect the “app” in front of the API first.
That is why LIAPP · LISS · LIKEY are not optional for business applications.
They become part of the operational infrastructure.
#BusinessAppSecurity #PaymentSecurity #SettlementSecurity #APISecurity #POSSecurity #TaxAppSecurity #SettlementRisk #FinancialIncident #MobileSecurity #AppSecurity #HookingAttack #APIManipulation #LIAPP #LISS #LIKEY
