|
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. Each interceptor point provides a request payload contract to the interceptor and the acceptable responses. The contract specifies the behavior of the flow based on the response sent by the interceptor.
In Fusion, 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. For example, you can intercept a cash withdrawal request from a card defaulter and block the transaction. Another classic use case is Just-in-Time (JIT) funding, where you can assess a payment request from a user and decide to fund the account in real-time so that the transaction succeeds.
Fusion Interceptors enable a fintech's applications to take part in decisions during business process flows that are not initiated by them. Fusion waits for the interceptor to respond, and based on the response, it triggers the next event. Fusion APIs allow a fintech to register Interceptors for various payment intercepting points (PIP).
In this release, Fusion allows you to configure Interceptors on Resource Products.
|
A typical interceptor flow would look something like this in a payment scenario:
As a fintech, you will be performing the following actions to implement the Interceptors against a PIP:
For the complete list of Payment Interceptor APIs, see Payment Core API Reference. |
In Fusion, Interceptors are created for a Resource Product which is associated with an account holder. A Resource Product may have a Resource, which is then mapped to one or more payment instruments or form factors, for example, card and so on. Resources are used to authenticate an Account Holder during payment transactions.
Before creating an Interceptor, let's find out on which Resource Product you want to configure an Interceptor. To do this, call the /resource_products
endpoint. The response returns a unique identifier, id
, for each available Resource Product.
To retrieve a specific Resource Product, use the following endpoint:
/api/v1/ifi/{ifiID}/resource_products |
|
To add an Interceptor for a Resource Product, call /resource_products/{resourceProductID}/interceptors
endpoint and pass the identifier, id
, of the Resource Product obtained from Retrieve a Resource Product step in the path parameter. Specify the allowed actionName
and a callback endpoint
in the body parameter.
In this release, the allowed PIPs ( |
To add an Interceptor for a specific Resource Product, use the following endpoint:
api/v1/ifi/{ifiID}/resource_products/{resourceProductID}/interceptors |
Example
|
Note a unique identifier, id
, actionName
and endpoint
returned in the response parameter associated with the newly created Interceptor.
After you register an Interceptor, simulate an Ecom, ATM or POS transaction and check the callback URL notification you would have received at you end. The callback URL is the endpoint
you have configured in the previous step against a PIP (actionName
). If you detect an I nterceptor when a payment is attempted, you may choose to suspend or proceed to the next step as per your business flow and requirement.
Contact Zeta Support to simulate and test a Payment Interceptor. |
A sample new payment request would look something like this after you've configured an Interceptor in a PIP. Note the actionName
in the request payload below:
{ "actionName": "PAYMENT_REQUESTED", "payment": { "id": 969762000003, "ifi": 140827, "requestChannelType": "SUPER_CARD", "state": "PAYMENT_REQUESTED", "value": { "currency": "INR", "amount": 1 }, "stateTransitions": { "PAYMENT_REQUESTED": 1586816781938 }, "payer": { "type": "RESOURCE", "targetURI": "account://6b2dfb83-9276-422c-8781-07eda71fc261", "resourceID": "0c97e84f-999d-4fdf-a53f-24cb99b11e76", "formFactorURI": "card://ff936322-287f-43e4-9497-a86d94bd97a9" }, "payee": { "name": "TEST MERCHANT", "type": "EXTERNAL_BUSINESS", "location": "MUMBAI" }, "paymentRequest": { "paymentRequestID": "T00001_111111_200413222621_684967968469_ff936322-287f-43e4-9497-a86d94bd97a9", "requestFrom": "1971050374361855296@ledger.zeta.in", "requestTo": "card://ff936322-287f-43e4-9497-a86d94bd97a9", "value": [ { "currency": "INR", "amount": 1 } ], "dueBy": 1586817981373, "towards": "Physical Super Card ECOM Purchase", "attributes": { "zeta.amc": "5811", "super-card.ifi": "140827", "super-card.ink": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36", "super-card.mcc": "5411", "super-card.mid": "M00001", "super-card.rrn": "684967968469", "super-card.tid": "T00001", "super-card.stan": "462394", "super-card.card-id": "ff936322-287f-43e4-9497-a86d94bd97a9", "journal.voucherCode": "RUPAY-508645_ECOM_AUTH", "super-card.acquirer": "111111", "super-card.card-6x4": "508645-xxxxxx-0289", "super-card.card-bin": "508645", "super-card.trans-id": "M00001_T00001_111111_462394_684967968469_200413222621", "super-card.txn-type": "ECOM", "super-card.acs-txnId": "423914997684266755797644619797", "super-card.init-time": "200413222621", "super-card.merchant-lat": "18.975", "super-card.merchant-lon": "72.825833", "super-card.merchant-city": "MUMBAI", "super-card.merchant-name": "TEST MERCHANT", "super-card.otp-enter-mode": "manual", "super-card.merchant-country": "IN" } |
You can now allow the intercepted payment from the last step to resume and instruct Fusion to process the payment. The allowed response timeout is configured as 5000ms. Specify the actionName
as configured (also seen in above payment sample) and pass the callback response
as PASS_THROUGH or FAIL against a paymentRequestId
in the body parameter.
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:
api/v1/ifi/{ifiID}/resources/{resourceID}/payments/{paymentID}/resume |
Example
In the following example, you are resuming the payment by providing callback response as PASS_THROUGH
or FAIL
against a paymentRequestId.
|
|
|