What Is OWASP - and Why Payment Platforms Can't Ignore It

Most software gets attacked for data. Payment platforms get attacked for money. That difference changes everything about how you should read security guidance - because on a payment system, a vulnerability is not a hypothetical embarrassment waiting for a breach notification letter. It is an open drawer with cash in it.

This is the first article in our OWASP for Payment Platforms series. Before we dig into the individual risks that bite payment systems hardest - broken authorization on wallet endpoints, SSRF through webhook handlers, injection in reconciliation imports - it is worth being precise about what OWASP actually is, what it is not, and why it deserves a permanent seat in your engineering process if you move money for a living.

What OWASP actually is

OWASP - the Open Worldwide Application Security Project - is a nonprofit foundation that has spent over two decades turning scattered security folklore into structured, freely available engineering guidance. It is not a vendor, not a certification body, and not a regulator. It is closer to a standards community: thousands of practitioners contributing real-world attack data and defensive patterns into documents any team can use.

Most engineers know exactly one OWASP artifact: the OWASP Top 10, the periodically updated list of the most critical web application security risks. That list matters, but treating "OWASP" and "the Top 10" as synonyms undersells what is available. The projects that matter most for a payments engineering team:

• OWASP Top 10 - the flagship list of web application risk categories: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, and so on. Think of it as the risk taxonomy.
• OWASP API Security Top 10 - a separate list focused on API-specific failure modes. For payment platforms this list is arguably more important than the classic Top 10, because a modern payment system is almost entirely APIs: merchant integrations, wallet operations, webhook callbacks, internal service calls.
• ASVS (Application Security Verification Standard) - a detailed, testable checklist of security requirements at three assurance levels. Where the Top 10 tells you what goes wrong, ASVS tells you what "done" looks like.
• Cheat Sheet Series - concrete implementation guidance per topic: session management, input validation, secrets handling, logging. The fastest path from "we know this is a risk" to "here is the pattern".

The lists are built from evidence - vulnerability databases, bug bounty submissions, breach analysis - not from committee intuition. When broken access control sits at the top of the Top 10, it is because it is the thing attackers most reliably find and exploit in the wild.

Why payments raises the stakes

Every OWASP risk category exists in every kind of application. What changes in a payment platform is the consequence profile. Three properties make payment systems a different security animal:

Exploits monetize directly. In most applications, an attacker who finds broken access control gets data they still have to figure out how to sell. In a payment system, the exploit is the payout: manipulate a transfer endpoint, replay a payout webhook, adjust a ledger balance. There is no fencing step. This is why payment platforms attract a more persistent, more professional class of attacker - the return on effort is unmatched.

Losses are immediate and often irreversible. A data breach unfolds over months of disclosure and remediation. A drained settlement account unfolds over minutes. Cross-border rails, instant payouts, and crypto off-ramps mean exfiltrated funds can be unrecoverable before your on-call engineer has acknowledged the page. The window between "vulnerability exploited" and "money gone" is the shortest of any software category.

The blast radius is contractual and regulatory, not just technical. PCI DSS explicitly references OWASP guidance as the benchmark for secure application development (requirement 6 expects development practices that address the kinds of vulnerabilities OWASP catalogs). Scheme rules, acquirer agreements, and central bank licensing regimes all assume you operate at or above this baseline. When an incident happens, "we had never heard of that risk category" is not a defensible position in front of a regulator, an acquiring bank, or an enterprise merchant's security review. OWASP is, in practice, the floor you are contractually presumed to stand on.

There is a fourth property that is easy to underestimate: trust is the product. Merchants and consumers forgive downtime far more readily than they forgive incorrect balances or unauthorized movements. A payment platform that suffers a publicized security failure loses something no incident retro can restore. The commercial cost of a breach is rarely the stolen amount - it is the churn that follows it.

How OWASP maps onto a payment platform

The infographic above shows the shape of the problem: OWASP risk categories are not abstract - each one lands on a specific zone of your architecture.

• The client and checkout surface collects the classic web risks: injection through payment form fields, cross-site scripting that skims card data, weak content security policies.
• The merchant-facing API is where the API Security Top 10 lives. Broken object-level authorization - merchant A reading or mutating merchant B's transactions by iterating IDs - is the single most common and most damaging API vulnerability class, and payment APIs are dense with object references: transaction IDs, wallet IDs, payout IDs, refund IDs.
• Webhook and callback handlers are a payment-specific SSRF and forgery hotspot. Your platform both sends webhooks (attacker-controlled destination URLs, if you let merchants register them freely) and receives them (PSP callbacks that must be signature-verified, replay-protected, and idempotent - or an attacker replays a "payment succeeded" event until your ledger believes it).
• The payment core and ledger concentrates access control and business-logic risk: privilege boundaries between support tooling and money movement, insecure design around refund and reversal flows, race conditions that the Top 10 files under insecure design but a payments engineer files under "double spend".
• PSP and bank integrations accumulate security misconfiguration: credentials with broader scope than needed, sandbox settings leaking into production, TLS and certificate validation shortcuts made during a rushed integration and never revisited.
• Monitoring and logging is where OWASP's "security logging and monitoring failures" category becomes existential. In most systems, poor logging means slow forensics. In a payment system, transaction-level observability is the fraud and intrusion detection layer. If you cannot see it, you are funding it.

If that mapping reads like an architecture review rather than a security checklist, that is the point - and it is the theme this series will keep returning to. Most OWASP findings in payment systems are not patch-level bugs. They are consequences of architectural decisions: how service boundaries were drawn, where authorization is enforced, how state transitions are guarded. That is exactly the class of problem our payment platform re-architecture work exists to fix - security review and architecture review, in payments, are substantially the same review.

What OWASP is not

Two failure modes show up in teams that adopt OWASP badly.

The first is treating it as a compliance checkbox. Scanning your codebase against Top 10 categories once a year, filing the report, and moving on misses the intent entirely. The lists are a vocabulary for continuous engineering judgment, not an annual audit artifact. The risks evolve; your architecture evolves; the mapping between them needs to be re-examined every time either one changes.

The second is assuming coverage equals safety. OWASP catalogs generic risk categories. It will not enumerate your platform-specific failure modes: the reconciliation job that trusts an uploaded settlement file, the internal admin endpoint that predates your authorization framework, the retry storm that turns a webhook replay into a ledger inconsistency. OWASP tells you where the well-known dragons live. Your architecture determines where the bespoke ones do.

Used well, OWASP is the starting grid for a payments security posture: a shared language between engineering, compliance, and external assessors, an evidence-based priority order, and a baseline no serious counterparty will let you operate below.

What's next in this series

In the next article we go from taxonomy to specifics: the handful of OWASP risks - drawn from both the classic Top 10 and the API Security Top 10 - that we see actually exploited in payment platforms, each with the concrete failure scenario and the engineering control that prevents it. Broken object-level authorization on transaction endpoints, webhook SSRF and replay, injection through reconciliation imports, and the misconfigurations that hide inside PSP integrations.

If you would rather not wait for the series to find out where your platform stands, a scoped review is faster: our architecture assessment examines authorization boundaries, integration security, and transaction observability against exactly this baseline - and tells you directly what is exposed and what to fix first.