Documentation

TPV

TPV available for Payment Modes

  • Net-Banking – Pre-payment validation of the end customer’s bank account details.
  • UPI – Pre-payment validation of the end customer’s VPA / UPI ID.
  • Penny Drop – Verify the end customer’s bank account.

TPV Process Flow

  • Merchant initiates a transaction request and passes the customer account details or customer’s VPA.
  • On the payment page, customer makes payment using NB or UPI respectively (only the payment option sent by Merchant in payment request is available on payment page).
  • The customer details (account or VPA) are validated at bank’s end, once validated only then the transaction goes through, else the transaction fails, and customer will have to retry the payment.

TPV Use Cases

  • Broking firms require the funds to be received only from one dedicated source account registered with the firm. TPV enables them to validate the account being registered once at the time of account registration, and further the account being used to make payment is validated at the time of payment.
  • At times, Investment / Government / Insurance based entities require the customer to pay using their own account only to make the purchase. In such a case, they send the registered account details of the customer in transaction request and the same is validated at the time of payment.
  • Penny Drop: It has become a necessary practice for businesses to verify the beneficiary’s account details prior to disbursing funds to the account (as a one-time activity). This is to avoid unnecessary failures in fund disbursement at some point in the future.

Split Settlements

Payment received can be split and settled as per the information passed in the API request for either transaction or refunds.
Pre-requisite: The product (i.e. bank account) must be configured and multi-product facility must be enabled with the help of account manager or integration support representative.

Specifications for the Amount to be split to multiple Accounts:
Merchant can specify multiple products in ‘prodDetails’ if the same is pre-configured. The amounts across those products can be variable, but the total amount across all the products should be equal to that paid by the end-user.

Process flow diagram: If there are various products across which the payment is to be distributed, the ‘product’ parameter shall be replaced by the ‘prodDetails’ parent JSON field as depicted in the example below –

The "product": "School",’ shall be replaced by:
"prodDetails": [ { "prodName": "Library", "prodAmount": 5000.00 }, { "prodName": "Commute", "prodAmount": 2500.00 } ],

Note: In such request, the sum of all ‘prodAmount’ should be equal to the amount to be paid.

Force Success

In case of no response from bank in real-time, enabling 'force success' will capture the response at any later point in time when the bank posts the final transaction status, or the status is fetched explicitly. The transaction is then converted from 'pending' status to 'force success' implying that transaction was successful, and callback is triggered to the merchant post which the services are provided. This is useful in scenarios where goods/services are provided at the time of success posting of transaction. E.g.- bill payments, payment towards investments etc.

Auto Refund

In case of no response from bank in real-time (maximum T+2 days), enabling 'auto refund' will capture the response at any later point in time when the bank posts the final transaction status, or the status is fetched explicitly. The transaction is then converted from 'pending' status to 'Auto Reversal' implying that refund will be processed against the successful transaction. This is useful in scenarios where goods/services are provided only in real-time, else the transaction must be considered as failed.
E.g.- Train tickets.

Auto Retry

Customers can retry payment in case failure occurs on the chosen payment method due to either network issues or any failure at the bank’s end. In such an instance, the customer has the option to choose any other payment method and continue making the payment.

Session Timeout

Time for session timeout can be specified for the payment page to be exhibited for certain duration e.g. ‘10’ minutes. Session timeout can be configured with the help of your account manager or drop an e-mail to NDPS.support@nttdata.com.