Specifications for Departments to use Collection Services of RPP

Onboarding department on Rajasthan Payment Platform for collection services is just a matter of 2–5 days. The entire story depends on speed of submission of mandatory documents and incorporation of modules in departmental application that are required once the system is functional.

Today we are going to discuss the various requirement that need to be completed by end-user department before making system live at their end. All the requirements are further tagged as mandatory, optional or in-parallel which means, mandatory requirements need to be completed before going live whereas in-parallel requirements need to be closed within 15–20 days of making services live.

Let’s start with all the items included in the checklist of RPP Collection go-live system-

Documents required for Onboarding (Mandatory)

Entire story starts with submission of Letter of Intent (LOI) from department willing to use Rajasthan Payment Platform Collection services for collection of funds through their departmental website. To start with, departmental team need to submit two basic forms –

  1. RPP Collection-Merchant Onboarding Form (Annex-A)
  2. RPP Collection-Bank Account Details Form (Annex-B)

Annexure-A is about details of department/organization and its nodal officer, duly seal-signed by the competent authority (Director / Commissioner / Secretary).

Annexure-B contains details of bank account where funds needed to be credited by Payment Gateway service provider on T+1. This form should be duly seal/signed by account signatory and cross verified by bank/branch.

NOTE: Bank account specified in Annexure -B must not be dormant and should be in the name of organization itself. If the account is dormant or inactive, then penny test done by payment gateway during onboarding process can get fail resulting into delay in onboarding process.

Along with above two filled-in forms, department need to submit following mandatory documents to start onboarding-

  1. Letter of Incorporation of the Organization/Department/PSU/
  2. PAN / TAN Card of Organisation/Department or Corporate Office
  3. GST Registration No of Organisation/Department or Corporate Office
  4. ID Proof of Nodal Officer
  5. PAN Card of Nodal Officer

Agreement between RISL & Department /Merchant (In-Parallel)

For every service of RISL (under any project), department need to sign an agreement with RISL, or we can say that both the parties sign a Memorandum of Understanding (MoU) that defines role and responsibilities of each party.

Under collection services, this MoU/Agreement covers the scope of duties to be performed by both the entities and timelines within which response is expected. As RISL is extending its Payment Gateway service, provided by various 3rd party payment gateway service providers, to the user department, this agreement covers chargeback, settlements, refunds and cancellations as major points where timely response is expected from departmental team.

Agreement can be executed in parallel to other processes like development, UAT, security audit, getting production credentials. However, it is required to be completed within 15–20 days of making system live.

Application Development & UAT

Departmental team should focus on development of all major modules within its application incorporating the various API’s exposed by RPP system. In general, following things should be covered by application-

  1. Payment Cycle (Mandatory): Application should completes user data capture process (as a part of some form) before asking user to make payment. Once user reaches payment page, user need to be redirected to Rajasthan Payment Platform page for completion of payment. After successful payment, user will be redirected back to departmental application where application should provide receipt of successful payment or notify user for any failed payment.
  2. Receipt Generation (Mandatory): For each successful transaction system should generate receipt as a proof of payment (recommended to have pdf). This receipt should contain all details about transaction like — PRN (Department Payment Reference Number), RPPTxnId, Date of Transaction, Date of Updation of Payment, Amount, PG Ref No/Bank Ref No and Name, email, mobile of user etc. These details will help in establishing relationship between departmental transaction number and bank payment reference number and protect any dispute raised by citizen or bank. System admins must have provision to generate this pdf receipt for any transaction.
  3. Verification API (Mandatory): Application must provide some interface, both to the end-user making payment and to the departmental administrators where system can call Query API/Verification API of RPP system to re-verify the status of any transaction. This API will be used by users to verify status of pending and failed transactions at any moment of time (After 10 minute of initiating transaction). Similarly system admin’s can use this feature to update final status of any pending or failed transaction on daily basis or as and when required (on consumer’s complaint or as a part of daily recon activity).
  4. Refund API (Optional): Department should take care of duplicate payments and cancellation request from citizens (if citizen don’t want to pay and want his/her money back). To raise any refund to return funds back to the citizen (example for duplicate payments), departmental application should have provision to be given to administrators where-in admin’s can select the transaction to be refunded. On button click, system should call RPP Refund API in backend. On receipt of call from application, RPP system submits this request to the payment gateway for further processing and refunding fund to the end-user (citizen). Refund API call can get failed in following two cases — refunds failed for those transactions for which there is open chargeback and also where refund request is submitted beyond 90 days of transaction initiation. Note: As a security measure, department should get its’s public IP’s whitelisted at RPP system to enable call to Refund API i.e., without whitelisting no refund request can be submitted to RPP.
  5. Webhook (Optional): — Webhook API is an API exposed by departmental application to which RPP system will push successful payment notification i.e., for every successful transaction as soon as it got updated in RPP system, a webhook call will be made to departmental application for further updation of transaction status. This help departmental team to avoid putting some schedular for re-verification of transaction status. NOTE: Webhook must support updation of status against failed transaction because sometimes it may happen that a transaction which is previously reported failed, can be received as successful after reconciliation between bank and payment gateway.
  6. Transaction Query API(Optional): This is one of the best API exposed by RPP system which returns list of all successful transactions on a particular Date. To automate the process of reconciliation, departmental team can implement this API to fetch and update status of all transactions that are successful in RPP system. However, in case department is expecting high volume of daily transaction then calling this API is not recommended because it any result into time-out. In that case, it is recommended to do file-based reconciliation (as explained below).

