Security and data

This is a high-level overview of how TensorRail protects payment data and merchant accounts, written for evaluators making a diligence pass. It describes the controls at a capability level. We answer security and due-diligence questionnaires on request, under a confidentiality agreement; see Security questionnaires.

Controls at a glance

Area	Control
Transport	TLS on all API traffic, hosted checkout, dashboard sessions and webhook deliveries. Plaintext transport is not offered.
At rest	Provider account credentials, onboarding documents, bank account numbers and backups are encrypted with application-level encryption. Secrets are kept out of source code and reach each service at runtime.
Environment isolation	Test and live data never mix. The mode is carried in the API key; a mismatched key is rejected with ERR_3051.
Account isolation	Each merchant's payments, balances and reports are reachable only with that account's credentials.
Card data	Raw card data sent to the payment API is refused at payment create and confirm (ERR_2029). Hosted checkout captures card details in card fields hosted by the card processor, and the payment is made with the token those fields return.
API keys	Scopes are enforced on the account API (/v1/...). Every secret key carries the default scope set listed in Authentication; publishable keys carry no server scopes.
Browser confirm	A publishable-key confirm run from the browser needs the page's origin enabled for your account; a confirm from any other origin gets no browser access to the response.
People	Role-based access for team members.
Sensitive actions	Two-factor step-up from a dashboard session for money-adjacent operations.
Webhooks	Signed, so your server can verify origin and reject replays.
Network	Optional per-account IP allowlist. It applies to calls made with a secret rail_* key, on the payment API (/payments, /refunds and related routes) and the account API (/v1/...) alike, and to dashboard sessions, checked against the address each person connects from.
Sessions	Every open session is visible and individually revocable, with a one-action sign-out everywhere.
Audit	Account-level audit trail of who did what, readable by the merchant.

Each of these is expanded below.

Encryption in transit and at rest

• In transit. All API traffic, hosted checkout, dashboard sessions, and webhook deliveries are served over TLS. Plaintext transport is not offered.
• At rest. Provider account credentials, onboarding documents, bank account numbers and backups are encrypted with application-level encryption. Secrets are kept out of source code and reach each service at runtime.

Isolation

• Environment isolation. Test-mode and live-mode data are isolated and never mix. The mode is carried in the API key, and presenting a key whose mode does not match the resource is rejected (ERR_3051). See Authentication.
• Account isolation. Each merchant's data is isolated from every other merchant's. A payment, balance, or report belongs to one account and is only ever reachable with that account's credentials.

Card data stays off your servers

Raw card data sent to the payment API is refused at payment create and confirm (ERR_2029). Hosted checkout captures card details in card fields hosted by the card processor, and the payment is made with the token those fields return.

So when a customer pays by card, the card details are entered into those card fields, embedded in the checkout page, never into your form. Your integration works with a payment_id and a client_secret, never a card number. This holds whichever integration path you use: hosted checkout and payment links render the whole page around the card fields, and the direct-API path submits the token they return. Questions about TensorRail's own compliance posture are answered as part of a security review; see Security questionnaires.

Access controls

• Scoped API keys. Scopes are named family:level across twelve families and are enforced on the account API (/v1/...). Every secret key carries the default scope set listed in Authentication. Publishable keys carry no server scopes and can only act, together with a payment's client_secret, on that single payment. See Dashboard and account.
• Origin-restricted browser confirm. A publishable key can confirm a payment client-side only from a page whose origin is enabled for your account. The hosted checkout page is enabled for every account; your own pages are enabled on request through the account team. See Authentication.
• Roles for people. Team members are assigned roles so each person has only the access their job needs.
• Step-up on sensitive actions. Security-sensitive operations (managing API keys, changing webhook configuration, assigning team roles) require an additional two-factor step-up from a dashboard session. See Dashboard and account.
• Signed webhooks. Outbound webhooks are signed so your server can verify each event genuinely came from TensorRail and reject replays. See Handle webhooks.
• IP allowlisting. An account can nominate the address ranges its servers and its team call from. The allowlist applies to calls made with a secret rail_* key, on the payment API (/payments, /refunds and related routes) and the account API (/v1/...) alike; calls made from your customers' browsers with your publishable key are not restricted by address. Dashboard sessions are checked against the address each person connects from. It is opt-in and it takes effect immediately; see IP allowlist for the lockout hazard and how to recover. A publishable-key browser confirm is restricted separately, by origin; see the browser confirm control above.
• Session control. Open sessions are listed and can be revoked one at a time or all at once, and recent sign-in activity is summarised with first and last seen times. See Account security for what that summary shows today.

Audit trail

Account and security-sensitive actions are recorded, so who did what and when is reviewable. Recent logins and key, webhook and allowlist changes are visible to account operators from the dashboard and through GET /v1/audit, and what happens to a balance is backed by an immutable double-entry ledger. See Money integrity.

Security questionnaires

This page is intentionally high-level. We answer security and due-diligence questionnaires on request, under a confidentiality agreement. Contact TensorRail to send one.

Related

• Authentication: keys, modes, and browser-safe credentials.
• Dashboard and account: scopes, roles, and step-up.
• Account security: two-factor, sessions, recent logins.
• IP allowlist: restricting secret-key API calls to known networks.
• Team and roles: what each role may do.
• Handle webhooks: signature verification and replay protection.
• Money integrity: the ledger and reconciliation.

TensorRail, Limassol, Cyprus.