Choose your integration

There are three ways to accept payments with TensorRail. They all sit on the same account, the same balance, and the same webhooks, and 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	You need full control of the payment experience	Automatically for most; only a method needing a new input touches code
Drop-in SDK	A mount point for our prebuilt fields	You want card fields embedded in your own page without card data reaching your servers	Automatically for methods the SDK renders

The Drop-in SDK is available on card rails

TensorRail.js exists to keep card data off your servers, so it switches on with a card acquirer enabled for your account; no rail enabled today takes cards. The other three paths take payments on the rails you already have. See Drop-in SDK for what that means before you pick this one.

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 and the Drop-in SDK do this enumeration for you — it is one of the reasons to prefer them.)

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. 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.