Large Payment Collection

Traditionally, large ticket size payments happen via both offline and online medium. The offline process includes payments made via cash, cheque, demand drafts etc. This medium has multiple challenges for both user and the merchant listed below:

Consumer Merchants

Cash, Cheque, and Demand Draft has handling cost

Manual reconciliation is required against a customer's receivables, where the payment is received via offline mode. The process is time-consuming and prone to errors. 

Cash, Cheque, and Demand draft has procurement time and cost

Non-availability of the automated refund process. In case of refunds, it requires a manual exchange of cheque or demand draft.

In case the incorrect details are provided, new cheque or demand draft needs to be issued 

Enormous costs associated with the handling of cash, cheque, and demand drafts.


The online process includes wire transfer via NEFT, RTGS and IMPS. While this gets rid of the handling costs associated with the offline payment process, there is one major challenge associated with this:

Consumer Merchant

Need to send the reference numbers of transfers to the merchant

  • Manual reconciliation against the reference number received from customer versus the payments available in their bank account
  • Enormous handling cost

Paytm's Large Payment Collection solution helps to resolve the above problems. Here each customer is provided with an account number, IFSC Code, and Beneficiary Name that is specific to them. These are virtual accounts, also referred to as VANs. Customers make the transfer to their individual VANs via IMPS, NEFT, and RTGS from their internet banking portal, physical bank branch etc. On receiving the money, the merchant will receive notifications of the transfer with detailed information about the customer (customer or business ID of merchant's system, customer or business name and other customers/business attributes). This information is also accessible via reports enabling customer's to complete automate the reconciliation of receivables with payments.

Overview of Large Payment Collection

  1. Merchant creates a VAN against an entity which could be an individual, business, or a group of individual/business from which payments need to be collected and reconciled with. The entity can also be an invoice for which the payment needs to be received.
  2. Merchant distributes the VAN to their respective customer. In case, the VAN is generated for a Customer A, then it should only be distributed to Customer A.
  3. Customer adds the VAN as a beneficiary with his bank. Once added, customer can make as many transfers to the merchant.
  4. On receiving each transfer, the merchant will be notified of the transfer with the entity details. Transfer and entity details will be available in the daily reports.
  5. On T+1, the merchant will receive the settlement against all the transfers received on VANs generated by them.
  6. If the merchant wants to return the partial or complete amount to the customer, they can initiate a refund.
  7. Once the use case of accepting payment from the entity is complete, the merchant can disable(close) the VAN to avoid any further collections.

Third-Party Validation (TPV)

Third-Party Validation helps in securing transactions made in the Banking, Financial Services and Insurance (BFSI segment). Merchants in the BFSI segments are prone to cases of cybercrimes, asset appropriation, identity thefts, money laundering, accounting frauds etc. In order to reduce the risk, the Securities and Exchange Board of India (SEBI) requires that all payments made to BFSI merchants should be made from bank accounts that are already registered with the merchant. The bank account can be provided by the customer at the time of registration or enrollment for the scheme offered by the merchant.


Merchants can add Bank Accounts or TPVs to a given VAN for TPV check at the time of VAN creation using the Create VAN API. Bank Accounts or TPVs can be added post VAN creation using the Update VAN API.  A maximum of 10 Bank Accounts can be Active at any point in time during the VAN lifecycle. Incoming payments are accepted only when a customer makes payments from pre-registered Bank Account or TPVs. All payments originating from non-TPV Bank Accounts are rejected. Therefore, Paytm Payment Gateway is able to secure transactions for BFSI merchant.

Creation of VAN

VAN is the virtual account that is created over a physical account. These are only created to track the payments that are being received in the main physical account. Paytm partners with a bank to facilitate these virtual accounts over its own account. These VANs can be generated corresponding to the entity against which the reconciliation needs to be done. Hence in case of schools seeking fees from students, it needs generated corresponding to students. If the business is seeking a payment against an invoice, then VAN needs to be generated against an invoice. Once complete payment is received, the merchant can disable the VAN associated with that invoice.


VAN details comprise the following:

  • VAN Account Number - This is a 16 digit alphanumeric account number which consists of the following:
    • First two characters - This is fixed as 11 by the partner bank.
    • Next 4 characters - This a merchant identifier called merchant prefix issued to the merchant at the time of onboarding. Merchant can also opt for names resembling their business names. Once a merchant identifier is taken, it cannot be allocated to any other merchant. You can see few examples of them in the table below:
      Merchant Name Merchant Identifier
      Paytm PYTM
      Sony SONY
      IIT Kanpur IITK
    • Last 10 characters - This is an alphanumeric ID that can be passed to the merchant. The merchant should pass the ID of the entity with which they want to reconcile the payment. Hence, in case of college seeking fees from students, it could be the Roll Number (provided it is unique). If the business is seeking a payment against an invoice, it can be a unique invoice ID.
  • IFSC Code - PYTM0123456, which is a fixed identity.
  • Beneficiary Name - One97 Communications Limited, which is a fixed identity.
    Example - Let us assume IIT Kanpur wants to collect VANs for its student. Hence, a sample VAN should appear as "10IITK20210023TA". Here, 20210023 is a unique Roll Number of each student in the institute and TA is the first letter of the first and last name of the student. This way a student will always remember the VAN corresponding to which the payment needs to be made.


