Payouts

Welcome to Payouts. This is a comprehensive reference for integrating with Plural for Payouts.

Payouts Overview

A payouts is the transfer of funds to a bank account or a wallet in the form of a deposit.

Large corporations and SMEs face major pain-points while utilizing traditional banking infrastructure to make payouts. Payouts and disbursals using the traditional banking infrastructure require cumbersome and non-flexible manual efforts. No impactful insights or analytics can be viewed using the traditional platforms. Bulk transfers can also happen via traditional banking platforms by uploading a spreadsheet on the banking portal or manually adding every beneficiary before transferring. But in such cases, a single error in a payment file can block all the bulk payments. Additionally, adding new beneficiaries is never instant.

By utilizing existing the proposed payouts features, merchants can:

  1. Make bulk payouts even if there are invalid records in a file, by ensuring that valid transfers go through.
  2. Receive reconciliation support for failed and invalid transfers so that merchants always know which transfer failed out of hundreds of payments, and why.
  3. Add beneficiaries instantly.
  4. Automate payouts using APIs to make 24*7 refunds and payouts to customers, partners and vendors for better UX.
  5. View financial summaries of payouts transactions to make better decisions.
  6. Remove transactional risks by enabling a maker-checker flow.
  7. Split marketplace payments to multiple vendors or stakeholders.
  8. Share Payouts Links with customers, vendors and partners who can add their details and receive payouts instantly.
2722

Payouts Integration

Dashboard Payouts

Make payouts easily and quickly from the dashboard. Keep it simple with dashboard payouts. Start making payouts by entering payee's account details or UPI handle in minutes. Dashboard Payouts will work on Current Account Model where merchant current account will be used as source account for the Payouts. Plural is partnership with YBL (Yes Bank) for this integration.

API Payouts

Make payouts easily and quickly by integrating with Plural Payouts API. API Payouts will work on Virtual Account Model where merchant virtual account will be used as source account for the Payouts. Plural is partnership with ICICI Bank for this integration.

Payouts Functionality

Beneficiary Creation

  • Single Beneficiary Creation
  • Bulk Beneficiary Creation
  • Penny Drop Testing to validate Bank Account

Payouts

  • Single Payouts
  • Bulk Payouts
  • Initiate Now
  • Schedule it Later

Maker and Checker Verification

  • Beneficiary Creation
  • Payouts

Payouts Mode

Payouts can be made using any one of the following payouts modes. The transaction limits and operating hours for each Payouts mode is listed in the below table.

Current Account - YBL Integration

Payouts ModeAmount Limit Min Per TransactionAmount Limit Max Per TransactionProcessing Hours
UPI₹1Upto ₹1 lakhCredited immediately on all days 24x7
IMPS₹1Upto ₹5 lakhCredited immediately on all days 24x7
RTGS₹2,00,000Upto ₹10 croreCredited in 45 minutes between 8:00 a.m. and 4:20 p.m. on RTGS working days. *
NEFT₹1,000Upto ₹10 croreCredited within 2.5 hours between 8:00 a.m. - 7:00 p.m. on NEFT working days. *

Virtual Account - ICICI Integration

Payouts ModeAmount Limit Min Per TransactionAmount Limit Max Per TransactionProcessing Hours
UPI₹1Upto ₹1 lakhCredited immediately on all days 24x7
IMPS₹1Upto ₹5 lakhCredited immediately on all days 24x7
RTGS₹2,00,000Upto ₹50 CrCredited in 45 minutes between 9:00 a.m. and 4:00 p.m. on RTGS working days. *
NEFT₹1Upto ₹50 CrCredited within 2.5 hours between 8:00 a.m. and 6:30 p.m. on NEFT working days. *

Beneficiary Creation

