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-10​

Refunds are created with POST /v1/refunds only. POST /refunds on the main API no longer creates a refund: it answers 404 with ERR_3012. Create every refund with POST /v1/refunds, which reserves it against the payment before anything is sent, so the refunds of a payment can never add up to more than it captured, whichever way each one is returned. Refunds made earlier are unaffected: GET /refunds/{refund_id}, POST /refunds/{refund_id} and POST /refunds/list work as before.

A publishable-key confirm from the browser needs its page's origin enabled for your account. Confirming client-side with a publishable key (rail_open_…) and a payment's client_secret now checks the page's origin against the origins enabled for your account; a confirm from any other origin gets no browser access to the response. The hosted checkout page is enabled for every account. For a confirm from your own pages, origins are enabled on request through the account team. See Browser flows and client_secret. No field or response shape changed.

2026-09​

The IP allowlist also covers payment API calls made with a secret key. Once your IP allowlist has an active entry, /payments, /refunds and the other payment API routes refuse a secret-key call from an address outside it with 403 ERR_1006, as the account API (/v1/...) already did. Calls made with your publishable key from your customers' browsers, such as the hosted checkout's, are not restricted.

Routes that take card data are no longer served or documented. POST /payment_methods, POST /payment_methods/{method_id}/update, POST /payments/{payment_id}/eligibility and the /subscriptions endpoints answer 404, and the API reference no longer carries card-number or security-code fields or example card numbers. Card details are entered in card fields hosted by the card processor, and the token those fields return is sent as payment_method_data.psp_token. Saved methods are created by a payment (setup_future_usage), and recurring charges are payments your server schedules; see Recurring and saved methods.

A refund_id you choose is letters, digits, _ and -. The API reference and Refunds now say so (1 to 64 characters, pattern ^[A-Za-z0-9_-]{1,64}$): the id is the path segment of GET and POST /refunds/{refund_id}, and an id holding /, %, ?, #, ;, a space or a non-ASCII character cannot be retrieved or updated by id. Refunds you created with dots, colons or other characters a URL path carries as they are stay retrievable.

Integration guidance is hosted checkout, payment links and the REST API. The guides, the quickstart and the integration chooser now cover exactly those three paths, over plain HTTPS with no TensorRail package to install. No API changed.

Documentation for three account-control surfaces that were already live. No API changed: these endpoints have been serving all along and only the documentation was missing: IP allowlist (including the lockout hazard and how to recover from it), Account security (two-factor, sessions, recent logins, password, security email) and Team and roles. The Reporting API page now also covers GET /v1/audit and POST /v1/analytics/report.

Money-out endpoints answer 404, recorded here for the first time. /v1/settlements, /v1/settlements/{id} and /v1/payouts are not served. Reading your balance is documented and supported (see Balances and its "What this endpoint does not cover" section), and everything beyond reading it is arranged with your account manager under your agreement rather than requested through the API. Keys may still carry the payouts:* scopes so that nothing would need reissuing if that changes; see Reserved scopes.

ERR_1022 (two_factor_enrollment_required) added to the error catalog. It is returned instead of ERR_1019 when an action needs step-up and no authenticator is enrolled at all: the two need different handling, since there is no code to prompt for.

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 automatic retry 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, and cards on card rails enabled on request.
  • Recurring payments: agreement-based (CIT then MIT) recurring billing on mandate-capable rails; 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.