Grievance Redressal

Introduction

This Customer Grievance Redressal Policy (“Policy”) has been approved by the Board of Directors of Instanow Info Systems Private Limited (“Instifi”), an RBI-authorised Payment Aggregator, and is framed in accordance with the Master Direction on Regulation of Payment Aggregators and applicable RBI guidelines, as amended from time to time.

All policy matters bind all participants, i.e. Customer, Merchant, and Payment Aggregator (Instifi), and contain detailed explanations of the types of disputes, the process of dealing with them, the compliance required, responsibilities of all stakeholders, documentation, reason codes, procedures for addressing grievances, and turn-around-time for each stage.

Instifi has provided details of multi-level support as well as the Designated Director and Nodal Officer responsible for regulatory and customer grievance handling functions.

Dispute Resolution Mechanism

Customers can raise dispute on shipped orders for the following reasons:

• Transaction amount is different
• Request is made for the copy of the receipt
• Settlement/payout not received
• Suspected fraudulent transaction investigated by the acquiring bank
• Multiple charges for the same order
• Merchandise not as advertised
• Customer did not engage in or authorize this transaction
• Merchandise has not been delivered
• Cardholder is not in possession of the card used for the transaction
• Service not received from merchant
• Order was cancelled
• Customer paid for order by other payment method

How we manage disputes:

At Instifi only the Customer or Instifi can raise disputes. The merchant can view all disputes raised on their transactions in their Disputes Listing Page. They can also provide updates as well as submit required documents for the dispute via a 3-way messaging facility between Instifi, the merchant, and the customer.

1. Supporting Documents

   Instifi may request for a set of supporting documents for cases that need further investigation. These documents could include the Authorization Letter from the customer, Cancellation Policy, etc. Merchants can respond by attaching the required documents with a clarification message using our messaging facility. This can be uploaded from the Dispute Management module.

2. Dispute Resolution

   Instifi team can either close the dispute in the merchant’s favour or allow chargeback to the customer. The Dispute status can be: ‘Open’, ‘Chargeback’, ‘Closed’ and ‘Open and Hold’. After the dispute status has been set to ‘Open’, or ‘Open and Hold’, Instifi can update its status to ‘Closed’ or ‘Chargeback’. If the open dispute is confirmed as chargeback, Instifi will debit the dispute amount in the customer’s favour and set the status as ‘Chargeback’. Similarly, if the open dispute is closed in favour of the merchant, Instifi will update the dispute status as ‘Closed’.

3. Resolution of ‘Open and Hold’ Cases

   Instifi designates the status as ‘Open and Hold’ for disputed cases that need further investigation and sets the amount as well as the end date for resolution. The amount set aside for resolution at this stage cannot be greater than the disputed amount. Different types of resolution for ‘Open and Hold’ cases:
   • When the time limit set for the ‘Open and Hold’ case is over and the dispute status has not changed, Instifi will release the amount held against the dispute and close the dispute.
   • After further investigation, when Instifi changes the status for the ‘Open and Hold’ case to ‘Chargeback’, the amount set aside for resolution (the balance amount payable) is treated as the chargeback amount and debited from the merchant’s account in favour of the customer.
   • When Instifi changes the status for the ‘Open and Hold’ case to ‘Closed’, the amount set aside for resolution is ruled in the merchant’s favour i.e. credited to their account.

Refund processing Timelines

Instifi has a very stringent mechanism to deal with refunds of failed transactions (transactions charged to customer but not returned to Payment Aggregator and, in turn, to merchant, hence no services are rendered). As per the merchant’s line of business, they can opt to configure their account to reverse such transactions or get it updated as a successful transaction post reconciliation, and continue to provide services. We can reconcile dropped transactions in 2 ways:

• We initiate server-to-server API calls with banks on a periodic basis throughout the day to fetch the status of transactions. Such cases are sent to the bank for reversal on T+1.
• For banks who do not provide the API-based reconciliation mechanism, we reconcile with the offline files received from the banks on the next working day. Thus refunds for such transactions are sent the next day post reconciliation or T+1 post reconciliation.