One payments partner could use another partner's verified sender to fund transfers
For CTOs and security leads at platforms that move money for partners.
If several partners share your platform, one lookup that forgets who is asking lets them borrow each other's checks. In a source-code security review of an embedded-payments API, one wrong import let a partner attach another partner's verified sender as a funding source, in two places.
- Fintech
- Embedded payments API
- Money
- Compliance
- Clients
- Reputation
What was at risk
Funds attached to the wrong sender
A partner could name another partner's sender when creating a receiver, so money could be mis-routed. Rated high, from reading the source.
Customer checks borrowed from someone else
The other partner's sender was already verified, so using it skips checks the first partner never passed. The review mapped this to the SOC 2 cross-tenant isolation criterion.
One database read exposes every partner
Partner API secrets were stored in plaintext. The review said a single read of that table gives away working credentials and compounds with the first flaw.
A control customers trust that does nothing
An IP allow-list could be set on a key, but nothing ever read it. A partner who set it believed the key was locked to their network.
Standards and rules in play
- SOC 2 criteria CC6.1, CC6.3, CC6.6The review mapped its findings to these SOC 2 trust criteria: logical access, authorization and cross-tenant isolation.
- CWE-798A hard-coded signing secret for service-to-service calls was classed as a hard-coded credential weakness.
Context: payment platforms usually answer to PSD2 in the EU, and to PCI DSS where card data is handled.
How we tested it
- Test level
- Static review of the source code of the payments API.
- Test types
- Security testing and white-box testing, plus regression testing of earlier findings.
- Test basis
- The source code, the partner-authorisation rules, and the findings of the previous review as a baseline.
- How we workedStatic analysisWhere it showed upSource scanning mapped to SOC 2. The unenforced IP list was shown by searching the code for any read of that column: none.
- How we workedReview against one questionWhere it showed upFor every data lookup on the path: does it carry the caller's partner? That question exposed the unscoped import, and a schema that never required the sender.
- How we workedRegression check against a baselineWhere it showed upEarlier findings were re-checked: no regressions.
Terms as in the ISTQB CTFL 4.0.1 syllabus and glossary.
What we found, and what it costs
- FindingHighReceiver creation accepted another partner's sender, in two placesWhat it costs youMoney mis-routed and verification borrowed from another partner: the worst thing a multi-partner payments product can do.
- FindingHighAPI key secrets stored and compared in plaintextWhat it costs youOne read of the table hands over working partner credentials, and it compounds with the first flaw.
- FindingMediumThe IP allow-list was never enforcedWhat it costs youPartners who set it believe their key is network-restricted. If the key leaks, it works from anywhere.
Six more findings, medium to low, among them an authentication check that could answer with a server error instead of a refusal.
What changed
The report named a fix for each finding: use the partner-scoped lookup in both places, make the sender a required field, hash secrets at rest, and enforce the IP list before showing it to customers. Nine new findings, none of them a return of an earlier one.
Can one customer of your platform reach another's money?
We review tenant isolation at the query level and tell you what each gap puts at risk. The first month is a trial.