Beneficiary Creation workflow

  1. Maker creates new beneficiary with validated bank details
  2. Beneficiary is queued in Beneficiary List page in ‘SUBMITTED’ status
  3. Checker filters the list for beneficiaries in ‘SUBMITTED’ status
  4. Checker verifies the details and sets status as ‘Active’ or ‘Inactive’
  5. Maker role is able to create a payouts

Maker-Checker validation

Merchant can enable two step authentication for a payouts transaction with approval authority for certain roles as specified below

Roles and Responsibility for Beneficiary Creation

  • Admin to create ‘Maker’ role which will be able to create new beneficiaries for a regular or bulk payouts
  • Admin to create a ‘Checker’ role which will be able to verify and approve the beneficiaries added by ‘Maker’ role/s
  • Maker roles are only able to add beneficiary details which will be queued for verification by only the ‘Checker’ roles
  • Payouts cannot be created for beneficiaries queued for verification by Checker roles
  • Beneficiaries created are sent in ‘SUBMITTED’ status until 'Approved' or 'Rejected' by Checker roles

Payouts Creation

Single or Bulk Payouts Workflow

  1. Maker creates an individual or bulk payouts for a beneficiary
  2. Payouts and/or beneficiary is created and queued for verification
  3. Payouts is displayed in the Payouts List page with status ‘Pending’ and/or beneficiary is listed under Beneficiary List with ‘SUBMITTED’ status
  4. Checker filters for Beneficiary List for ‘SUBMITTED’ state
  5. Checker edits the Beneficiary details and activates beneficiary addition
  6. Checker filters the Payouts List for ‘Pending’ payouts
  7. Checker edits the payouts
  8. Checker verifies details and sets status as ‘PROCESSING
  9. Payouts is initiated for transfer
  10. Dashboard is updated with status

Single Payouts

Roles and Responsibility for Single or Bulk Payouts

  • Maker roles will create a payouts for new or existing beneficiaries
  • For existing beneficiary, queue the created payouts for verification by checker roles and assign a “Pending” status
  • The payouts can be put in ‘Processing’ state by the checker role
  • For new beneficiary created, queue the beneficiary for verification by checker role and queue the payouts as well
  • Payouts can be created and also be initiated by checker roles and admin
  • Maker roles are able to view the list of Payouts in all status

Scheduled Payouts Workflow

  1. Maker role can create payouts for immediate initiation or can scheduled the same for later
  2. Payouts scheduled for later must not appear in top of the queue to avoid delay or failure if not verified by checker in time
  3. In case, no action is taken on a queued payouts by Checker role, when the payouts reaches or exceeds its scheduled date, then fail the payouts

Payouts Lifecycle

A payouts lifecycle will have the below statuses during life cycle

  • Pending
  • Scheduled
  • Queued
  • Processing
  • Processed
  • Reversed
  • Cancelled
  • Rejected
  • Failed

Pending

If the Approval Workflow feature is enabled on the account, a payouts is assigned the pending state if the payouts requires approval by checker roles, according to the workflow setup.

At this stage, the payouts details are stored in the system, but the state will require approval from checker roles to move to Verified state. No processing has been done either by Plural Payouts or the contact's bank.

Action Required

The payouts remains in this state until and unless the payouts is approved/rejected by the required user(s).From the pending state, payouts can either move to the:

  • queued state if the account doesn’t have sufficient balance to process the payouts.
  • scheduled state if you have scheduled the payouts.
  • processing state if you have sufficient balance to process the payouts.
  • rejected state if you reject the payouts or if you did not approve the payouts before the scheduled date and time

Queued

A payouts is assigned the queued status only when there is not sufficient balance in the account.

At this stage, the payouts details are stored in the system, but no processing has been done either by Plural Payouts or the client’s bank

Action Required

The payouts remains in this state until you add sufficient funds to your business account.
From the queued state, payouts can either move to the:

  • processing state when you add sufficient balance to process the payouts.
  • cancelled state if you cancel the payouts.

Scheduled

