API Documentation

Integrate VerifyTaka into your application to automate MFS payment verification. Our API supports bKash, Nagad, and Rocket with real-time updates.

Base URL

https://api.verifytaka.com/v1

Format

JSON requests and responses using standard HTTP codes.

Test with Postman

Get started quickly with our ready-to-use Postman Collection.

Run in Postman

Authentication

VerifyTaka uses API Keys to authenticate your requests. Understanding the difference between these keys is critical for your platform's security.

Frontend Safe

Public API Key

vt_pk_...

Designed for use in Browsers and Mobile Apps. It can only be used for the /v1/verify endpoint.

When to use:

Verify payments on a checkout page
Showing status in a user dashboard

Backend Only

Secret API Key

vt_sk_...

Has full access to your shop data. Never expose this key in client-side code (JS, HTML, etc) as it compromises your security.

When to use:

Server-to-server verifications
Automated order fulfillment logic

Which key do I need?

Frontend Site

Use Public Key only. Restrict it via Allowed Origins for extra security.

Backend App

Use Secret Key only. It allows you to bypass origin checks securely.

Hybrid Stack

Use Both. Public Key for real-time UI updates, Secret Key for final fulfillment.

Learn more about Public vs Secret Keys

Verification API

POST

// Initialize with your Public API Key
const verifyPayment = async (txnId) => {
  const response = await fetch('https://api.verifytaka.com/v1/verify', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-API-Key': 'vt_pk_your_public_key'
    },
    body: JSON.stringify({
      txn_id: txnId,
      amount: 500, // Optional: verify exact amount
      sender: '017XXXXXXXX', // Optional: verify sender number
      mfs_type: 'BKASH' // Optional: BKASH, NAGAD, ROCKET
    })
  });

  const result = await response.json();
  if (result.verified) {
    // Payment verified successfully
    console.log("Success:", result);
  } else {
    // Verification failed (Mismatch, Expired, etc)
    console.log("Failed:", result.message);
  }
};

cURL example

POST /v1/verify

curl -sS -X POST "https://api.verifytaka.com/v1/verify" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: vt_pk_your_public_key" \
  -d '{"txn_id":"DE23P0YC09","amount":500,"sender":"017XXXXXXXX","mfs_type":"BKASH"}'

Request Parameters

Parameter	Type	Description
txn_id	string	The Transaction ID (e.g. DE23P0YC09)
amount	number	Optional. Verify if the paid amount matches.
sender	string	Optional. Verify if the sender's phone number matches.
mfs_type	string	Optional. BKASH, NAGAD, or ROCKET (case-insensitive).

Tip:Only include optional fields (amount, sender, mfs_type) if you specifically want to verify them.

Response Structure

Success Response (200 OK)

{
  "verified": true,
  "result": "SUCCESS",
  "txn_id": "DE23P0YC09",
  "amount": 500,
  "sender": "017XXXXXXXX",
  "mfs_type": "BKASH",
  "received_at": "2026-05-02T08:16:22Z"
}

Error Response (4xx)

{
  "verified": false,
  "result": "AMOUNT_MISMATCH", // or SENDER_MISMATCH, MFS_TYPE_MISMATCH, EXPIRED, NOT_FOUND
  "message": "Amount does not match the transaction on record"
}

Webhooks

Webhooks allow you to receive real-time notifications when a payment is received or verified. We will send a POST request to your configured Webhook URL. All payload fields are at the root level — there is no nested data wrapper.

Security Tip

Verify the X-VerifyTaka-Signature header using your Webhook Secret to ensure the request is from VerifyTaka.

Webhook Events

Fired after a successful bKash / Nagad / Rocket TrxID verification. Use this as the source of truth for fulfilling MFS orders.

Example JSON body

{
  "event": "payment.verified",
  "txn_id": "DE23P0YC09",
  "amount": 500,
  "mfs_type": "BKASH",
  "sender": "01797875031",
  "shop_id": "shop_abc123",
  "verified_at": "2026-05-02T08:17:05Z",
  "checkout_session_id": "vt_cs_abc...",
  "merchant_order_id": "order_123",
  "metadata": { "cart_id": "abc" }
}

Hosted checkout

Skip building a payment UI — VerifyTaka hosts the checkout page for you. Your server creates a session, sends the customer to a unique link, and once the customer pays the page verifies it automatically and redirects them back to your site.

The checkout page supports two payment methods: Mobile Financial Services (bKash, Nagad, Rocket) where the customer enters a TrxID, and Cryptocurrency where the customer picks a coin and sends the exact amount to a generated deposit address. The secret key never leaves your server.

Simplest way for your backend to know payment succeeded

Configure a webhook_url on your shop and handle the payment.verifiedevent on your server. VerifyTaka POSTs to your URL once per successful payment with a signed body — no need to watch the customer's browser or parse the redirect. Use the redirect to success_url only for a thank-you page; treat the webhook as the source of truth for fulfilling orders.

Step-by-step flow (MFS)

Create session

Your server POSTs to /v1/checkout/sessions with amount + order id

Redirect customer

You send the customer to checkout_url from the response

Customer pays

They send money via bKash/Nagad/Rocket, then enter the TrxID

Verified

Page verifies, customer is redirected to your success_url with a signed payload

Step-by-step flow (Cryptocurrency)

Create session

Same as MFS — your server POSTs to /v1/checkout/sessions

Customer selects crypto

On the checkout page they switch to the Crypto tab and pick a coin/network

Deposit address generated

The page fetches a unique deposit address and the exact coin amount required

Customer sends crypto

They send exactly the required amount + network fee to the displayed address

On-chain confirmation

