HomePayment PageAPI ReferenceDiscussions
Hey! These docs are for version 3.2, which is no longer officially supported. Click here for the latest version, 1.0!

App flow

Suggest Edits

Onboarding

  1. A consumer signs up on Sahay by entering his mobile number and verifying via OTP
  2. Subsequently, he’s asked to enter his GSTN username, GST Number and submit an OTP triggered to the GSTN-linked mobile number.
    • Note: This number may or may not be the same as the number consumer used in step 1.
  3. This “GSTN linking” allows Sahay to fetch the GSTN invoices raised by the MSME.
  4. Behind the scenes, Sahay will now create a loanApplication for every eligible invoice with each lender.

Data Sharing

  1. After showing the MSME its invoices, Sahay will request permission to share this data with potential lenders.
  2. This data sharing will happen via an account aggregator SDK embedded within Sahay.
  3. The borrower signs up on an AA (using the same mobile number as authenticated with Sahay), links his/her bank account and GSTN and provides consent for sharing this data with the lenders.
  4. This received data can be used by the lenders to judge all the loanApplications submitted by Sahay (on behalf of the borrower).

Loan offers

  1. Having received borrower data from the AA (GSTN, bank account statements, basic profile information) and Sahay (PAN?, Name, etc.), each lender should analyze these data points and create loanOffers.
  2. A lender can return one or more loanOffers per loanApplication. In other words, lenders will create one or more loan offers per GSTN invoice.
    • In Phase 1, we’ve requested all the lenders to keep similar terms on each loanOffer i.e. all lenders should offer to fund 95% of the invoice amount and keep interest rates around 13-15%.
    • In Phase 2, lenders could create multiple offers based on the risk involved. For eg: one loan offer could fund 80% of the invoice at 13% interest while another could fund 95% of the invoice at 16% interest.
  3. Since all lending is expected to happen against an invoice, lenders should ideally assess each invoice in isolation.
    • Such assessment could happen based on attributes such as buyer history, previous relationship between buyer & seller, availability of proof of delivery (E-way bill) etc.
  4. Lenders who define “risk limits” at a borrower level should nevertheless rank individual invoices so as to be ready for disbursals against any one of them.

Offer acceptance

  1. Having received multiple loanOffers, the MSME will choose a single offer and proceed.
  2. The selected offer will get attached to the MSME’s loanApplication and a formal acceptance will be requested via SMS OTP.
  3. This SMS OTP will be triggered directly by the lender and Sahay will facilitate OTP submission by the borrower.
  4. Thus, a loanApplication becomes accepted.

Disbursement

  1. A loanOffer should mention the account the lender wants to disburse funds to.
    • Typically the priority order for such disbursements is expected to be: Working Capital a/c, Current a/c, Savings a/c.
    • In Phase 1, the borrower doesn’t get to change the disbursement a/c. In later stages Sahay might facilitate this via setDisbursementAccounts API.
  2. Similarly, LSP apis support the notion of disbursement plans to facilitate scheduled disbursements. This could be used by lenders (if they wish) to offer staggered loans to consumers (education loans for example.).
    • In Phase 1, only one-time disbursement plans will be supported.

Repayment

  1. The loanOffer should also mention the repayment plans supported by a lender.
  2. The most important fields in a repayment plan are:
    • Frequency of repayment (one-time, weekly, monthly etc.)
    • Expected amount
  3. A repayment plan only becomes active once the associated method is authenticated.
    • In other words, once the borrower chooses a monthly/one-time repayment plan, Sahay will request a lender to return a paymentUrl.
    • This URL will be opened by Sahay and consumers will have to enter their UPI VPA, receive a collect request and approve the E-mandate. Post approval, lender’s shall close the page and inform sahay about the successful setup of the repayment method (via webhook/status APIs).
    • In future, lenders might independently add support for other repayment methods (such as E-NACH).

Data Sharing

  1. After the repayment plan, disbursement plan, and disbursement account have been set, Sahay will request permission to share this data with potential lenders, and provide monitoring.
  2. This data sharing will happen via an account aggregator SDK embedded within Sahay. The borrower provides consent via the LSP for sharing this data with the lenders.
  3. This received data can be used by the lenders to monitor the plans and account submitted by Sahay (on behalf of the borrower).

Grant Loan

  1. All the above steps completed, Sahay will submit the loanApplication for a lender’s approval (via grantLoan API).
  2. At this stage, the lender must make last minute checks (such as verifying the repayment method is active, borrower’s conditions haven’t materially changed etc.) and create a Loan.
  3. The Loan thus created should be logged by the lender in PCR.
  4. Lender shall return a loanId to Sahay for keeping track of future updates to the loan object.

Disbursement

  1. Post receiving the loanId, Sahay requests the lender to disburse funds to the borrower.
  2. Lender shall initiate an appropriate IMPS/RTGS/UPI request and deposit funds in the disbursement account.
  3. Should the disbursal request fail (due to any reason), the lender should inform Sahay via a failure request.
  4. Sahay/lender shall retry the disbursement three times before informing the borrower about the failure and cancelling the loan.

Collections

  1. Once the loan amount becomes due, Lender shall intimate Sahay about the upcoming repayment deadline.
  2. Sahay will inform the borrower (via push notifications, email/sms messages etc.) about the upcoming deadline.
  3. The borrower will thus ensure sufficient funds are present in his bank account to enable repayment.
  4. Lenders can collect these funds via UPI E-mandate or E-NACH at the due date.

Handling NPAs

  1. Assuming a borrower doesn’t have sufficient funds on the due date, the lender’s E-mandate will fail.
  2. In such a scenario, following steps will be taken:
    • Lenders shall report the failure to PCR as well as Credit bureaus.
    • Sahay will prevent the borrower from taking any new loans from the Sahay platform.
    • Repeated reminders shall be sent from both Sahay and the Lender to facilitate repayment.
  3. If the borrower doesn’t repay the loan (including late fees) by the 30th day, lenders will assign Relationship Managers to facilitate loan recovery.
    • RMs shall speak to the borrower via Phone/In-person and encourage timely repayment.
    • If the borrower doesn’t repay the loan by the 45th day, lenders shall have the right to declare the borrower as NPA and file court proceedings for recovery purposes.

Requesting more data

  1. In Phase-1, lenders are expected to work with the GSTN and bank account data to make decisions on the loan. Hence a loanApplication should receive offers or Sahay will consider it to be rejected by the lender.
  2. In Phase-2, Sahay will facilitate additional data collection basis the lender’s response to getOffers API.
    • Lender’s will be able to indicate additional documents needed such as proof of delivery documents, board certificate, authorization from all partners etc.
    • Sahay will appropriately inform the borrower and facilitate collection of this information.
    • getOffers will be called again once the appropriate information has been placed inside the loanApplication.

Updated 9 months ago