Just-in-time (JIT) funding is a way by which a transaction can be funded in real-time when sufficient funds are not available in the PPI account of the account holder.
In an ideal world, one needs to have sufficient funds in the corresponding account to be able to make a transaction. If the transaction amount is less than the account balance, then the transaction is declined. On the contrary, with JIT funding, one’s transaction can go through if the respective account doesn’t have enough funds. This is handled by assigning a credit limit to each of the account holders by the fintech.
For example, Shreya has been assigned a credit limit of INR 50,000. The balance in this account is INR 2,000. Now, she wishes to transact for INR 25,000.
This difference amount of INR 23,000 is the credit amount that will be requested. This requested credit amount will be transferred to the account of Account Holder Shreya. Given the balance of the account is now equal to the transaction amount, the transaction will be successful.
Before getting started, below are some of the key terms related to the topics
|Interceptor||Interceptors are HTTPS endpoints with the extra functionality of returning a response. The host of the interceptor then consumes the response and incorporates it in the request flow. Refer Interceptors for more information|
|SCLMS||SCLMS stands for Simple Credit Limit Management System. It is an internal system to assign and manage credit limits for Fusion accounts.|
|Zeta Switch||Payment switch that processes the incoming payment requests|
|Policy||Policies refer to the set of rules and conditions that a fintech can apply to an entity’s transactions at an Account Holder level. Refer to [transaction policies](https://fusion.zetaapps.in/docs/transactions/about-policy/) for more information|
The process of JIT Funding uses Interceptors (/docs/extensions/interceptor/about-interceptors/) to enable the fintech to take part in decisions during transaction processing, whenever a payment is initiated by the account holders. The process involves the following actors–
- Payment Gateway or Merchant
- Fusion (+ Zeta Switch)
Let us try to understand the JIT Funding process by taking the example mentioned above. Shreya is a customer of the fintech ZegWorld. ZegWorld is in the business of issuing payment cards to freelancers such as Shreya, who can request a credit amount to make purchases and then return the amount within 30 days.
Before being able to provide the JIT funding facility to their customers, ZegWorld will require a funding account with Fusion. This funding account acts as a source account for the transfer of the funding amount to Shreya’s account whenever the credit is requested.
At any time, if the funding account balance is less than the requested credit amount, the related transaction will be declined. In summation, ZegWorld is responsible for maintaining the respective balances here.
Creation of ZegWorld’s account with the IFI
This activity is a part of the onboarding process. Please get in touch with the Implementation Team for the set-up.
ZegWorld will first need to onboard Shreya as an account holder and assign the product bundle to her. Refer to the below steps
- Create an account holder: To create an account holder, the fintech will have to create an application. Once the issuer approves the application, an account holder is created. Please refer to Create Account Holder for more details.
- Assign bundle: Upon the creation of the account holder, the fintech will then call the bundles endpoint to assign the bundle to her. Please refer to Issuing a Bundle for more details.
ZegWorld may use its internal logic to compute the credit limit that can be utilised by Shreya. Let’s say that the maximum credit limit assigned to Shreya is INR 50,000. ZegWorld will further create a credit line and assign the credit limit to her using the below endpoint. This is like a lien extended to the account issued as part of the issueBundle call
Please refer to Create Credit Account API for more information.
After successful onboarding, Shreya visits a local shop to acquire some raw material. At this moment, her account balance is INR 2,000. She selects the items she wants to purchase and proceeds for payment, say, via POS machine.
At Fusion, the following checks are made to validate a transaction. Once fusion decides on the fate of the payment/transaction request, it conveys the success or failure of it to zeta switch via interceptor.
If the billing amount is less than INR 2,000 which is the balance amount in Shreya’s account, then the transaction will go about smoothly, else will be declined.
If the transaction amount is greater than Shreya’s account balance, then to be able to pay, she will have to use the credit balance. Say-
Here, fusion will make two checks–
1. Is the present credit limit available with Shreya ≥ Requested credit amount?
Shreya was initially assigned with a maximum credit limit of INR 50,000 by ZegWorld. Every time she utilizes the credit, her credit balance is reduced by that amount. For example, if she had previously utilized INR 10,000 from her credit balance, then she can only utilize INR 40,000 [INR 50,000 – INR 10,000] till she repays the credit amount- INR 10,000 to ZegWorld. That is,
So when the request for the credit amount of INR 23,000 is received, the system checks if the credit balance is available for the transaction. If so, then it moves to the next check, else the payment is declined
2. Is the present funding account account balance of ZegWorld ≥ Requested credit amount?
Each fintech sets up a funding account whose balance shall be adequate for fusion to initiate an account to account (A2A) transfer.
Hence, the system checks if ZegWorld’s funding account has enough funds for the system to initiate an account transfer to Shreya’s account. If so, then the transfer is initiated else, the payment is declined.
Case 2.1: Funding account’s balance [Z] = INR 1,00,000
As funding account’s balance [Z] > Requested credit amount [C], the payment is approved. The funding account’s balance [Z] is updated along with Shreya’s account balance[B] and credit balance [Y].
Case 2.1: Funding account’s balance [Z] = INR 10,000
As funding account’s balance [Z] < Requested credit amount [C], the payment is declined.
A fintech can intercept a payment request going out to a merchant on a particular card network, and based on its risk system’s logic and policies, direct Fusion to either approve or reject the request.
Let’s say that Shreya had defaulted her previous payment of INR 10,000 by 20 days. As per ZegWorld’s policies, she can’t use the credit balance until her previous dues are cleared. ZegWorld can configure such policies and interceptors by following the steps as in the Configure Interceptors section.
A fintech can use the range of APIs in the sections ahead to manage the respective credit lines- including credit line status, and balances.
Using the below endpoint, Fintechs can request the credit line details of the account holder against the respective bundle account ID. This account ID was created during Setting up the credit line.
It will return all the account related activity including the status of the credit line, credit limit allotted, present credit balance, date of creation and last modification, policy and webhook configurations.
Please refer to the API- Get account by account ID for more information.
Fintechs can call this API endpoint to update the credit balance in terms of decreasing the same, which can be due to any reason, say, the account holder- Shreya transacted using her credit balance. Following the example of transaction as in
Transaction Amount > Account Balance, INR 23,000 is requested from her credit balance. Hence, the
amount in the request payload will be 23000. Corresponding to it, the credit balance will be updated to INR 17,000.
Please refer to the API- Decrease credit account balance for more information.
Fintechs can call this API endpoint to update the credit balance in terms of increasing the same, which can be due to any reason, say, the account holder- Shreya paid back the amount taken up from the credit balance. Say, after the transaction above, she paid back the INR 10,000. Hence, the
amount in request payload will be set to 10000, and the corresponding credit balance will be updated to INR 27,000.
Please refer to the API- Increase credit account balance for more information.
Fintechs can update the credit limit against the bundle account ID by passing the updated credit limit amount against it.
Please refer to the API- Change credit account limit for more information.
Fintechs can update the status of the credit line of the account holder using the below endpoint. The status can be:
- ACTIVE: activating credit line for the account holder
- INACTIVE: suspending the credit line for the account holder
- DELETED: deleting the credit line for the account holder
Upon sending the request, the status codes will be received confirming the change.
- 204: change was successfully made
- 400: status couldn’t be changed which can be due to–
- incorrect account ID
- Changing state to ‘Active’ from ‘Inactive’ or ‘Deleted’
- Changing state to ‘Inactive’ from ‘Deleted’
Please refer to the API- Update credit account status for more information.
Audit log, also referred to as audit trail, contains the record of all the events and changes with respect to the account holder’s credit line. You can define the number of records by page and size.
Please refer to the API- Credit audit log for more information.
Once the payment is processed, ZegWorld can know the status of the payment by configuring the webhooks to receive the event message on its application’s endpoint.
/subscribe API to be able to subscribe to the webhook. The body of the API shall contain the callback URL (ZegWorld’s application endpoint)
In this example ZegWorld will configure webhooks on
PAYMENT_CAPTURED event and
PAYMENT_REQUEST_ DECLINED events.
Successful Payment: The callback URL associated with the PAYMENT_CAPTURED event will be called and ZegWorld will be notified of the successful payment.
Failed Payment: The URL associated with the PAYMENT_REQUEST_DECLINED event will be called and ZegWorld will be notified of the failed payment along with the reason for payment failure
These webhook payloads are secure as their authenticity can be verified with a secret token that Zeta shared with ZegWorld.
You can refer to these events on Fusion Event page for more information.