Paytm As TG with only Paytm PA

This section describes the integration where merchants are currently using Paytm as their payment aggregator for card transactions. They use either Paytm local vault service, internal or external 3rd party vault APIs to provide the checkout/cashier page experience natively on its APP/website using custom Checkout integration via API or Mobile SDK.

Going forward merchants can continue the above workflows using Paytm as a token gateway to connect with all three different card schemes.

Saved card workflow

1. You need to call the Fetch Pay Option API to get saved cards against the user. This will return the masked details for saved cards existing in the current and card scheme’s vault in response.

   Note:Saved cards from current vault will be provided till 31 Dec 2021 provided further extensions are not provided.

2. There will be three attributes that will be provided against each saved card -
   1. isCardCoft : This identifier indicates if the returned card is tokenized or not. 
   2. isEligibleForCoft: This identifier indicates if card tokenization is supported or not. This depends on both Paytm’s integration readiness with different card schemes and onboarding process completion for the merchant. Also isEligibleForCoft will also come false for already tokenized cards.
   3. isCoftPaymentSupported: This identifier indicates if payment processing is supported via the tokenized card or not. Initially there will be scenarios where transaction is not supported whereas tokenisation is because bank gateways would not have integrated the solution.  

   While sharing the cards in FPO, we merge the cards that exist in the current saved card vault and have been tokenized. There might be a scenario where the card is tokenized and exists in the saved card vault. At this point it is checked if the merchant supports token transaction processing or not. If token transaction is supported, then response 1 is returned else response 2 is returned.

   Response	IsCardCoft	isEligibleForCoft	isCoftPaymentSupported
   Response 1	Ture	False	True
   Response 2	False	False	NA

3. Based on isCardCoft and isEligibleForCoft, you can display the consent workflow to the user. It needs to be ensured that the consent provided is explicit in nature as mandated by RBI. Once the consent is provided by the customer, merchant calls the Process transaction API in the subsequent section.
4. If the card is tokenized and transaction processing is not supported on it, then complete card details need to be provided in the Process Transaction API. The reason these card details are returned is so that you can match the last 4 digits, issuing bank and card schemes with the fresh card details being entered by the user. Upon match, we recommend - 
   1. You may skip providing the consent to the user to avoid multiple tokenization of the same card.  As governed by RBI, soon issuers will create workflows to show merchant details where the user's cards are tokenized. Multiple tokenizations of the same card against the same merchant will be visible there to the user.
   2. Since this card was tokenized before by the user and still requires to enter complete card details, you can communicate the rationale of unavailability of the card that customer.

1. Fresh cards can be entered by the user. Merchant can also use his own vault wherein each saved card of his system will also act as a fresh card for Paytm.
2. Against the BIN of the new card, merchants can call the Fetch BIN API and get the isEligibleForCoft attribute. Based on these attributes, merchants can display the consent workflow to the user.

Tokenization Request with transaction request

1. Card tokenization request can be made along with the transaction processing request.
2. Customer needs to provide customer consent details taken in coftConsent object in Process Transaction API. This consists of details the timestamp, device details on which consent is provided.
3. Fresh card as well as well saved card details can be shared in Process transaction API as done today.
4. On successful user authentication, Paytm will trigger the tokenisation request. This will be an asynchronous workflow without impacting the in-process transaction. Post 31 Dec, once the transaction is completed, we will no longer share the BIN (First 6 digits of the card) in our Transaction Status API and Order Webhook.
5. Paytm will route the tokenization request to the respective card network and return a unique Token Index Number to you for further communication with the Token Gateway Service.
6. Paytm will store the mapping of the Token Index Number with your Customer and Paytm MID.
7. Paytm will notify you when the card is successfully tokenized with the card network and will pass all the Token info along with Token Status in Notify Token webhook response. The Token Index Number can be saved by you and used for subsequent card operations such as Generate Token Data, Get Token Info or Modify Token Status.
8. You can also query the status of your tokenization request by calling the Get Token Info API with a unique provision request Id as input instead of the Token Index Number. This requestId is equal to the merchant generated order id in case of in-line tokenization.

1. Merchant needs to pass the token index number (TIN) and CVV in card cardInfo in the Process transaction API.
2. Upon getting the request, we will validate if the transaction processing is supported on the requested token or not. If not supported, we will fail the attempted payment and provide the response.
3. If transaction processing is supported, then we will connect with the issuing bank via the banking gateways and card networks to process the transaction. In response, we will provide the Bank’s ACS page wherein customers can be redirected to complete the transaction process.