The payouts remains in the scheduled state till the scheduled date and time is reached. At this stage, the payouts details are stored in the system and would require verification by the checker role to move to ‘Verified’ state.

No processing can be done either by Plural Platform or the contact's bank before payouts is moved to ‘Verified’ state.

From the scheduled state, payouts can either move to the,

  • processing state when the scheduled time is reached post payouts is ‘Verified’ by checker role
  • cancelled state if you cancel the payouts before the scheduled time
  • failed state if you do not have sufficient balance to process the payouts.

📘

Note

The queued state does not apply to scheduled payouts.

Processing

A payouts can acquire the processing state in one of three ways:

  • From the verified state, when the designated person approves the payouts and you have sufficient balance to process the payouts.
  • From the queued state, when you add sufficient funds to your account to process the payouts.
  • Immediately, when a payouts is created if you do not have the Queued Payouts or Approval Workflow feature enabled on your account.
  • At this stage, either Plural Payouts or the contact's bank could be processing the payouts. No further action is required by you while a payouts is in the processing state.

📘

Note

IMPS and UPI payouts can remain in the processing state for T+2 working days.

From processing state, payouts can either move to the:

  • processed state if the payouts is successful.
  • reversed state if the payouts fails.

Deemed Success

Payouts made via IMPS and UPI can be in the processing state for up to T+2 working days. This happens since NPCI marks these payouts as deemed success or deemed approved. Below is how a payouts is processed from when it is authorized by you to when you receive the terminal payouts state (processed/failed/reversed).
If NPCI is successfully able to credit money to your beneficiary account, it returns a success status to the partner bank who in turn returns it to us and we mark the payouts as processed.

If NPCI is not able to credit money to your beneficiary account, it returns a failed status to the partner bank, who passes the status to us and we mark the payouts as reversed.

Sometimes, there are technical errors when trying to credit the payouts to the beneficiary account. When this happens, it is not possible to be certain if the payouts was credited to the beneficiary. In such cases, NPCI moves the payouts to an intermediate state (deemed success). From this state, the payouts can go to the processed, failed or reversed state.

When we receive the deemed success from NPCI, we do not move the payouts to a terminal state. We do this to avoid returning a false positive state to you. Instead, we keep the payouts in the processing state till we receive the final status from the partner bank.

Once the transactions in the deemed success state are reconciled by the beneficiary bank and NPCI, we receive the final status from the partner bank and move the payouts to the terminal state (processed/failed/reversed). This could take T+2 working days.

Processed

  • The processed status means that payouts has been processed by the contact's Bank.
  • A payouts in the processed state can move to the reversed state if a payouts failure is detected.
  • This can happen due to various reasons such as the customer's bank reversing the transaction or if the payouts was reversed by the clearing house.

Reversed

  • A payouts acquires the reversed state when the payouts operation fails. This can happen due to issues with our partner banks, clearing house or even the customer's bank.
  • As soon as Plural Platform identifies a payouts failure scenario, it moves the payouts to the reversed state and creates a reversal transaction that credits your business account with the original payouts amount and fees and tax (system should be flexible enough to process it for individual clients).
  • No further action is possible on a payouts in this state.

Rejected

A payouts in the pending state acquires the rejected state when:

  • It is manually rejected by you.
  • It is not approved by you before the scheduled date and time.
    No further action is possible on a payouts in this state.

Cancelled

A payouts can reach the cancelled state when the user manually cancel a payouts in the:

  • queued state. You can cancel a payouts in the queued state either from the Dashboard or using APIs.
  • scheduled state. You can cancel a payouts in the scheduled state from the Dashboard
    A payouts that has been cancelled acquires the cancelled state. No further action is possible on a payouts in this state.

Failed

This status is applicable only when a payouts is made using the current account balance.

  • Payouts in the processing state move to the failed state when they are failed by our current account partner bank.
  • Payouts in the scheduled state move to the failed state if you do not have sufficient balance to process them.
    No further action is possible on a payouts in this state.