Security

Passwords are stored only as bcrypt hashes at cost 12, never in a form that can be turned back into the password. Nobody here can read yours, and a database copy would not yield it.

Two-factor authentication (TOTP, any standard authenticator app) is available to every account and required for privileged roles — a token issued to such an account reaches only the enrolment endpoints until a second factor exists, so the requirement cannot be walked around by ignoring the prompt.

Repeated failed sign-ins lock the account for a period that grows with the number of attempts, which is what makes password guessing impractical rather than merely slow.

Sessions are short-lived and refresh in the background, so a token that leaks is useful for a limited window rather than indefinitely. Changing your password ends your sessions everywhere else, and an administrator can revoke an account across every device at once — enforced centrally, so a device that is already holding a token stops working rather than running until it expires.

Accounts are issued by an administrator. There is no public sign-up, which removes the entire category of attacks that begins with creating an account.

All traffic is encrypted in transit over TLS, and connections are upgraded to HTTPS rather than served insecurely.

Secrets are encrypted at rest — API keys, webhook signing secrets and authenticator seeds are stored as ciphertext, not as values an operator or a database dump could read.

Our web application sets a strict Content Security Policy with per-request nonces, and refuses to be embedded in a frame — the two controls that stop injected script from running and stop the interface being wrapped by somebody else’s page.

Internal services accept traffic only from our own gateway; reaching a service port directly is refused. The gateway is the single door, so it is the single place that has to be right.

This is the part most worth being specific about: card numbers do not live on our systems.

Cards are held by a PCI DSS Level 1 certified vault provider. A card is captured directly by the vault and is sent to an acquirer directly from the vault. It does not pass through our servers in either direction, and we hold no ability to read one back — the vault’s read-the-card-back endpoint is deliberately absent from our systems rather than merely unused.

What we keep is a token, the first six and last four digits, and the card brand — enough to show an operator which card a payment used, and not enough to be a card. Our mobile app never receives card data at all.

Each tenant’s data lives in its own database, not in a shared table separated by a column. A query that forgets a filter cannot reach another customer’s data, because there is no path from one database to another.

Merchant and acquirer logins see a masked view: a merchant is never shown which acquirer processed its traffic, and an acquirer is never shown another acquirer’s. That masking is applied on the server, so it is not something a modified client can remove.

Sign-ins, configuration changes and administrative actions are written to an audit log — who did what, and when. In a payments business that is not bookkeeping: it is how a change to a live routing configuration is traced to a person, and how unauthorised access is noticed at all.

Credentials are never written to logs. Where an API key is revealed to an operator, the reveal itself is recorded, because “who has seen this key” cannot be reconstructed afterwards.

Requests are authenticated with an API key and an HMAC signature over the exact bytes you send, with a short replay window. A modified request fails the signature even when the key is valid.

Keys can be restricted to specific IP addresses, rotated with an overlap so nothing breaks mid-cutover, and revoked immediately. A key’s secret is shown exactly once, when it is created — we cannot show it to you again, which is the point.

Webhooks we send are signed, so you can verify a delivery came from us before acting on it.

If you believe you have found a security issue, please write to info@aureavia.com with enough detail to reproduce it. We will acknowledge you and keep you informed while we work on it.

Please give us a reasonable opportunity to fix an issue before disclosing it publicly. We will not pursue anyone who reports a genuine finding in good faith and does not access, modify or retain other people’s data while doing so.

We do not currently hold a SOC 2 attestation or an ISO 27001 certificate, and this page does not imply either. If that changes we will say so here, with the report available on request.

PCI DSS Level 1 refers to our vault provider, which is where cardholder data is held — it is not a certification of our own systems, and we describe it that way on purpose. A security page that overstates is worth less than one that omits, because a reader who checks one claim and finds it hollow has no reason to believe the rest.

For how we handle personal data, see the Aurea Via Privacy Policy.