API & Business Logic 101

The refund requests looked normal at first. A customer bought a $200 pair of headphones, returned them, got their money back. Standard e-commerce.

Then Marcus noticed the pattern. The same customer had "returned" those headphones 47 times in three days. Each refund went through. The customer had received $9,400 in refunds for a single $200 purchase.

The website's return portal would never allow this. It checked whether an order had already been refunded before processing a new request. But someone had figured out how to call the refund API directly, skipping the website entirely. The API itself didn't check. It just processed whatever refund request it received.

"The website has the rule," Marcus explained to the product team. "The API doesn't. They found the gap."

Forty-seven requests. Forty-seven refunds. All to the same order, all to the same credit card. The business logic that should have stopped this existed in one place but not another.

This story is fictional, but the patterns are real.

Why This Matters

If you've worked through the earlier modules on fraud basics and payment systems, you understand how money moves and what motivates criminals. This module adds a critical layer: how the software systems that move money can become targets themselves.

Every banking app, payment platform, and financial service runs on APIs. They're the invisible infrastructure connecting your phone to your money. When criminals exploit API weaknesses, they're not stealing credentials or tricking humans. They're finding flaws in the rules that govern how systems behave.

Understanding APIs won't make you a programmer. But it will help you recognize when an attack pattern points to something deeper than a compromised password.

What Is an API?

API stands for Application Programming Interface. That name doesn't help much, so think of it like a waiter in a restaurant.

You're sitting at a table (your phone) and want food (your account balance). You can't walk into the kitchen and cook it yourself. There are rules and processes.

The waiter (the API) is your go-between:

1. You tell the waiter what you want ("I'd like to see my balance")
2. The waiter takes your request to the kitchen (the bank's servers)
3. The kitchen prepares your order (looks up your account)
4. The waiter brings back either your food ("Balance: $1,247.83") or an explanation ("Sorry, we can't find that account")

In banking terms:

• Your mobile app sends requests to the bank's API
• The API asks the bank's systems for your information
• The API sends back results to display on your phone

Why APIs exist: Without them, every app would need direct access to every database. Chaos. APIs create organized channels for systems to communicate safely.

How API Requests Work

Every API transaction has four parts.

1. The Request

When you tap "Check Balance" on your banking app, the app sends a message like:

• "Give me the balance for account #12345"
• "The user logged in with token abc123"
• "This request is coming from their registered iPhone"

2. Authentication

The API checks identity:

• "Is this really John Smith?" (token verification)
• "Is this request from John's registered device?"
• "Is John's session still valid?"

3. Processing

Once identity is confirmed:

• Connect to the database
• Look up the specific account
• Check permissions
• Retrieve the requested information

4. Response

The API sends back either success ("Balance: $1,247.83") or an error ("Access denied" or "Account not found").

A Transfer Example

What you do: Open your app, tap Transfer, select accounts, enter $500, tap Send.

What actually happens:

App sends to API:
"Transfer $500 from checking #12345 to savings #67890
User: John Smith (token: abc123)"

API checks:
- Is John logged in? ✓
- Does #12345 belong to John? ✓
- Does John have $500? ✓
- Are both accounts active? ✓

API processes:
- Subtract $500 from checking
- Add $500 to savings
- Record the transaction

API responds:
"Transfer complete. New balances: Checking $1,247.83, Savings $2,847.83"

HTTP: How Computers Talk

HTTP (HyperText Transfer Protocol) is like a postal system for the internet. Every message follows standard rules, just like every letter needs an address and return address.

Request Types

What a Request Looks Like

Method: POST
URL: https://bank.com/api/transfer
Headers:
  Authorization: "Bearer token_abc123"
  Content-Type: "application/json"

Body:
{
  "from_account": "12345",
  "to_account": "67890",
  "amount": 500.00
}

Think of it like addressing an envelope:

• URL = Street address
• Method = Type of mail (regular, certified, express)
• Headers = Return address and special instructions
• Body = The letter inside

What Is Business Logic?

Business logic is all the rules that make a business work properly. It's the difference between what a system can do technically and what it should do according to policy.

Banking Rules

• "Customers can't withdraw more than their balance"
• "International transfers over $10,000 require additional verification"
• "ATM withdrawals are limited to $500 per day"
• "Savings accounts allow only 6 withdrawals per month"

E-commerce Rules

• "Discount codes work once per customer"
• "Free shipping applies to orders over $50"
• "Returns must be requested within 30 days"

Insurance Rules

• "Claims over $10,000 need manager approval"
• "You can't file duplicate claims for the same incident"
• "Policies must be active 30 days before claims are accepted"

Where Rules Get Enforced

Think of business logic like security checkpoints:

Customer Request
    ↓
Frontend (First checkpoint)
"Does this look reasonable?"
    ↓
API Gateway (Second checkpoint)
"Is this user allowed to ask?"
    ↓
Business Logic Layer (Head of security)
"Does this follow all our rules?"
    ↓
Database (The vault)
"Store it if everything checks out"

The problem: these checkpoints don't always agree. The mobile app might show you can only transfer $500, but the API might accept $50,000. The frontend might prevent negative numbers, but the backend might not check.

Authentication vs. Authorization

These terms get confused constantly. They're different.

Authentication = "Who are you?"

Proving your identity through:

• Something you know (password)
• Something you have (phone for SMS codes)
• Something you are (fingerprint)

Authorization = "What can you do?"

Like access levels in a building:

• Lobby: Anyone can enter
• Office floors: Need employee badge
• Executive floor: Need special clearance
• Server room: Need highest clearance

A customer service rep might be authenticated (logged in) but not authorized to approve wire transfers. A manager might be authorized for wires but not authorized to access another branch's accounts.

Why APIs Attract Attackers

Traditional fraud tricks humans. API fraud tricks computers directly.

What makes APIs vulnerable:

What criminals exploit:

Marcus's case from the opening? The website checked "has this order been refunded?" before allowing a return. The API just processed whatever it received. Forty-seven refunds later, a $200 order had cost the company $9,400.

Key Takeaways

• APIs are the real interface. Mobile apps and websites are just wrappers. The API is where transactions actually happen, and it's where attackers focus their attention.
• Business logic lives in layers. Rules enforced in the app might not exist in the API. Rules in the API might not exist in the database. Every gap is an opportunity.
• Authentication isn't authorization. Knowing who someone is doesn't tell you what they should be allowed to do. Many attacks exploit this confusion.
• Speed creates risk. APIs process requests in milliseconds. Attackers can attempt dozens of fraudulent transactions before anyone notices. The 47 refunds happened over three days, but each one processed instantly.
• You don't need to code. Understanding the concepts (request/response, business rules, authentication vs. authorization) is enough to recognize when something's wrong in the logs.

What's next: Business Logic Attacks covers specific attack patterns: negative value exploits, race conditions, workflow bypass, and authorization failures.

Key Terms

• API (Application Programming Interface): A structured way for software systems to communicate, like a waiter carrying requests between your app and the bank's servers.
• HTTP (HyperText Transfer Protocol): The standard format for messages between computers on the internet, including API requests and responses.
• Business logic: The rules that define how a business should operate, enforced (or not) by software systems.
• Authentication: Proving who you are (identity verification).
• Authorization: Determining what you're allowed to do (permission verification).
• Session token: A temporary credential that proves you've already logged in, so you don't need to re-enter your password for every request.
• Rate limiting: Restrictions on how many requests a user or IP address can make in a given time period.
• Parameter: A value sent with an API request, like account number or transfer amount.

---

Generated with AI assistance. Reviewed by humans for accuracy.