Report sample
See how issues are written before you pay: evidence, affected flow, impact, fix notes, owner, and retest status.
Fintech penetration testing for payment apps, APIs, and mobile flows in Nigeria.
I review the parts of your product that carry trust: login, wallets, payment logic, APIs, mobile screens, admin tools, and support workflows. You get clear findings, retest support, and the documents needed to start cleanly.
payments auth admin tools api boundaries
EC-Council Certified consultant.
No 80-page PDF nobody owns.
Retest letter after fixes.
Blank templates available now.
What you get
Clear output before, during, and after the review.
You should not need to guess what the work looks like. The scope, report format, retest letter, and paperwork are all visible before you book.
Named consultant
The first page shows who is responsible for the work, what is in scope, review dates, boundaries, and client contacts.
Retest letter
When fixes go live, you get a short letter saying what passed, what did not, and what still needs another look.
Plain English for non-engineers
Founders, finance people, partners, auditors. Most of them will not read a 40-page technical report, and honestly, fair.
What we test
The review follows the money, the users, and the weird edge cases.
Penetration Testing
Web, mobile, admin
I walk the flows people actually use: signup, wallet, checkout, account settings, support tools, and the awkward admin bits nobody demos.
Vulnerability Assessment
Short list, no noise
Not a giant export. You get the issues that matter, why they matter, and where your developer should start on Monday morning.
Authentication Security
Login, OTP, sessions
Password reset, OTP, device change, refresh tokens, role checks. Boring stuff, until one loose check lets the wrong person in.
API Security
Boundaries and leakage
Tenant separation, object access, rate limits, webhooks, partner callbacks, and those tiny ID leaks that turn into serious problems.
Secure Architecture Review
The expensive stuff
Secrets, logs, cloud permissions, data movement, third-party tools, production access. The pieces that get painful to clean up later.
Why Simpa Labs
Small, direct, and allergic to security theatre.
Scope in writing
You know who is doing the review, what is included, what is off-limits, and what receipts you will receive at the end.
Findings engineers can actually fix
Each issue comes with the affected flow, proof, business risk, and fix guidance. No clever-sounding waffle.
The whole product, not one lonely endpoint
Fintech bugs like to hide between screens: mobile app, API, admin panel, support view, payment callback. So I check the joins.
Paperwork sorted early
NDA, service terms, SOW, invoice format, and testing authorization are ready before you hand over access. Less back-and-forth. Better.
The paperwork
Read the templates before you book.
Some teams ask for documents late and then everything drags. No need. These are the blank forms used before access is shared; names, dates, fees, and exact scope only go in after both sides agree.
Contracting party Akande Simpa, EC-Council Certified
Operating names Simpa Labs / AlterCore Enterprises
Contact security@simpalabs.com
Template preview Testing Authorization and Boundaries
Contracting party Akande Simpa, EC-Council Certified
Operating names Simpa Labs / AlterCore Enterprises
Client name Added after scope is agreed
Review dates Written before access is shared
Systems listed App, API, mobile flow, admin tool
Safety contact A real person on the client side
Mutual NDA Covers confidential product, technical, business, and security information shared during scoping and delivery. DOCX Service Agreement The basic business terms. Useful before anyone starts sharing access. DOCX Statement of Work What is being reviewed, when, for how much, and what counts as done. DOCX Testing Authorization Permission in writing, with boundaries, hours, contacts, and the no-drama rules. DOCX Data Handling Note How files, evidence, notes, credentials, and screenshots are handled. DOCX Retest Letter A simple confirmation after your team fixes the reported issues. DOCX Invoice / Receipt Billing details and receipt confirmation, kept plain. DOCX
Example findings
Realistic findings. Sanitised, obviously.
Client reports stay private. These examples show the style: direct, specific, and not dressed up to sound clever.
Password recovery quietly became account takeover
forgot password -> fresh session -> email change
Each feature looked normal on its own. Put together, the reset flow let a user step into an account that was not theirs. Not fancy. Very bad.
Fix this before launch
Old tokens still had too much power
login -> refresh token -> privileged action
Logout happened, but the token still worked in places it should not. The permission check was early, polite, and then absent when it mattered.
Fix in the current sprint
Customer data showed up in boring places
export file -> logs -> support view
The app was not screaming. That was the problem. Sensitive customer details were sitting in exports, logs, and a support screen too many staff could open.
Clean up before growth makes it messy
How it works
A simple route from “please check this” to “we fixed it.”
- 01
Quick scope call
We talk through the product, the deadline, the flows that matter, and the kind of receipts your buyer, board, or partner is likely to ask for.
- 02
Hands-on review
I work through login, payments, onboarding, admin actions, APIs, mobile flows, and integrations. Slowly where it matters. Fast where it does not.
- 03
Report and retest
You get the report, a plain summary, a fix walkthrough, and a retest letter after your team patches the important bits.
Contact
Send the app, deadline, and the thing keeping you up.
A short message is enough. Product type, launch date, app links if you can share them, and whether your buyer or investor already asked for a security review.