didn't get this

*for multiple NBFCs

We should say instantly once the payment is captured

this is can't be enabled per trasnsaction, the features works on per txn basis but its enabled for all txns

Does this mean this will be available only via API and not dashboard and webhooks?

And also on the dashboard. Lets also add a screenshot from the dashboard

Status details is available for all payout statuses including intermediate status like pending, processing and terminal states like reversed, failed, etc

Lets also specifically call out when error object should be used

This is a generic webhook section, are we not talking about status details here? What is the purpose of this section?

We should have a specific call out that other objects will not be supported.

This was added earlier, not sure why it was removed (Ref https://docs.google.com/document/d/17slaVEjmveSfF1b9Nben1boNR5zUL0zlqh5VX7PvmvE/edit )

"The ‘failure_reason’ field, ‘error’ object,’queueing_details’, ‘cancellation_details’ would be deprecated from the API response in a few days after enablement to reduce redundancy"

This is not payout status, this is status details. Also do we need this section?

Below are the sample status details responses that appears as part of the status details object.

Download the table to view exhaustive list of status details, their corresponding payout statuses and also possible steps you can take to proceed further.

Can we rename this to Status details API response, payout status responses is not the correct heading

Please remove failure_reason from all places in the doc

Lets specifically call out when error object has to be used and when status details has to be used

We need to remove this section completely. We need to replace this by payout status details or link it to the status details page

Status details are sent as part of the fetch payout API response and webhook payloads. It provides additional details about each payout status including intermediate status like pending, processing and terminal states like reversed, failed, etc. A payout update webhook is fired every time an attribute in status details changes.

Can we rephrase this to something better?

Like: Create multiple sub accounts on top of a single bank account to manage funds in a safe and compliant way

sub accounts

what does this mean?

Respective ledger entries are recorded

add dummy names for customers

lets take dummy names

can we take dummy names like acme corp instead of alphabets

limit

the add limit option

increase

Debited

accounts

to enable their LSP to trigger loan disbursals in a secure and compliant way.

Lets skip this

Lets also add -Using this account, master merchant can add limit to the sub account via the dashboard.

Can we also say they can see the real time limit balance of their sub account

Using this feature, NBFCs will also be able to ensure that loan disbursals flow from their account to the borrowers accounts and hence stay compliant with the digital lending guidelines.

Using this feature, NBFCs can work with multiple LSPs on a single bank accounts. NBFCs can provide secure, restricted access to LSP to enable loan disbursements to their customers

This feature can be used by NBFCs...

the LSP needs access to initiate loan disbursals to their customers

These are static limits, i.e once the sub account consumes this limit, the master merchant will have to replenish it.

Once a sub account initiates a payout, limit on the sub account will be reduced and the money movement will happen from the bank account of the master merchant.

Using this feature, merchants can create multiple sub accounts, and manage payouts for multiple businesses/use cases via a single bank accounts

The master merchant can allocate amount limits to each sub accounts. Each sub account will have their own RazorpayX merchant dashboard, API keys, users, approval worflows etc

Skip this part here. We should add it separately

to allow a master merchant with a bank account to create and manage multiple sub accounts on top of this bank accounts.

We should restrict this page only to API errors, for everything else merchant should use status details. We may have to revamp this page

We should replace this with status details

Lets remove this and club NEFT, RTGS

replace with etc

Bank window closed in case of NEFT and RTGS

Add mode card

On credit cards, all networks are supported. For debit and prepaid cards only specific networks are supported

Can we split this into credit and debit card sections and have network as a column

We support prepaid cards also

this is the list of cards supported on the mode 'card'. We need to add this to the docs https://docs.google.com/spreadsheets/d/1FJbg-fos4ZiAUj85yAgpJ6ZRemNNVZPcYCCAW70Il9s/edit#gid=0

Make payouts directly to a beneficiary's credit card by bank transfer using NEFT or IMPS Make payouts directly to a beneficiary's debit, prepaid card by using the mode card

Both DC and CC work on different modes, we need to convey that separately

There is also a list of cards/bank we support, we should add that to the docs and link it here

Can we add prepaid card also

Can we remove/change this? amazonpay should be in lower case only

Lets also call out that Amazon brand guidelines and T&C needs to be followed, violation of the same could result in the feature being blocker

Can we add a disclaimer stating that the APIs for Amazon pay remain the same, only the API request and response value change? Since this looks like a doc just for amazon pay

the image is not rendered on the site, any idea if this is a beta site issue or docs issues?

asset

Can we add something else here istead? like - You can make payouts to amazon pay wallets using your RazorpayX accounts

Can we mark this as X, we don't support this right now. Once we add the support, we can update the document

Lets also add the below points:

• The customers who receive money on their Amazon gift card balance cannot transfer it to their bank account

balance

Can we replace this with:

You can make payouts up to ₹10,000 (per transaction) to the Amazon account of your beneficiary. The amount will be deposited to the Amazon pay gift card balance of the beneficiary.

can we skip this?

amazonpay

for amount greater than 10k, a new payouts can be initiated

wallet as a section and amazon pay as a subsection

can we add wallet section and have amazon pay as a sub section

this is mandatory for amazon pay only, not for other wallets

there has been a change in the API structure here based on API council feedback. Please check this once https://docs.google.com/document/d/10XfLSY_dNGKATS1518GFTeVnG-EqktmVRD4xUMwsNuc/edit#heading=h.q07m0owjmkm3

for amazon pay email is not required, phone number is compulsory, email is for other wallets (but we don't support them right now)

can we call out that for amounts greater than 10k, they can create a new payout

lets add amazonpay here

skip

amazonpay

not supported for amazon pay, since its optional. we can skip in this section

this was changed based on feedback provided by API council, this is in lower case now ('amazonpay'). We will also accept it in upper case (but will be transformed to lower case by us)

Can we add a wallets section here and then add amazon pay as sub section?

Is the original hyper link not available?

Custom narration is not supported on Amazon pay, where can we add this?

Can we also call out that there is no limit on the amount of balance that a customer can have in their Amazon pay gift card balance

Amazon pay works only with phone number. Amazon pay gift card is not sent to the contact. Whereas the money will be credited to the Amazon pay gift card balance

the field is provider and AMAZONPAY should be in lowercase ('amazonpay')

Lets call this as Payouts to wallets section, amazon pay is one of the wallet types that we support. Within this lets add an amazon pay section

need to remove 'the'

is it 'in turn' or 'inturn'?

Please use beneficiary, instead of contact everywhere

Before starting with this, can we add a brief above this section? Something like this: IMPS and UPI Payouts can be in processing for upto T+2 working days, this happens when NPCI marks these payouts as deemed success or deemed approved'

the payout can either move to processed/reversed

'In order to avoid false positives' - does this sound better?

not NPCI but the partner bank returns the status to us

Can this be rephrased? Difficult to understand from the existing sentence

Can we add a diagram for the deemed success flow as well?

We need to add reversed to this

We need to add reversed to this

TAT here is T+2 working days

We receive the final status from our Partner bank

TAT is T+2 working days

This comment is for the diagram:

RazorpayX talks to partner bank and not NPCI directly, also can we Beneficiary bank instead of contact bank everywhere?

Deemed success is applicable only for IMPS and UPI payouts, we need to call this out