Bank Statement Reconciliation Module (Optional)

It is always recommended to have bank settlement reconciliation module within core application of department. This will enable department to have end-to-end reconciliation of every transaction with funds received in bank account. Funds are settled directly by Payment Gateway Service Provider in the Bank account of department specified during onboarding.

Generally, all funds are settled on T+1. In case funds are not received by Payment Gateway itself, then settlement may be delayed for the selected transactions only.

For reconciliation of funds, department will require — settlement report from payment gateway (downloade from PG portal or received via email), report from RPP (received daily by email or downloaded using Transaction Query API as specified above or downloaded using RPP Portal) and bank statement in csv or excel.

Department team should do two different recon activities:

  1. Match single credit received in bank account with sum of all entries specified in settlement report provide by PG.
  2. Match one by one department portal transactions with transactions specified in settlement report received from payment gateway (using RPP Report as linking report)

By performing above specified two recon activities, department can mark fund received date (bank credit date) against each of their transaction. This way department can track-back any transaction for which fund are not received or funds are received in duplicate, or funds are reversed (via refund) or funds are debited against charge backed transactions.

Refund and Cancellation Policy on Portal (Mandatory)

It is mandatory for department to clearly display its refund and cancellation policy on its own home page of website/portal. Generally, payment gateway denies to provide its collection services in absence of these policies.

Departments generally quotes — “We don’t have any refund or cancellation policy”. This may be true when department is providing offline services and getting payment via cash/challan/offline modes.

But in this dynamic world when department itself is moving to provide digital services and accepting funds via online modes through various payment instruments like Net Banking, Credit/Debit Cards, Wallets, UPI or QR, it not recommended to have ZERO refund policy.

Many a times, consumer or citizen makes multiple payment against same service (considering that earlier payment is not successful) and later they come to know that all payments are successful and settled to department or sometimes, consumer want’s their money back as they decided to not to take service from department. To handle all these cases, department should clear states its refund and cancellation policy.

Additional Resources

In addition to all the above points, following things will be provided to department to help them in reconciliation of transactions and funds-

  1. Access of Rajasthan Payment Platform Portal: Department team need to share SSO-ID of its users (any number of users) to be mapped in system and get access to transaction search and report module on RPP.
  2. Access to Portal of Payment Gateway: Department team need to share Name, designation, email and mobile of one user who will gain access to settlement report section. Using this portal, settlement report can be downloaded (within 90 days) and used in reconciliation of daily received funds.
  3. Bank Statement (CSV or Excel): Department must have access to the net banking system of their bank account that enable them to download statement in csv or excel file format and use that for reconciliation of funds in account.

Closure Note

If department take care of all the functionalities specified above in this blog, department users will feel relaxed, and they will be able to answer queries to their users within stipulated time-frame. If anything is not ready at the time of go-live, then also, it is recommended to work on all these sections to make system easy for everyone.

Scroll to Top