Just in time Funding
In this section, you can understand how Fusion can solve for the lending / Just in time funding use case of the Fintechs. Fintech provides a Credit Line and a Card to customers where instead of taking a personal loan, they can utilize the Card to shop anytime anywhere without worrying about having the funds in their bank account
Consider the following scenario:
Fintech X wants to provide short term and low-ticket value loans to its customers (₹500 to ₹2,00,000) – Customers can utilize amounts based on their KYC limits.
They also Provide virtual cards (or physical cards) to allow users to utilize disbursed funds at eCommerce merchants. Physical cards, when available, would be used at POS and ATM machines also.
Basically consuming Fusion’s API banking stack and JIT funding - a real-time movement of money. The Line Management can be done by Fintech.
Step by Step Guide
Below is a step by step guide for the fintech’s journey for the lending use case.
First step of the customer journey with fusion starts from onboarding the customer in the fusion’s system. This can be done using the Account holder creation API. Based on the use case and the KYC limits you want to assign to the Customer you can create an account holder in desired KYC state.
Creation of Account Holder
Fintech creates the account holder by providing the basic information of the user.You can refer this section for more on account holder creation.Once an Account holder has been created in fusion’s system. Fintech can go ahead and issue the pre configured bundles available for fintech.
Bundle Creation
Once the Account holder creation is done, users can issue the bundle. By bundle issuance the user gets the payment product and account product. For bundle creation, it is mandatory to provide the account holder id, which we get in the response of Account Holder creation API.You can find more details about the Bundle API’s here
After bundle issuances, details for the card can be fetched from get Resource API and 16 digit card via SDK.
Get Resource details
After the issuance of the bundle, a resource id is created. With that resource id account holder can get the details of the form factor (Phone and Card type). Which can be further used to block/unblock the card, apply limits on card etc.Details of the Get Resource API are available here
At this point of time, an account holder has been created in fusion’s system for the fintech’s consumer. An account and a payment product has been issued to him/her . In order to access the account,a form factor in the form of card and phone number has been issued as well. Now the consumer can go ahead and perform any kind of transaction.
Just-In-Time (JIT) Funding
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. By 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 fintech. Note : Limit Management System has to be built and managed by Fintech.
In order for Just In Time funding to be implemented, Fintech needs to be communicated whenever a fintech’s user is attempting some kind of transaction. This communication can be done in the form of an interceptor.
For this they need to configure the Zeta’s Interceptor at their end by providing the URL at which they want to get the pre-authorization request.
Configuring an interceptor
Endpoint URI
Request parameters
-
ifiID: Required. Unique identifier of the IFI. -
Resource Product id: Required. Unique identifier of the Bundle being issued. -
actionName: Required. Action on which Fintech needs to be communicated. -
Endpoint: Required. URL at which Fintech want to get the pre-authorization request.
Response parameters
-
ifiID: Unique identifier of the IFI. -
Resource Product id: Required. Unique identifier of the Bundle being issued. -
actionName: Required. Action on which Fintech needs to be communicated. -
Endpoint: Required. URL at which Fintech want to get the pre-authorization request. -
status: Status of the interceptor. Value of this field can be ACTIVE/INACTIVE
Example
Switch Theme
Expand More
Copy
curl -X POST \
https://fusion.preprod.zeta.in/api/v1/ifi/140827/resource_products/e15b4f9b-5488-443b-b401-263465cc66ba/interceptors \
-H 'authorization: {{auth-token}} \
-H 'cache-control: no-cache' \
-H 'content-type: application/json' \
-d '{
"actionName": "PAYMENT_REQUESTED",
"connectionConfig": {
"endpoint": "http://127.0.0.1",
"headers": {
"k1": "v1"
}
}
}'
Code Copied
Switch Theme
Expand More
Copy
{
"ifi": 140827,
"id": "d0bc6d3c-4769-4ea2-a145-928e97c39132",
"resourceProductId": "e15b4f9b-5488-443b-b401-263465cc66ba",
"actionName": "PAYMENT_REQUESTED",
"connectionConfig": {
"endpoint": "https://webhook.site/38b85364-3071-45f5-9d49-d390b4d7025b",
"headers": {
"k1": "v1",
"k2": "v2"
}
},
"status": "ACTIVE",
"createdAt": "Apr 16, 2020 3:21:48 PM",
"modifiedAt": "Apr 17, 2020 2:59:41 PM",
"headers": {}
}NOTE: Interceptors can be updated at any given point if Fintech would want to update their end point. For more details please refer to this doc.
Once the interceptor has been successfully configured, whenever a payment is attempted Fintech will be notified. Fintech needs to acknowledge the incoming interceptor request within 2000ms of request, with HTTP 200 as response code. In case it is not acknowledged within 2000ms, payment will be marked as failed.
Once fintech has acknowledged the incoming interceptor request then fintech may choose to allow or disallow the transaction as per their business flow and requirement . In case they choose to allow the payment Fintech needs to make sure the account holder’s account should have the sufficient balance.
Account to Account Transfer
Since this is a just in time funding use case Fintech needs to transfer the funds to the account holder’s account at this moment. For which they need to use A2A transfer.
For this API, fintech needs to pass the debitAccountID and creditAccountID(Accountholder’s account id), so that amount can be transferred to the Accountholder. After this API, we can resume the intercepted payment.
Endpoint URI
Request parameters
-
ifiID: Required. Unique identifier of the IFI. -
Request id: Required.This identifier is used to identify a unique request -
amount: Required. User needs to specify the amount that needs to be transferred. (In Paisa). -
currency: Required. It shows the currency in which the money is transferred. (Length 16 characters). -
transfer code: Required.(Length 240 characters) -
Debit Account ID: Required.individualID of the debited account. -
Credit Account ID: Required.individualID of the credited account.. -
Remarks: Required. (Length 256 characters)
Response parameters
-
Request id: This identifier is used to identify a unique request. -
Transfer id: Unique identifier for the transaction. This will be used in case of reversals. -
status: Status of the transfer. Value of this field can be Success/Failure
Switch Theme
Expand More
Copy
curl --location --request POST 'https://fusion.gw.zetapay.in/api/v1/ifi/140793/transfers' \
--header 'X-Zeta-AuthToken: {{token}}' \
--header 'Cookie: {{Cookie}}' \
--data-raw '{
"requestID" : "test_abcd_1aadflkjhdjh_123658",
"amount": {
"currency" : "INR",
"amount" : "10000"
},
"transferCode": "ATLAS_P2M_AUTH",
"debitAccountID": "dc97c156-1fed-44c0-a7e4-5158f1fac042",
"creditAccountID": "03a60325-e8a4-4c84-b094-30bfb130502b",
"transferTime": 12324254832342,
"remarks": "TEST",
"attributes": {}
}'{
"requestID": "test_abcd_1aadflkjhdjh_123658",
"transferID": "20200806123348502_15770_test_abcd_1aadflkjhdjh_123658",
"status": "SUCCESS"
}
At this stage, the Account holder’s account has been funded with a sufficient amount of money and the fintech can proceed to resuming the intercepted payment.
Account to Account Transfer Reversal
A2A Reversal API should be used by Fintechs for below use cases:
The JIT funding was successfully done by Fintech, however the Payment failed to process due to any technical failures. The JIT funding was successfully done by Fintech on any online merchant like Amazon, Flipkart etc (where users have the flexibility to cancel the order) , however the user later cancels the order OR the money was debited but the transaction failed.
In both the cases, Fintech should reverse the JIT funding done by them. If the money is not debited from the user’s wallet, like in case of point 1, Fintech will receive a “PAYMENT_FAILED” callback event and they should immediately process the reversal. In case of point 2, where the payment has to be reversed by the merchant, for such cases as and when the “PAYMENT_REVERSED” event is received for that particular transaction, Fintech should process the reversal.
Endpoint URI
Request parameters
-
ifiID: Required. Unique identifier of the IFI. -
Request id: Required.This identifier is used to identify a unique request -
amount: Required. User needs to specify the amount that needs to be transferred. (In Paisa). -
currency: Required. It shows the currency in which the money is transferred. (Length 16 characters). -
doPartialReversal: Required.This field helps us decide whether we want to do a full reversal or partial reversal. Value of this field can be True/False -
transfer code: Required.(Length 240 characters) -
Remarks: Required. (Length 256 characters)
Response parameters
-
Request id: This identifier is used to identify a unique request. -
Payment type: This would be “reversal”. -
Transfer id: Unique identifier for the transaction. This will be used in case of reversals. -
Reverse Transfer id: Unique identifier for the reversal transaction. -
amount: Required. User needs to specify the amount that needs to be transferred. (In Paisa). -
currency: Required. It shows the currency in which the money is transferred. (Length 16 characters). -
Remarks: Required. (Length 256 characters) -
status: Status of the reversal. Value of this field can be Success/Failure
Switch Theme
Expand More
Copy
curl --location --request POST 'https://fusion.gw.zetapay.in/api/v1/ifi/140827/transactions/20200806123348502_15770_test_abcd_1aadflkjhdjh_123658/reversal' \
--header 'X-Zeta-AuthToken: {{token}}' \
--header 'Cookie: {{token}}' \
--data-raw '{
"requestID": "497cd983-c91a-4a1d-a112-276986f7e54676",
"currency": "INR",
"amount": 20000,
"doPartialReversal": true,
"transferCode": "A2A_VBOPayout-VBO2E_AUTH-REVERSAL",
"remarks": "test reversal"
}'{
"requestID": "497cd983-c91a-4a1d-a112-276986f7e54676",
"paymentType": "REVERSAL",
"transactionID": "20200806123348502_15770_test_abcd_1aadflkjhdjh_123658",
"amount": 20000,
"currency": "INR",
"status": "Success"
}
Resuming Intercepted Payment
Fintech needs to allow the intercepted payment from the last step to resume and process the payment. The allowed response timeout is configured as 5000ms. This 5000ms essentially starts from the moment you have acknowledged the interceptor request.
The callback response can be interpreted as follow:
-
PASS_THROUGH: The Payment Engine resumes the payment processing as per default Payment Lifecycle. -
FAIL: The Payment Engine rejects the payment request and updates the state as PAYMENT_FAILED.
To resume an intercepted payment, use the following endpoint:
Example
In the following example, you are resuming the payment by providing callback response as PASS_THROUGH or FAIL against a paymentRequestId.
Switch Theme
Expand More
Copy
curl -X POST \
https://fusion.preprod.zeta.in/api/v1/ifi/140827/resources/127ee225-9f35-4027-adf0-f582f4da04f8/payments/287053001811/resume \
-H 'authorization: {{auth-token}} \
-H 'cache-control: no-cache' \
-H 'content-type: application/json' \
-d '{
"paymentRequestId": "T00001_111111_200413225441_163251477338_ff936322-287f-43e4-9497-a86d94bd97a9",
"actionName": "PAYMENT_REQUESTED",
"response": "PASS_THROUGH"
}N/AWebhook Notifications
For every payment state change, Fintechs will receive the callbacks, refer this link for more information. The webhook endpoint must be shared by the Fintechs for them to consume the Payment events.