Security & compliance
Built to be answered for.
Payra is designed for organisations that have to justify every action taken in their name. The controls below are structural — properties of how the platform is built, not settings an operator has to remember to switch on.
Controls
What is true by construction
Card numbers are out of scope
Payra does not store, log or return a card number. There is no code path in the platform that reads one — the single historical path was deleted along with the tool that used it. Cards are handled by reference; the regulated issuing partner holds the card data. This keeps Payra's PCI DSS (the card industry's security standard) scope small by construction rather than by policy.
Tenants are isolated at the database
Isolation is enforced by PostgreSQL row-level security, forced on every tenant table, with the application connecting as a least-privilege role that cannot bypass it. A query that arrives without the right tenant context returns nothing rather than everything. A live cross-tenant leak test runs against the real database as part of the release gates.
No agent can approve anything
The AI agents draft; they do not execute. An approval tool does not exist in the agent's toolset — not disabled, absent — so there is nothing to misconfigure. Every action that creates provider state goes through a human approval queue.
Maker is never checker
The person who raises a proposal cannot approve it. This is enforced on the server, and the interface reflects the same rule rather than merely hiding a button — a proposal's own author is told a different approver must decide.
Everything is on the record
Every state change writes an audit event and every AI call writes its own run record, to append-only tables. The trail cannot be quietly edited after the fact, which is the property that makes it worth anything to an auditor.
Strong authentication, enforced
Multi-factor authentication is required, not offered — passkeys, authenticator apps and backup codes, with account lockout and session expiry. No administrator ever sets or learns another person's password; credentials are set by the user through single-use links.
How the rules hold
A policy nobody enforces is decoration.
The difference between a security posture and a security document is whether anything stops you when you break it. In Payra, something does.
- A written constitution
- Interface, infrastructure and security rules are written down as numbered laws, published inside the product, and versioned with an amendment log.
- Machine-checked on every change
- The rules a machine can judge are enforced by an automated gate that runs locally, on commit, and in the pipeline. It blocks; it does not warn.
- Reviewed where a machine can't judge
- The rest are reviewed by dedicated automated reviewers — interface, infrastructure and security — before anything merges.
- Every escaped bug becomes a check
- When a defect reaches a test environment, the fix ships with the automated check that would have caught it, so the same class of bug cannot recur.
Status
Where we are, plainly.
Payra is pre-production and is not yet certified. The platform is built to the PCI DSS control expectations described above and is currently running in a controlled test environment. We would rather tell you that than imply a certification we do not hold — ask us for the current status and we will walk you through it.