Choose your integration

There are three ways to accept payments with TensorRail: hosted checkout, payment links, and the direct REST API. All three are one API: the same account, the same balance, the same webhooks, every method enabled for you, and test and live on one base URL, https://api.tensorrail.com, where your key selects the environment. You can use more than one. Pick by how much control over the payment screen you want, versus how little you want to maintain.

Path	You build	Best when	New methods appear
Hosted checkout	A redirect	You want the fastest launch and least maintenance	Automatically, zero code
Payment links	Nothing (or one API call)	Invoicing, or no dev time right now	Automatically, zero code
Direct API	Your own checkout UI, over plain HTTPS	You need full control of the payment experience	Automatically for most; only a method needing a new input touches code

No TensorRail package to install for any of them. Every call is an HTTPS request with your key in a header, so any language with an HTTP client works, and the request examples on this site are plain HTTP calls with curl, Node fetch or Python requests.

The rule that makes this simple

You never choose the payment-method mix, and you never re-integrate to add one. TensorRail enables methods and corridors on your account; your integration renders whatever is enabled. The enabled set grows rather than being fixed: it is visible in your dashboard, and your account manager can extend it (see Corridors and coverage). What the platform supports overall is in the unauthenticated GET /v1/capabilities catalogue. The only difference between the paths is who draws the payment screen.

Everything else is shared: one POST /payments create call, one payment object, one status vocabulary, one error catalog, one webhook contract, one set of balances. Switching paths later, or running several at once, changes no server-side code except how you hand the customer to the payment screen.

Hosted checkout

Create a payment on your server, then redirect the customer to pay.tensorrail.com with the payment's identifiers and your publishable key. TensorRail presents every enabled method, handles each rail's specifics (redirects, app approvals, reference displays), and returns the customer to your return_url.

Build the redirect URL from the created payment, using your publishable key (pk), which is browser-safe:

https://pay.tensorrail.com/?mode=link&payment_id=PAYMENT_ID&client_secret=CLIENT_SECRET&pk=rail_open_test_xxx&amount=50000&currency=INR

Query param	Value
mode	link
payment_id	from the created payment
client_secret	from the created payment
pk	your publishable key
amount	display amount, minor units
currency	display currency
description	optional display line
country	optional ISO 3166-1 alpha-2 code; disambiguates the market when a currency is shared across several

The client_secret scopes the page to exactly this one payment; the secret key never leaves your server. Best for getting live in a day and never maintaining a payment UI. New methods render here automatically.

Payment links

A payment link is the same hosted-checkout URL, shared instead of redirected to. Create it without code from the dashboard (Payment Links → enter amount, currency, optional description → Create), or build the URL from a created payment and send it by email, chat, or invoice. Each link maps to one payment_id; reconcile with your own reference via metadata. The outcome arrives on the same webhooks as every other payment, so links you send by hand still land in your automated fulfilment and reporting.

Best for invoices, one-off collections, or launching before you have dev resources.

Direct API

Run your own checkout. Create a payment, present the enabled methods, and confirm the customer's choice. You control every pixel; in return you own three responsibilities the hosted page would otherwise carry:

• next_action handling: forward the customer to whatever the confirm response asks for (redirect, in-app approval, reference details), treating it as opaque.
• Decline UX: a failed payment should offer the customer a fresh attempt (a new payment, a new Idempotency-Key).
• Method rendering: drive the method list from configuration rather than hard-coding it in your checkout, so a newly enabled method appears without a code change. What is enabled is per account and changes as coverage is added; your dashboard shows the current set and your account manager confirms additions. (Hosted checkout does this enumeration for you: it is one of the reasons to prefer it.)

Best for teams that want the payment experience fully inside their product. The complete walk-through, including declines, retries, and manual capture, is Accept a payment.

Deciding in practice

• Shipping this week, or no frontend capacity? Hosted checkout.
• Collecting invoices or one-offs, sales-led? Payment links.
• Checkout is part of your product's core UX? Direct API.
• Not sure? Start hosted; you can move to the direct API later without touching your create call, webhooks, or reconciliation, because those are identical across paths.

Whichever you pick

• Authenticate with your key: secret key server-side, publishable key in the browser, from an origin enabled for your account. See Authentication.
• Confirm outcomes with webhooks, not the customer's return.
• Send an Idempotency-Key on create; the platform enforces it, which makes your retries safe. See Orchestration and routing.
• Build against a test key first. See Testing and sandbox.

Next steps

You have picked a path. Head straight into its guide:

• Hosted checkout: create server-side, redirect to the hosted page.
• Payment links: share a link, no checkout to build.
• Direct API: run your own checkout and confirm the customer's choice.

TensorRail, Limassol, Cyprus.