Skip to main content

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. Detailed security documentation is available to qualified partners on request; see Requesting detail.

Controls at a glance​

AreaControl
TransportTLS on all API traffic, hosted checkout, dashboard sessions and webhook deliveries. Plaintext transport is not offered.
At restSensitive data encrypted at rest; secrets held as managed key material, not in code or configuration.
Environment isolationTest and live data never mix. The mode is carried in the API key; a mismatched key is rejected with ERR_3051.
Account isolationEach merchant's payments, balances and reports are reachable only with that account's credentials.
Card dataEntered into the processor's PCI-compliant secure fields and reduced to an opaque token before it reaches TensorRail. No card number is submitted to, stored by, or returned from your integration — or from ours.
API keysLeast-privilege scopes, enforced per call. Publishable keys carry no server scopes.
PeopleRole-based access for team members.
Sensitive actionsTwo-factor step-up from a dashboard session for money-adjacent operations.
WebhooksSigned, so your server can verify origin and reject replays.
AuditAccount-level audit trail of who did what.

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. Sensitive data is encrypted at rest. Secrets and credentials are handled through managed key material rather than stored in application code or configuration.

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 never reaches your servers — or ours​

Raw card numbers are refused at the API in every capture mode (ERR_2029). The only card shape the API accepts is an opaque token minted by the processor's own PCI-compliant secure fields, so no cardholder number reaches TensorRail at all. Questions about TensorRail's own compliance posture are answered as part of a security review — see Requesting detailed documentation.

So when a customer pays by card, the card details are entered into isolated input fields served by the licensed processor, embedded in the checkout page — never into your form, and never into a field TensorRail itself operates. Card data does not pass through your servers, and it does not pass through ours. Your integration works with a payment_id and a client_secret; TensorRail works with the token. Neither ever holds a raw card number.

This is the same principle whichever integration path you use: hosted checkout and payment links render the whole page around those processor fields, and the direct-API path submits the token they mint. It is a structural control rather than a policy one — there is no code path by which a card number could arrive.

Access controls​

  • Scoped API keys. Keys carry least-privilege scopes, named family:level across twelve families (the scopes a new key carries are listed in Authentication). A call outside a key's scopes is refused. 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.
  • 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.

Audit trail​

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

Requesting detailed documentation​

This page is intentionally high-level. For a security or compliance review, TensorRail provides detailed documentation to qualified partners under appropriate confidentiality. Contact TensorRail to request it.

TensorRail, Limassol, Cyprus.