Skip to main content
Tap on Phone lets a merchant accept contactless cards, phones and watches on an ordinary Android phone. Your app describes the sale, the SDK owns the screen from tap to outcome, and your backend sees the transaction like any other Rinne transaction.

​
Platforms

Android

Available in closed beta. Kotlin SDK for Android 10 and newer, on phones with NFC and Google Play services.

iOS

Coming soon. The same integration model, the same token from your backend and the same branding object.

​
How a payment flows

1

Your backend mints a short-lived access token

It calls POST /v1/terminal/token with your API key. The key never ships inside the app. The token expires after fifteen minutes by default and works only on the Tap on Phone surface.
2

Your app prepares the terminal once

Payments.getReady takes the token, attests the device and provisions keys. It is idempotent, so calling it again on a prepared terminal returns immediately.
3

Your app launches the checkout for one sale

Checkout.Contract opens Rinne’s screens with the amount, the payment method and your idempotency key. The customer taps, enters a PIN on the certified pad when the card asks for one, and the operator reads the outcome.
4

Your app receives exactly one result

PaymentResult is Approved, Declined, Failed or Cancelled. It arrives through Android’s activity-result machinery, which survives the process being killed mid-payment.
5

The transaction appears on the Rinne API

The SDK registers the transaction with Rinne while authorising. Read it back through the transactions API or a transaction.created webhook using the requestId you sent.

​
What the SDK gives you

  • Certified checkout screens for preparing, presenting the card, processing, PIN entry and every outcome, in English and Brazilian Portuguese.
  • One branding object. CheckoutConfig themes the screens and the certified PIN pad together. Try every field in the simulator.
  • A stable error taxonomy. Thirteen ErrorCode values, each with operator text and a retry hint, instead of the dozens of low-level causes underneath.
  • Card-present refunds. A refund is a card re-tap for the full amount of a sale, launched with the same contract.
  • Onboarding helpers. AntennaSetup shows the merchant where the NFC antenna is, and Payments.checkDeviceReadiness reports NFC, connectivity, location and Play services before a customer is waiting.

​
Requirements

The merged manifest of your app carries all nine permissions, which matters when you answer the Play Console questionnaire; Going to production lists what each one is for. The device runs an integrity check before every transaction. Emulators, rooted devices and devices without Play services fail it with ATTESTATION_FAILED, so test on a physical phone.
During the closed beta, integrations run against the sandbox environment with the sandbox artifact. Sandbox payments authorise against a simulated acquirer and never move money. Rinne provides the production artifact and credentials when your integration is approved for launch.

​
What the SDK never exposes

The SDK never receives the card number, track data, PIN, expiry, cardholder name or cryptogram, and none of them can appear in a PaymentResult. Receipt fields such as the masked last four digits come from the transaction record on the Rinne API, not from the SDK.

​
Get access

Tap on Phone is in closed beta. Access is granted on request. To join, email [email protected] with your company name and a short description of your app. You receive credentials for the SDK registry, a sandbox API key with the tap_on_phone.* permission (or the *.* wildcard) and a merchant enabled for contactless capture.

​
Start here

Quickstart

From an empty project to an approved sandbox payment in six steps.

Simulator

Brand the screens, play the flow and copy the Kotlin that produces it.

Customization

Every CheckoutConfig field, what you cannot change, and how to override the copy.

Results and errors

What your app receives after a payment, and what each error code means.