VAN Lifecycle Management

  • VAN can be generated using the Create VAN API. This is a bulk API wherein you can send up to 10 VAN creation requests altogether.

  • Merchant must pass the entity related details that will be required at the time for reconciliation. All fields that are passed to us in UDF fields, customer details and purpose will be provided in reconciliation assets like Order Status API, Payment Webhook, and transaction report generated from the UMP.

  • Merchant can also pass the list of bank accounts from which the payments can be accepted. The addition of bank accounts on a given VAN would ensure that TPV validation will be performed on that VAN. At any point in time, TPV validation can be performed for a maximum of 10 bank accounts. All these accounts should be in Active status.

  • In case the response is not received to re-verify the status of the VAN creation request, the merchant can check the status using the Query VAN API.

  • In case the merchants want to stop accepting payments via a particular VAN, then they can request the Update VAN API.

  • Merchants can use VAN Order List API to fetch order details for a given MID.

  • Merchant can also fetch all the VANs generated with their status using the VAN List API.


Distribution of VAN to the customers

  • Once the VAN is generated, the merchant can distribute VANs amongst their customers via emails, SMS, Whatsapp, etc.
  • As of now, Paytm will provide this functionality of distributing the VANs to the respective customers. But as of now, Paytm does not support this.

Caution: Merchant needs to ensure that there is no mixup in the VAN distribution amongst customers. Hence the VAN generated for a Customer A needs to be distributed to the Customer A. If not, the payment will be made by some other customer whereas payment will be notified to merchant against the Customer A.


Receiving payments in VAN

Once the VAN is created and distributed amongst the customers, they do the following:

  1. Customer adds VAN details as a beneficiary in their bank account.

  2. Once the account is added, the customer can initiate a transfer using IMPS, NEFT, and RTGS. Transfer limits associated with IMPS, NEFT, and RTGS are provided in the table below. There might be additional limits imposed by user’s issuing bank.

  3. On making the transfer, payment is received by Paytm's partner bank. The partner bank accepts the payment and notifies Paytm of the transfer received with the associated VAN details.

  4. On receiving the payment notification, Paytm creates a successful order. This order has associated details that were passed in the Create VAN API.

  5. Merchant gets payment completion Webhook with the transfer details. This also comprises the associated details that were passed in the Create VAN API.

  6. In the case of TPV, the Partner bank performs TPV if bank accounts are associated with VAN. The partner bank rejects the payment where TPV fails and notifies Paytm of the failed transfer with the associated VAN details.  On receiving the payment notification, Paytm creates a failed order. Paytm notifies the merchant of a payment failure caused by TPV check failure by sending a failure webhook. Similar to the success webhook, the failure webhook also consists of associated details that were passed in the Create VAN API.

  7. Merchant can also query the payments received using the Order list API  or Transaction Status API, which will provide a list of all payments between a time frame with VANs corresponding to each order.

  8. Once complete payment is received, the merchant can disable(close) the VAN associated with that invoice.
  9. Merchant will have access to payment and VAN details corresponding to transaction and settlement report generated from the Merchant Panel.

  10. On T+1, Paytm will settle the collected amount into the customer's settlement account.


Type of fund transfer Allowed on VAN Amount Limit Time taken to register payment
IMPS Yes INR 1 - INR 2 Lakh Real-time
NEFT Yes INR 1 - Limit applied by your bank Between 30 mins to 2 hours
RTGS Yes INR 2 Lakh - Limit applied by your bank  Real-time
UPI No -


In case the merchant wants to return complete or partial amount, a refund can be initiated via Refund API or Merchant Panel. You can see the detailed refund process here.


Rules specific to refunds for this flow are mentioned below:

  • Missing bank account information - In case of certain transfers, the remitter account number or ISFC code is not received by us from the partner bank. In such scenarios, refund or reverse transfer cannot be processed. In case the merchant requests the same, it will be failed from Paytm's end. An indicator of this blank remitter will be detailed in our APIs, webhooks, etc.
  • Refund above INR 2 Lakh - Refund above INR 2 Lakh is not accepted. Hence, if a merchant wants to refund INR 4.5 Lakh against an order of 5 Lakh, then three different refund needs to be raised.

Integration testing on staging environment

You need to follow the steps below while testing on the staging environment:

  1. Dummy VANs can be created on staging using the Create VAN API and Query VAN API. Actual money cannot be transferred in this VAN.
  2. In order to initiate a payment in this VAN, a merchant needs to use this Paytm Utility. Here merchant needs to provide the following details:
    Name Definition
    User Name User name of the remitter. This could be a dummy user name which will be provided to the merchant in all reports and API.
    User Account Number Account number of the remitter. This could be a dummy account number which will be provided to the merchant in all reports and API.
    User IFSC IFSC code of remitter. This could be a dummy IFSC code which will be provided to the merchant in all reports and API.
    VAN 16 digit VAN number created via staging API. Note that payment will be created provided they entered VAN exists on staging.
    Transaction Amount Amount for which a merchant wants to simulate the payment process.
  3. On pressing Submit, Paytm will create a payment on staging. On successful creation, the merchant will:
    • Get an S2S webhook notifying payment completion

    • Merchant can see the order and payment details on the merchant dashboard

    • Merchant can query details of the order on the staging environment

    • Merchant can initiate a refund 

Post Integration Steps

Post completion of integration on your staging environment, do a complete transaction from order summary page on your website or mobile app.

  1. Attempt a test transaction using the test paymodes credentials.

  2. Ensure you re-verify transaction response with Transaction Status API via server to server call in payment flow and not separately as a one-time activity.

  3. See the transaction details in the "Test Data" mode on your dashboard.

Once the test transaction is complete, move your code to live environment with production account details, which you would have received from Paytm.


Lastly, it's recommended that you read about Managing Refunds and late payment notifications.


In case of any issues with integration, please get in touch.