Skip to main content
It provides pre-built payment elements (UPI, Cards, T&C, etc.) that are rendered inside secure iframes, ensuring sensitive payment data never touches the merchant’s servers. With a simple script include and a few lines of JavaScript, merchants can:
  • Collect payment details securely
  • Trigger payments with a unified pay() API

What does the Drop-in SDK provide?

The Drop-in SDK offers a set of ready-to-use payment elements, including:
  • UPI Collect
  • Card Number
  • Card Expiry
  • Card CVV
  • Card Holder Name
  • Payment status popup (success, failure, processing)

How TBDropin Works

TBDropin follows a component-based architecture similar to modern payment element SDKs.
  1. Load the SDK
  2. Initialize TBDropin
  3. Create payment components
  4. Mount components into the DOM
  5. Trigger payment using pay()
Each payment input (Card Number, UPI ID, CVV, Expiry, etc.) runs inside a sandboxed iframe, isolating sensitive data and improving security.

Key Concepts

1. Initialization

Before using any component, the SDK must be initialized.
await TBDropin.init({
  mode: "sandbox", // or 'production'
  publishKey: "your_publish_key",
});
Initialization:
  • Sets the environment (sandbox / production)
  • Loads payment atom definitions
  • Prepares secure message handling between iframes

2. Payment Components (Elements)

TBDropin provides individual payment elements, such as:
  • tb_upiCollect
  • tb_cardNumber
  • tb_cardExp
  • tb_cardCvv
  • tb_cardHolder
  • tb_tnc
Each component:
  • Is created using TBDropin.create()
  • Is mounted into a DOM container
  • Emits lifecycle events like ready, change, clear
const upi = TBDropin.create('tb_upiCollect', {
  placeholder: 'Enter UPI ID',
  styles: {...},
  fonts: [...]
});

upi.mount('#upiCollect');

3. Component Lifecycle & Events

Every component exposes event hooks:
component.on("ready", () => {
  console.log("Component is ready");
});

component.on("change", (data) => {
  console.log("Input changed", data);
});

4. Secure Iframe Architecture

All payment fields are rendered inside secure iframes created by the SDK. Benefits:
  • PCI compliance
  • No raw card / UPI data exposed to merchant
  • Isolated DOM & styles
  • Safe cross-origin communication via postMessage
The SDK handles:
  • Iframe creation
  • Styling constraints
  • Event communication
  • Data aggregation during payment

5. Making a Payment

Once the required components are mounted and valid, payment is initiated using:
const response = await TBDropin.pay({
  billingSessionId,
  subscriptionId,
  mandateId,
  payMethod: selectedPaymentMethod,
  cardType: "CC", // only for cards
});
Rules:
  • Exactly one of billingSessionId, subscriptionId, or mandateId is required
  • T&C (tb_tnc) must be visible and accepted
  • All required inputs must be valid before payment proceeds

6. Getting Required IDs for Payment

Before calling TBDropin.pay(), merchants must obtain one of the following identifiers from the Transact Bridge APIs:
  • billingSessionId
  • subscriptionId
  • mandateId
These IDs are generated server-side using Transact Bridge APIs and represent different payment flows. Important: Exactly one of these IDs must be provided when calling pay(). You can obtain the billingSessionId by creating a billing session using the Transact Bridge Sessions API. This API allows you to generate a unique payment session for one-time payments. Refer to the API documentation below for request structure, required parameters, and response details.

One Time Payment API Docs

View the Postman API Collection