CryptAPI detects the transaction (≥ 1 confirmation) and notifies VerifyTaka

Webhook fired

Your server receives payment.verified or payment.underpaid — fulfill the order

Network fees: The displayed crypto amount does not include the blockchain network fee. Customers should send the exact displayed amount plus the network fee on top. Fees vary by network — BEP-20 is typically the lowest.

1. Create a session

Call this from your backend with your secret key. Never call it from the browser.

POST /v1/checkout/sessions

curl -sS -X POST "https://api.verifytaka.com/v1/checkout/sessions" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: vt_sk_your_secret_key" \
  -d '{
    "amount": 500,
    "merchant_order_id": "order_123",
    "success_url": "https://yoursite.com/payment/done",
    "cancel_url": "https://yoursite.com/cart",
    "metadata": { "cart_id": "abc" },
    "expires_in_seconds": 3600
  }'

Complete session — MFS (optional)

Usually the hosted page calls this; use cURL only for debugging. Replace vt_cst_YOUR_PUBLIC_TOKEN with the token from checkout_url.

POST /v1/checkout/sessions/by-token/…/complete

curl -sS -X POST "https://api.verifytaka.com/v1/checkout/sessions/by-token/vt_cst_YOUR_PUBLIC_TOKEN/complete" \
  -H "Content-Type: application/json" \
  -d '{"txn_id":"DE23P0YC09"}'

Generate crypto address

Called by the hosted checkout page when the customer selects a cryptocurrency. Returns a unique deposit address and the exact coin amount required. Pass the same coin to get the cached address back (idempotent per session per coin).

POST /v1/checkout/sessions/by-token/…/crypto-address

curl -sS -X POST "https://api.verifytaka.com/v1/checkout/sessions/by-token/vt_cst_YOUR_PUBLIC_TOKEN/crypto-address" \
  -H "Content-Type: application/json" \
  -d '{"coin":"usdt_trc20"}'

Supported coin identifiers

btcBitcoin (BTC)

ethEthereum (ETH)

ltcLitecoin (LTC)

solSolana (SOL)

trxTRON (TRX)

usdt_trc20USDT (TRC-20 / Tron)

usdt_bep20USDT (BEP-20 / BSC)

usdt_polygonUSDT (Polygon)

usdt_erc20USDT (ERC-20)

usdc_bep20USDC (BEP-20 / BSC)

Response (200)

{
  "crypto_address_in": "TQGDxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "crypto_amount_required": 4.23,
  "crypto_coin": "usdt_trc20"
}

After generating the address, display crypto_address_in and crypto_amount_required to the customer. Payment completion is asynchronous — listen for the payment.verified or payment.underpaid webhook on your server.

Request body fields

Field	Type	Required	Description
amount	number	Yes	Payment amount in BDT (e.g. 500)
merchant_order_id	string	Yes	Your unique order/invoice ID
success_url	string	Yes	Where to send the customer after success
cancel_url	string	No	Where to send them if they cancel
metadata	object	No	Any extra data you want back on the redirect
expires_in_seconds	number	No	Session TTL (default 86400 = 24 h)

Response (201)

{
  "session_id": "vt_cs_...",
  "checkout_url": "https://verifytaka.com/pay/vt_cst_...",
  "expires_at": "2026-05-14T00:00:00.000Z",
  "status": "open"
}

Redirect your customer to checkout_url. That link is valid for the duration you set. If you create a second session with the same merchant_order_id while the first is still open, you get the same URL back (idempotent).

2. Handle the success redirect

After the customer pays, their browser is sent to your success_url with these query parameters:

Query params on success_url

Param	Description
txn_id	The verified MFS transaction ID
amount	Amount that was verified
merchant_order_id	The order ID you passed when creating the session
session_id	The checkout session ID
timestamp	Unix timestamp (seconds) of verification
signature	HMAC-SHA256 signature — verify this before fulfilling the order

3. Verify the signature

Always check the signature param on your backend before marking an order as paid. Use your webhook_secret as the signing key (same secret you use for webhooks).

How to build the canonical string

// 1. Sort these five fields alphabetically by key name:
//    amount, merchant_order_id, session_id, timestamp, txn_id

// 2. Join as key=value pairs separated by &  (no URL-encoding):
const canonical =
  `amount=${amount}&merchant_order_id=${merchant_order_id}` +
  `&session_id=${session_id}&timestamp=${timestamp}&txn_id=${txn_id}`;

// 3. HMAC-SHA256 with your webhook_secret, compare as lowercase hex:
const expected = hmacSHA256(canonical, webhookSecret).hex();
const isValid  = expected === signature; // from query param

Security checklist

Never use your vt_sk_ secret key in frontend JavaScript or mobile apps.
Always verify the signature param before fulfilling an order — do not trust the other params alone.
If you create a session with the same merchant_order_id while it is still open, the same link is returned — no duplicate charges.
Sessions expire automatically; expired links show an error page and cannot be completed.

Downloads & Integrations

Android Forwarder

The core engine that syncs your bKash, Nagad, and Rocket SMS to the cloud in real-time. Lightweight and secure.

Latest Version: v1.0.0

Supported: Android 8 - 12

Android 13+ Users:Google may block permissions for sideloaded apps. If you can't enable the service, go to App Info > Triple dots (⋮) > "Allow restricted settings".

Download APK

WooCommerce Plugin

Drop-in payment gateway for WordPress. Automatically verify payments and fulfill orders without writing code.

Compatible: WP 6.0+

Download Plugin (.zip)

Setup Tip: Use your Global Token or individual Shop Device Token to connect the Android app. For WooCommerce, only your Secret Key is required.