A full PCI-DSS focused security assessment of NovaPay Solutions — a FinTech payment processor handling merchant onboarding, card-present and card-not-present transactions, settlement operations, and chargeback workflows. We found plaintext PANs in the database, CVVs stored post-authorization, hardcoded API keys in client-side JavaScript, and a CSRF vulnerability on the payment transfer endpoint that enabled unauthorized fund movement.
NovaPay Solutions is a FinTech payment processor serving 340 merchants across e-commerce, retail POS, and recurring billing verticals. The platform handles merchant onboarding with MCC code assignment and risk tier classification, processes card-present and card-not-present transactions through a proprietary gateway, manages a card vault for tokenized recurring payments, and operates settlement and chargeback workflows that move real funds between merchant and issuer accounts.
Our engagement began as a PCI-DSS readiness assessment ahead of NovaPay's annual QSA audit. Within the first 3 hours, we discovered that Primary Account Numbers (PANs) were stored in plaintext in the transactions database — no tokenization, no encryption, no masking. The card vault, designed to securely store card data for recurring billing, was also storing full CVV/CVC codes post-authorization, a direct and unambiguous PCI DSS 3.2.2 violation.
The merchant portal contained a SQL injection vulnerability in the search function that gave us direct read access to every merchant's transaction history, settlement records, and cardholder data. Stripe API secret keys were hardcoded in frontend JavaScript, visible to any user inspecting the page source. The payment transfer endpoint — which moves funds between accounts — had no CSRF protection, meaning a crafted link could silently initiate unauthorized fund transfers from any authenticated merchant session.
Over a 4-day engagement, we catalogued 25 findings across merchant operations, payment processing, settlement, and compliance domains. All findings were mapped to PCI DSS v4.0 requirements, SOC 2 Type II criteria, and NIST 800-53 controls. Critical infrastructure remediation was completed within 48 hours.
6 Critical, 7 High, 12 Medium — spanning cardholder data exposure, payment flow manipulation, merchant portal exploitation, and compliance infrastructure gaps. Every finding mapped to PCI DSS v4.0.
transactions table. No tokenization, no column-level encryption, no data masking. A single database query returned full 16-digit card numbers for every transaction processed in the last 18 months — over 2.1 million cardholder records immediately accessible.Implement tokenization via a PCI-compliant vault (Stripe, Basis Theory, or VGS). Encrypt all existing PANs with AES-256. Truncate stored PANs to first-6/last-4 for display. Implement key management with HSM-backed CMKs.
Purge all stored CVV data immediately. Modify card vault to never persist CVV after authorization response. Implement automated PAN-scan tools to detect any future CVV storage. Update QSA documentation to reflect remediation.
sk_live_*) were embedded directly in the merchant portal's client-side JavaScript bundle. Any user inspecting page source had full access to create charges, issue refunds, transfer funds, and read all customer payment data through Stripe's API. The keys had been in production for 9 months with no rotation.Rotate all exposed Stripe keys immediately. Move all payment API calls server-side. Use only publishable keys (pk_live_*) in frontend code. Implement pre-commit hooks to scan for secret patterns.
' UNION SELECT pan,cvv,expiry FROM cards-- returned full cardholder data from the card vault. We demonstrated extraction of all merchant records, transaction histories, settlement amounts, and internal admin credentials — all from the unauthenticated search field.Replace all string-concatenated queries with parameterized prepared statements. Implement input validation and WAF rules. Restrict database user permissions to minimum required. Enable query logging and anomaly detection.
POST /api/transfers endpoint accepted authenticated requests with no CSRF token validation. A crafted HTML page — delivered via phishing or XSS — could silently initiate fund transfers from any authenticated merchant session. We demonstrated moving $10,000 between merchant accounts using only a hidden form auto-submit, with no user interaction required beyond visiting the page.Implement CSRF tokens on all state-changing endpoints. Use SameSite=Strict cookies. Add re-authentication for high-value transfers. Implement transfer velocity limits and anomaly detection alerts.
raw_transaction_data column. PCI DSS 3.2.1 prohibits storing track data after authorization. Track data contains everything needed to clone a physical payment card — 340 merchants' in-store transactions over 6 months provided a card cloning dataset for tens of thousands of cards.Purge all stored track data immediately. Modify POS integration to strip track data after authorization response. Implement automated scans to detect any sensitive authentication data in storage. Add column-level monitoring.
merchant_id parameter, any authenticated merchant could view, respond to, and accept chargebacks belonging to other merchants. We accessed chargeback details — including cardholder names, transaction amounts, and dispute reasons — for all 340 merchants from a single test account.aws s3 ls confirmed public read access to all objects.?api_key=sk_live_...) instead of request headers. API keys appeared in web server access logs, CDN logs, browser history, and referrer headers. Every intermediary between the merchant and NovaPay could read the authentication credentials — a violation of PCI DSS transport security requirements.cards, transactions, and settlements tables), which directly aided the SQL injection exploitation.Every finding was mapped to the frameworks that apply to payment processors handling cardholder data, merchant financial information, and fund settlement operations.
Watch us walk through the NovaPay findings live — demonstrating the SQL injection exploit chain, plaintext PAN extraction, CSRF fund transfer, and webhook forgery attack. Coming soon.
Complete audit walkthroughs across different industries and threat profiles — each covering a distinct compliance framework and attack surface.
If you're processing payments, PCI-DSS compliance isn't optional. We'll find what your QSA will find — before they do.