T-Kassa Mobile Payment Integration: Native iOS & Android Guide
Consider this: when a client taps "Pay" and the app freezes on a blank screen — that's a catastrophe. Switching from a WebView-based payment to a native T-Kassa integration can save businesses $5,000–$20,000 per month in lost revenue due to higher conversion. Our team has integrated T-Kassa (formerly Tinkoff Cash Desk) into over 50 projects with audiences from 1,000 to 100,000 users over the past 5 years. Below is a proven scheme that works from the first attempt.
Why Choose Native T-Kassa Integration?
T-Kassa provides ready native SDKs for iOS and Android. Unlike WebView wrappers, the native payment screen loads in under 1 second (2–5 times faster than WebView), supports Face ID/Touch ID for authorization, and handles post-payment returns correctly. The SDK also includes fraud protection and automatically fills saved cards. This yields 20–30% higher payment conversion than the browser-based version — a 2–3 times improvement. According to official Tinkoff Acquiring SDK documentation, the native approach minimizes user steps.
How the Main Flow Works?
T-Kassa uses a two-stage scheme: first the server initializes the payment (server-side initialization) and obtains a paymentId, then the SDK on the client processes it. This is a standard payment gateway scheme, but precisely here mistakes are most common.
Server initialization:
POST https://securepay.tinkoff.ru/v2/Init { "TerminalKey": "your_terminal_key", "Amount": 150000, "OrderId": "ORDER-1234", "Description": "Оплата заказа", "Token": "sha256_signature" } The response contains PaymentId and PaymentURL. PaymentId is passed to the SDK for processing the payment in the native UI.
Step-by-Step Integration Guide
Step 1: Server-Side Initialization
Ensure the server generates a correct Token — a SHA-256 hash of concatenated parameters (in alphabetical order of keys) with Password appended at the end. Use official libraries for generation. This step is critical for payment processing without errors.
Step 2: Launch the Payment Screen on the Client
After receiving the PaymentId, pass it to the SDK. Example for Android:
val tinkoffAcquiring = TinkoffAcquiring( context, terminalKey = "your_terminal_key", publicKey = "your_public_key" ) val paymentOptions = PaymentOptions().setOptions { setTerminalParams( terminalKey = "your_terminal_key", publicKey = "your_public_key" ) orderOptions { orderId = "ORDER-1234" amount = Money.ofRubles(1500) title = "Order No.1234" description = "Payment for order" savingAsParentPayment = false } featuresOptions { useSecureKeyboard = true cameraCardScanner = CameraCardIOScanner() fpsEnabled = true tinkoffPayEnabled = true } } val launcher = registerForActivityResult(TinkoffAcquiring.createPaymentContract(context)) { result -> when (result.status) { AsdkState.Success -> handleSuccess(result.paymentId) AsdkState.Cancelled -> {} AsdkState.Error -> handleError(result.error) else -> {} } } tinkoffAcquiring.openPaymentScreen( activity = this, paymentOptions = paymentOptions, launcher = launcher ) For iOS (AcquiringUISDK):
import TinkoffASDKUI let credential = AcquiringSdkCredential( terminalKey: "your_terminal_key", publicKey: "your_public_key" ) let acquiringSDK = try AcquiringUISDK(credential: credential) let paymentData = PaymentInitData( amount: 150000, orderId: "ORDER-1234", customerKey: "user_123" ) acquiringSDK.presentPaymentView( on: self, paymentData: paymentData, configuration: AcquiringViewConfiguration() ) { result in switch result { case .success(let paymentInfo): print("Payment ID: \(paymentInfo.paymentId)") case .failure(let error): print("Error: \(error)") case .cancelled: break } } Step 3: Handle Callbacks and Payment Verification
After payment, T-Kassa sends a callback (webhook) to your server. You must configure a callback URL in your T-Kassa account. The callback includes PaymentId, Status, and a digital signature. Verify the signature to confirm authenticity. Then update the order status. For payment verification, you can also use the GetState API to check the payment state.
Case Study: How We Boosted Conversion from 12% to 28%
Let me share a specific case. Our client was a marketplace with a native Android app. Before us, payment went through WebView and lost 30% of orders at the confirmation stage. We switched everything to the T-Kassa SDK, set up SBP setup and Tinkoff Pay, added a custom payment method selection screen. Result: conversion increased from 12% to 28%, a 2.3x improvement. Support stopped receiving complaints about "stuck payments". Key integration points:
- Server-side payment initialization with correct Token (SHA-256).
- Using
CameraCardIOScanneron iOS and ML Kit on Android for card entry. - Setting up callbacks via webhook: we receive payment status in real time and update the order without user involvement.
Additional Settings
Tinkoff Pay
Tinkoff Pay opens the T-Bank app for payment confirmation. The T-Bank app must be installed on the device for it to work. The SDK checks automatically via UIApplication.canOpenURL (iOS) or PackageManager.getLaunchIntentForPackage (Android) and hides the button if the app is not found.
Request Signature (Token)
All server requests to the T-Kassa API are signed using SHA-256: concatenation of parameter values + Password in alphabetical order of keys. An incorrect token is a common cause of error 0 (Invalid Token) during payment initialization. We strongly recommend verifying token generation on the server side using official libraries.
Comparison of Native Integration vs WebView
| Criterion | Native T-Kassa SDK | WebView Wrapper |
|---|---|---|
| Load speed | < 1 second | 2–5 seconds (2–5x slower) |
| Payment conversion | 25–35% | 10–18% (2–3x lower) |
| Biometry support | Yes | No |
| Error handling | Native alerts | Browser errors |
| UI responsiveness | 60fps | 30fps (2x lag) |
The table shows that the native SDK is 2–5 times faster, provides 2–3 times higher conversion, and offers a significantly better user experience.
Common Errors and Their Solutions
| Error | Solution |
|---|---|
| Invalid Token | Check parameter order and Password value. |
| PaymentId null | Ensure the server returns a correct Init response. |
| Keyboard disappears | Disable useSecureKeyboard = true for debugging. |
| SBP not displayed | Set fpsEnabled = true and update the SDK. |
What's Included in the Work
- iOS / Android SDK connection
- Server-side payment initialization with correct signature
- Option configuration: SBP, Tinkoff Pay, card saving
- Status handling and webhook confirmation
- Testing via test terminal (use test terminal credentials from your dashboard)
- Payment verification through callbacks
Timelines and Pricing
Basic integration takes 1–2 days. If custom UI or additional methods are required — up to 5 days. Typical cost ranges from $500 to $2000, depending on complexity. Our team has 5+ years of experience with T-Kassa and has successfully completed over 200 payment integrations. We guarantee the payment screen works stably even under high load. Contact us for a free engineer consultation — we'll assess your project and provide an optimal solution.
According to data from Tinkoff Developer Portal, the native SDK increases payment conversion by 20–30%. Get a consultation with an engineer — we'll help you connect T-Kassa without errors.







