Skip to main content

Changelog

Notable changes to the TensorRail API and its documentation. Newest entries are at the top.

Each entry is dated and describes what changed in the public API surface. Branch your integration on stable identifiers, status values and error.code, never on message text, so additive changes never break you.

2026-08​

Your API key's environment now decides which money it touches. GET /v1/balances returns only the key's environment (a test key reads test balances, a live key live balances), and POST /v1/payment-links/prepare creates a link in the key's environment. An explicit mode / live_mode that contradicts the key is refused with the new ERR_3051 (mode_mismatch, HTTP 422) instead of being reinterpreted. Dashboard sessions keep the explicit environment toggle. If you relied on a live key defaulting to the test environment (almost certainly a bug, not a choice), update your integration. See Balances.

Balances are per currency, per environment. Test and live money are held and reported separately for every currency. The balances array entries and the top-level snapshot carry a live_mode label, so test money and real money can never be read as one number.

Payment links from the API are valid for 24 hours and accept an optional return_url.

Webhook retries are re-signed at send time. Every delivery attempt — including automatic and manual retries — now carries a TensorRail-Signature whose timestamp is the moment of that attempt, so the documented 5-minute freshness check passes on retries. If you had relaxed or skipped the freshness check to accept retries, you can (and should) enforce it strictly again.

GET /v1/webhooks/config response narrowed. The endpoint now returns exactly what was documented: webhook_details, payment_response_hash_key_set, and profile_id. Previously it also carried unrelated profile configuration fields; integrations reading only the documented fields are unaffected.

Documentation: one site. The developer documentation and the platform guides now live together on this site.

2026-07​

Initial published version of the v1 API.

The first publicly documented release of the TensorRail API. It covers the full payment lifecycle on one base URL, https://api.tensorrail.com, with your key selecting the environment.

  • Payments. Create, confirm, retrieve, update, capture, cancel, and list payments. The merchant-visible payment object carries payment_id, status, amount, currency, client_secret, next_action, and related fields.
  • Refunds. Create full and partial refunds, then retrieve, update, and list them.
  • Disputes. Retrieve and list disputes, accept a dispute, and submit and attach evidence.
  • Webhooks. Signed, server-to-server event delivery for payment, refund, and dispute outcomes, verified with the TensorRail-Signature header and a five-minute replay window.
  • One canonical error contract. Every failure returns a JSON error object with a stable type and an ERR_NNNN code, uniform across every method and rail.
  • Idempotency on create. POST /payments and POST /refunds honor an Idempotency-Key header so a network retry with the same body returns the original resource rather than creating a duplicate.

2026-04​

Platform launch.

  • Hosted checkout and the direct API.
  • Payment methods: local methods on the corridors enabled for your account. Card acceptance runs through an acquirer you bring yourself and is enabled on request.
  • Recurring payments: agreement-based (CIT then MIT) recurring billing. Not enabled on any rail currently offered — mandates need a mandate-capable rail; see Recurring and saved methods.
  • Dispute management: view, accept, and submit evidence via API.
  • Webhook notifications with HMAC-SHA512 signature verification.
  • Payment links: shareable checkout URLs, no frontend required.

TensorRail, Limassol, Cyprus.