Security
Payments infrastructure fails in expensive, public ways. This page is what we do about that, stated plainly enough that your security team can check it.
Defence in depth
Five layers, outermost first
Network
L1TLS on every connection
Application
L2Scoped keys, role-based access
Transaction
L3Velocity checks and fraud rules
Authorisation
L4Maker-checker before funds move
Data
L5Tokenised cards, AES-256 at rest
Raw card numbers are never stored — not on your servers, and not on ours.
Controls
TLS on every connection, AES-256 for stored data.
Card numbers are replaced with tokens. Raw PANs never reach your servers.
Velocity checks, blocklists and anomaly rules applied per transaction.
Maker-checker on payouts, so a single credential cannot move funds.
Every transaction, retry and state change is recorded and exportable.
Sandbox runs the same API surface as production, with no live funds.
Data
The shortest route to a smaller breach is holding less. These two lists are the whole policy.
In detail
Card numbers are replaced with network tokens at the point of capture. The raw PAN does not reach your infrastructure and is not retained on ours.
This is the single biggest lever on your own compliance scope. What you never hold, you never have to certify, secure or breach-notify.
Every connection runs over TLS. Stored data is encrypted with AES-256. Keys are managed separately from the data they protect, with rotation.
Maker-checker means one authorised user creates a payout run and a different one approves it. A single compromised credential cannot move funds.
Most payout fraud is not a broken cryptographic primitive. It is one set of credentials in the wrong hands, and a second approver is what stops it.
Velocity checks, blocklists and anomaly rules are applied per transaction rather than in a nightly batch. Patterns that look like card testing or account takeover are flagged while the transaction is still in flight.
Every transaction, retry, state change, approval and administrative action is recorded with an actor and a timestamp, and is exportable.
An audit trail is only useful if you can produce it under pressure. Ours is queryable, not archived somewhere you have to raise a ticket to reach.
Internal access follows least privilege and is limited to staff with a business need. Access to systems holding personal or payment data is logged and reviewed.
Production and sandbox are separate environments. Sandbox holds no live funds and no production data.
A certification is a point-in-time audit against a defined scope. It says an assessor checked a set of controls on a set of systems and found them in place. It does not say the provider is unbreachable, and it does not say the scope covered the thing you care about.
Ask any provider — including us — what the scope of their certificate is, and when it was last assessed. If the answer is a logo rather than a document, that tells you something.
Questions
Yes. We hold PCI DSS certification and can produce the current attestation on request. Your own scope depends on how you integrate — using tokenisation or hosted checkout keeps raw card data off your systems and substantially reduces what you have to certify.
Yes, ISO/IEC 27001 for information security management. The certificate is available on request.
Payment and KYC data relating to Indian transactions is stored in India, in line with the Reserve Bank of India's data storage requirements.
We notify the Data Protection Board of India and affected users as required under the Digital Personal Data Protection Act, 2023. No provider can promise a breach will never happen. What we can commit to is that you find out from us rather than from someone else.
Yes. Dashboard access is role-based, and payout approval can be restricted to named users independently of who can create a run.
Most enterprise buyers have one. TrustPay would rather answer it up front than three weeks into procurement.