“The Worst Incident: Payment Is Normal, But the Money Is Wrong”

Payment, Billing, and Point API Manipulation

“Everything looks normal in the payment system… so why are the numbers wrong?”

The settlement team was the first to notice something unusual.

The revenue graph was clearly increasing, but the actual deposited amount was gradually falling short.

At first, they suspected:

• A card processing fee issue?
• A delay from the payment gateway provider?
• An internal accounting error?

Everything was checked, but server logs and payment approval records were all marked as “normal.”

Then, after one month, that “small difference” had grown into tens of millions of won.

This was the beginning of a payment, billing, and point API manipulation incident.

Why Is This Incident So Dangerous?

There are many types of payment-related incidents, but this type is especially dangerous for one reason:

The server continues to believe that the requests are legitimate until the very end.

• Payment approval appears normal
• API responses appear normal
• No abnormal logs are generated

As a result, detection becomes extremely difficult.

Attackers also:

• Do not steal a large amount at once
• Take small amounts quietly over a long period

➡ Financial damage + highest detection difficulty
That is why this type of attack ranks as TOP 2.

Real API Manipulation Attack Scenario

The lifestyle app operated both point payments and in-app payments.

The attack flow was as follows:

1. Network Hooking

o Intercepting API traffic in a modified application environment

2. Fine Manipulation of API Parameters

o Adjusting payment amounts and deducted point values

3. Distorting Deduction After Payment Approval

o PG payment approval remains normal
o Only the actual user deduction amount is modified

The user sees “Payment Completed,” and the server records “Approved.”

However, only the numbers are slightly changed as the transaction proceeds.

What Was the Core Security Problem?

The essence of this incident was not server security.

It was a client trust problem.

Specific Problems

• API calls were allowed even from modified apps and hooking environments
• Client-provided payment amounts were trusted directly
• Normal users and manipulated users could not be distinguished
• No detection criteria existed for repeated small-value attacks

In other words:

The biggest security weakness was assuming that “a normal API request means a normal user.”

How Did LIAPP Defend Against It?

After the incident, the service reviewed the app execution environment before changing the payment architecture.

LIAPP – Blocking Modified and Hooking Environments

• Detecting network hooking and proxy usage
• Verifying app integrity (blocking repackaged and modified apps)
• Blocking execution when memory manipulation or API hooking is detected
• Detecting automated and script-based requests
• Automatically blocking suspicious users

Preventing payment APIs from being called in manipulated environments.

Detecting “small but repeated theft” through behavior data.

Even if an account exists, suspicious environments cannot move money.

Changes After Security Implementation

After applying security:

• Payment amount mismatches were completely prevented
• Point abuse cases significantly decreased
• Settlement and audit risks were resolved
• External audit response time was reduced

The most important change was this:

The belief that “protecting the server is enough for payment security” completely changed.

Lessons Learned from This Case

Payment incidents always begin with very small numbers.

• 100 won
• 200 won
• 500 won

But if ignored, those numbers can threaten company trust and business continuity.

The core of payment security is not the amount.

It is the reliability of the request.

That trust can only be protected by verifying:

• Whether the app is legitimate
• Whether the environment is secure
• Whether a real person is operating it

Payment APIs must be protected from the app level, not only the server.

#LifestyleApp #PaymentSecurity #APIManipulation #PointAbuse #InAppPayment #FinancialIncident #MobileSecurity #AppSecurity #SettlementRisk #AuditResponse #SecurityIncidentCase #HookingAttack #LIAPP #LISS #LIKEY