Every Payment Decision, Tested.
An authorized manual penetration test of a customer-facing invoice payment application supporting post-payment and prepayment workflows – focused on business logic, transaction integrity, access control, and server-side enforcement.
CONFIDENTIALITY NOTICE
The client identity, application name, invoice numbers, merchant identifiers, exact endpoints, transaction identifiers, payment tokens, and exploit-specific details are intentionally withheld. Findings are described at the vulnerability-class and business-impact level for public case-study use.
01. Engagement Snapshot
The client operates a payment application that allows customers to review invoice balances and complete payments using payment methods enabled by the merchant. The application also supports a prepayment workflow, making transaction integrity and server-side validation central to the assessment.
| Field | Detail |
|---|---|
| Client | [Confidential – identity withheld] |
| Platform | Customer-facing invoice payment application |
| Engagement | Manual web application and API penetration testing |
| Payment flows | Post-payment and prepayment |
| Primary focus | Business logic, access control, transaction integrity, payment-state enforcement |
| Methodology | OWASP Web Top 10, OWASP API Security Top 10, manual payment logic testing |
02. Why This Engagement
Payment applications carry risk beyond common web vulnerabilities. A control failure can affect the amount charged, invoice status, permitted payment method, surcharge calculation, customer data, or transaction ownership. These issues often sit inside business rules that automated scanners cannot understand.
The assessment therefore tested the relationships that must remain trustworthy throughout a payment: the payment link, merchant, invoice, amount, invoice status, payment method, session context, and final transaction result.
WHY MANUAL TESTING MATTERED
The highest-value questions were not simply “Is this endpoint vulnerable?” but “Can a user change a financial decision that the server should control?” That required hands-on interception, request manipulation, replay, concurrency testing, and validation of backend behavior.
03. Our Approach
CyberZEALS built and executed a payment-focused test matrix with more than 60 scenarios. Testing combined manual browser interaction, intercepting-proxy analysis, direct API validation, transaction replay, and controlled concurrency testing.
1. Transaction & amount integrity
Full-payment validation, partial payments, prepayment values, zero/negative amounts, precision, overpayment, and multi-invoice totals.
2. Authorization & object access
Invoice/payment identifiers, merchant context, receipt access, session binding, and IDOR/BOLA-style authorization checks.
3. Payment-state & method controls
Expired, cancelled, and already-paid invoices; card/ACH enablement; server-side enforcement of merchant payment settings.
4. Surcharge & business logic
Surcharge removal, under-calculation, rounding/threshold behavior, and consistency across payment flows.
5. Replay, race conditions & privacy
Duplicate-payment conditions, stale balances, concurrent submissions, receipt/email behavior, input validation, caching, and sensitive-data exposure.
04. How the Engagement Ran
Phase 1 – Flow mapping & scoping
Mapped post-payment and prepayment journeys, invoice states, payment options, surcharge behavior, receipts, and trust boundaries.
Phase 2 – Active manual testing
Intercepted and modified payment traffic to test whether backend controls remained authoritative when the client was manipulated.
Phase 3 – Reporting & remediation guidance
Documented confirmed issues with severity, business impact, technical impact, evidence, and practical remediation steps prioritized by financial risk.
05. Findings & Results
The assessment identified 10 confirmed findings across payment integrity, business logic, access control, invoice lifecycle, concurrency, surcharge handling, and input validation. The severity distribution reflects the potential financial and privacy impact of each issue.
CRITICAL : 1
HIGH: 3
MEDIUM: 3
LOW: 3
| ID | Finding category | Severity | Public case-study summary |
|---|---|---|---|
| F-01 | Payment Amount Manipulation in Prepayment Workflow | Critical | A client-controlled amount could be reduced while the payment workflow still reached a successful invoice state, creating direct revenue and reconciliation risk. |
| F-03 | Expired Payment Link Validation Bypass | High | The backend accepted a payment attempt after the payment link had expired, showing that expiry was not consistently enforced server-side. |
| F-04 | Cancelled / Already-Paid Invoice Validation Bypass | High | Old payment context could remain usable after an invoice entered a non-payable state, creating risk of unwanted or duplicate payments. |
| F-06 | Payment Method Restriction Bypass | High | Client-side payment-option flags could be manipulated to expose a disabled payment method when the backend did not independently enforce merchant configuration. |
| F-02 | Race Condition – Duplicate Invoice Payment | Medium | Concurrent requests could reach payment processing against the same invoice state, creating duplicate-charge and reconciliation risk. |
| F-05 | Partial-Invoice Overpayment | Medium | Near-simultaneous payments against the same outstanding balance could exceed the amount actually remaining. |
| F-07 | Surcharge Bypass | Medium | A rounding or minimum-value edge case allowed an eligible transaction to avoid the expected surcharge. |
| F-08 | Billing Field Input Validation Weakness | Low | Billing fields accepted a broader character set than required, weakening data quality and downstream input safety. |
| F-09 | State/Country Input Validation Weakness | Low | Location parameters accepted unrestricted special characters rather than validated values or codes. |
| F-10 | Receipt Authorization Bypass | Low | Receipt access relied on client-controlled context without sufficiently binding the receipt to the authorized merchant context. |
DISCLOSURE LEVEL
Exact payloads, endpoint paths, invoice identifiers, payment tokens, and client-specific exploit steps are deliberately excluded from this publication draft. The table communicates the security class and business significance without exposing operationally sensitive details.
06. Representative Security Lessons
Payment amount integrity must be server-authoritative
The critical prepayment finding demonstrated why the browser must never be the source of truth for financial amounts. The server should load the current invoice balance, validate what is payable, bind the processor transaction to that value, and only update the invoice after the expected amount is verified.
Payment state must be checked at the moment of payment
Expired, cancelled, and already-paid invoices were treated as dedicated attack scenarios. A page that was once valid can become invalid while it remains open, so the backend must re-check the latest invoice and payment-link state immediately before authorization or capture.
Concurrency is a payment-security control, not only a reliability concern
Race-condition testing showed the importance of idempotency, locking, and atomic balance validation. Parallel requests must not be able to consume the same invoice state or create more than one successful payment for a single intended transaction.
Merchant configuration must be enforced by the backend
Payment-method options presented by the frontend should be considered display information only. The server must independently verify that the selected method is permitted for the merchant and invoice before creating or completing a payment.
Surcharge and receipt logic deserve the same scrutiny as payment capture
Fee calculations and receipt access can create financial or privacy impact even when the underlying card transaction is valid. Server-side surcharge calculation, strict object authorization, and validated transaction ownership are therefore part of the payment trust boundary.
07. Business Impact
- Direct revenue loss when an invoice can reach a paid state without the expected settlement amount.
- Duplicate charges, overpayments, refunds, chargebacks, and customer disputes caused by concurrent payment processing.
- Invalid payments against expired, cancelled, or already-settled invoices.
- Bypass of merchant payment restrictions and fee rules when client-side configuration is trusted.
- Exposure of payment receipt information when object-level authorization is incomplete.
- Reconciliation and support overhead caused by inconsistent payment, invoice, and transaction states.
08. Remediation Priorities
1. Recalculate financial values server-side
Ignore client-submitted authoritative amounts. Retrieve the current invoice balance and calculate payable values and surcharges from trusted server-side state.
2. Bind the complete transaction context
Validate merchant, payment link, invoice, current amount, allowed method, session, and payment transaction as one trusted context.
3. Enforce an explicit invoice state machine
Allow payment only from approved payable states and invalidate old sessions or payment context when an invoice expires, is cancelled, or is fully settled.
4. Add idempotency and atomic concurrency controls
Use unique payment-attempt records, idempotency keys, transaction locking or atomic compare-and-update logic, and callback deduplication.
5. Apply object-level authorization everywhere
Validate ownership and merchant context on receipts and other transaction objects; never make authorization decisions from a client-controlled header alone.
6. Harden validation at API boundaries
Use strict schemas, allow-lists, length limits, and consistent server-side validation for billing and location fields.
METHODOLOGY COVERAGE CONFIRMED
The engagement combined OWASP Web Top 10 and OWASP API Security Top 10 coverage with dedicated payment-business-logic testing, including IDOR/BOLA scenarios, amount manipulation, payment-state bypass, payment-method bypass, surcharge bypass, replay, and concurrency testing.
09. Capabilities Demonstrated
- Manual web application and API penetration testing for payment systems
- Business logic and transaction-integrity testing across post-payment and prepayment flows
- OWASP Web Top 10 and OWASP API Security Top 10 coverage
- IDOR/BOLA and receipt/object authorization testing
- Price and payment-amount manipulation testing
- Payment-state, payment-method, and surcharge bypass testing
- Race-condition, replay, idempotency, and overpayment testing
- Professional risk-ranked reporting with business impact and remediation guidance
The key takeaway
Payment security is not limited to protecting card data. The application must preserve the integrity of every decision that moves money – who can pay, what can be paid, how much is due, which method is allowed, which fees apply, and whether the transaction is still valid at the exact moment it is processed.
PUBLICATION NOTE
This case study is intentionally anonymized for external use. Before publishing, confirm that the final wording and redaction level meet the client confidentiality requirements that apply to the engagement.