Penetration testing for fintech companies
Fintech products fail where money rules meet real traffic: a withdrawal sent twice, a callback replayed, an approval changed after the checker signed it. BERRY9 engineers test those flows by hand, together with onboarding, mobile apps, partner APIs and back-office tools.
- Typical duration
- 5 to 10 working days
- Testing
- Manual, by engineers
- Report
- Executive + engineering
- Delivery
- Remote, on-site by arrangement
Last reviewed
01 / Where attackers look
What attackers go after in a fintech product
Fintech systems turn requests into money, so rules about who may do what, how often and in which order are the target.
Money movement logic
Transfers, wallet top-ups, refunds and payouts depend on rules the code must enforce every time: limits, balances, approvals and the order of steps. Testers try to break each rule with repeated, reordered and parallel requests.
Onboarding and KYC
Document upload, one-time passcodes, liveness and identity checks are all sign-up gates. We test whether a step can be skipped, replayed or answered for someone else, and what the upload handler does with a hostile file.
Mobile apps
Lending, payments and investing apps keep sessions, keys and personal data on the phone. We check storage, device binding, traffic protection, deep links and what a rooted device can change.
Partner and bank APIs
Calls to banks, payment gateways and data providers are relied on by both sides. We check signatures, callbacks, replay, allow-lists and what happens when a partner's response is late, wrong or missing.
Back-office and approvals
Staff tools approve loans, release payments and change limits. Maker-checker rules, role boundaries and audit trails are tested as carefully as the customer-facing screens.
Statements and data exports
Statements, reports and bulk exports carry the most personal and financial data in one file. We check who can request them, for whom, and how long a link works.
02 / Scope
What a fintech penetration test covers
A fintech engagement usually joins the customer apps and APIs to the staff tools and the infrastructure that links them.
| Flow or system | What we try to break | Covered by |
|---|---|---|
| Customer web application | Account access, transaction flows, limits, session handling, sign-in and recovery, and the logic around approvals and refunds | Web application testing |
| Mobile apps | Local storage, device binding, root and tamper checks, certificate pinning, deep links and outgoing traffic | Mobile app testing |
| Mobile and partner APIs | Authorization per object, replay and signature checks, callbacks, throttling and the fields each response exposes | API security testing |
| Back-office and admin tools | Role boundaries, maker-checker enforcement, audit trails and access from the office network | Web application testing and Network penetration testing |
| Cloud and infrastructure | Exposed services, storage, identities and network paths between the card or payment systems and everything else | Cloud security assessment and Network penetration testing |
| Source code | Money-handling and authorization code, secrets and dependencies, as a deeper complement to testing | Source code review |
03 / Common flaws
Business-logic flaws specific to money
We try these patterns on every product that moves value; none of them depends on a software version.
Show details for Business-logic flaws specific to money
Most serious fintech findings are not technical tricks. They are ordinary requests, sent in an order or at a speed the designers did not expect. A scanner cannot find them, because it does not know what a balance is supposed to be.
- Parallel requests. Two withdrawals sent at the same instant that both pass a balance check. Our article on race conditions explains the pattern.
- Values the app never offers. Negative amounts, fractions of a paisa, very large numbers and amounts split to stay under a limit.
- Changing a request after approval. A beneficiary, an amount or an account altered between the checker's screen and the money leaving.
- Replayed callbacks. A payment-success message from the gateway accepted twice, or accepted without checking its signature.
- Promotions and referrals. Cashback or credit that can be claimed repeatedly, or with accounts created in bulk.
- One-time passcodes. Codes with no attempt limit, codes that stay valid too long and codes that can be requested for one number and entered for another.
Limits on how often a route can be called belong to the same set of questions: see our article on rate limiting and API abuse. Because the flaws are about rules and not about versions, this work is manual, with an engineer who first learns what your product is meant to allow.
04 / Rules and partners
Regulators, banks and PCI DSS
Regulators, partner banks and card schemes decide when testing is required. The report is the evidence they ask for.
Show details for Regulators, banks and PCI DSS
Who requires what depends on your licence, your partners and the data you hold, so read your own regulator's directions and your bank or partner contracts, or ask your compliance team. Many regulated entities are expected to run security testing on a schedule, and partners often ask for the latest report before onboarding. We do not decide which rules apply to you; we produce the test and the evidence.
Card data brings PCI DSS 4.x into play, and its clause 11.4 sets a yearly rhythm for tests from outside and inside, with another round after big changes. Our PCI DSS testing page goes further. Personal data in India is covered by the DPDP Act, and the rules add breach-notification duties, summarized in our DPDP checklist. Incident reporting to CERT-In has its own clock, described in our CERT-In article.
For most of these, the test report is evidence your auditor, assessor or partner weighs, and the verdict stays with them. See how often to test for a schedule that follows your releases.
05 / How it runs
How a fintech engagement runs
Expect between 5 and 10 working days for the whole engagement, with exact dates in the proposal.
Show details for How a fintech engagement runs
Before day 1
Rules and flows
We fix the flows to be tested, name the partner systems that stay off limits, and set ceilings for test amounts and request volume. All of it goes into the proposal.
Day 1
Sandbox and accounts
You open a sandbox with test balances and give us an account for every customer and staff role. We check access and share the addresses our requests come from.
Days 2 to 7
Manual attack work
We work through onboarding, transactions, approvals, the apps and the APIs, and phone you straight away if money or personal data is exposed.
OutputProof for each finding, with the steps to repeat it
Days 8 to 9
Two reports and a call
Management, partners and auditors get an executive report; your developers get an engineering report with fixes. A walkthrough call covers both.
After your fixes
Retest
Fixed findings are tried again, and each one is marked closed or still open.
06 / Preparation
What to prepare before the test
A sandbox with test balances lets us try the dangerous cases without moving real money.
Show details for What to prepare before the test
- A sandbox or staging environment with test balances, so that transactions can be tried without real money moving.
- Accounts for each customer role and each back-office role, including a maker and a checker.
- Partner and gateway documentation, and a list of callbacks and webhooks the system receives.
- A build of each mobile app, and either a rooted handset or permission to use emulators.
- Agreed limits on amounts, volumes and testing hours.
- Agreed testing hours, and a contact who can be reached by phone during them.
Backups, notices to your provider and the other general steps are in our preparation guide. A printable checklist PDF covers the same ground in a form you can hand to your compliance team.
07 / Price and timing
Price and schedule for a fintech test
Show details for Price and schedule for a fintech test
A fintech product is not a starter scope: Every other test starts from INR 27,000 + 18% GST, climbing with the number of apps, partner integrations and back-office tools. With several apps, partner APIs and back-office tools, the proposal prices each one separately. The VAPT cost guide shows how the pieces add up.
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
08 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
Do you test transaction logic and race conditions?
Yes, they are the heart of a fintech test. In a sandbox with test balances we send repeated, reordered, parallel and out-of-range requests at transfers, top-ups, refunds, limits and approvals, and document each finding so that your team can repeat it. See the section on Business-logic flaws specific to money above.
Is a penetration test mandatory for fintech companies in India?
No single rule covers every fintech. Your licence, your regulator's directions, your bank and gateway partners and PCI DSS (if card data is in scope) decide what testing is expected and how often. Ask your compliance team or partner which applies, and tell us so the scope matches. See the section on Regulators, banks and PCI DSS above.
Can you test the mobile app and the APIs together?
Yes, and we recommend it. Most serious mobile findings sit on the server, so we test the app on the device and then test the API calls it makes directly, with and without a login. See the section on What a fintech penetration test covers above.
Will you test with real money or real customer data?
No. We ask for a sandbox or staging setup with test balances and sample data. When a check has to run in production, the written rules name the window, the limits and what we may touch. See the section on What to prepare before the test above.
How long does a fintech penetration test take?
The usual range is 5 to 10 working days, kickoff through report. Several apps, many partner integrations or intricate approval flows push it higher, and the proposal lists the dates. See the section on How a fintech engagement runs above.
Do you cover PCI DSS?
We test the systems in scope. When card data is in scope, your assessor will look for yearly external and internal tests and a retest after significant changes, and our report is one input to that judgment. Compliance is decided by the assessor, not by BERRY9. See the section on Regulators, banks and PCI DSS above.
What does the report give our partners and auditors?
An executive report for management, partners and auditors covering what was tested, how, what turned up and what was retested, plus an engineering report with proof and fixes for your developers. See the section on How a fintech engagement runs above.
Could testing disturb live payments?
We work to avoid it: sandbox first, no destructive payloads, and written limits on amounts and speed. If a production check is unavoidable, the proposal names the window and the stop conditions. See the section on What to prepare before the test above.
Plan your next security test
Tell us what needs testing and when you need it done, and we will propose a scope and timeline. We respond within 24 hours. If you would rather talk first, call or write to us.
- +91 86868 92922
- contact@berry9.com
- H.No: 8-3-945/A/12 & 13, Sri Venkata Sai Nest Apartments, Nagarjuna Nagar Colony, Yellareddyguda, Hyderabad 500073, Telangana