About Interceptors

Interceptors are HTTPS endpoints with the extra functionality of returning a response. The host of the interceptor (eg: Fintech) 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.

Fusion Interceptors

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.

Consider the below use cases :

1. Let us assume a card defaulter is trying to withdraw some cash,you can intercept a cash withdrawal request immediately and block the transaction immediately.

2. 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.

To know more about interceptor use cases, see Fusion Interceptor Blog.

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.

• The supported entity type is RESOURCE_PRODUCT_ID.

• The allowed PIPs (payment states) on which you can configure interceptors are PAYMENT_REQUESTED and PAYMENT_AUTHORIZATION_RECEIVED. To know more about these states, please see Payment Lifecycle.

Interceptor flow

A typical interceptor flow would look something like this in a payment scenario:

1. Account holder A tries to purchase something on Amazon (Any merchant)

2. The Payment Engine receives a payment request.

3. The Interceptor flow triggers in various payment states if the fintech has configured an interceptor on PIPs.

4. VBO’s receives information about a transaction being attempted by account holder A

5. The Switch suspends the payment for a default configured timeout.

6. VBO should acknowledge the incoming interceptor request within stipulated amount of time and sends acknowledgement back to Zeta.

7. The VBO determines if the intercepted payment should succeed or fail and then responds to the Payment Engine.

8. The Payment Engine then allows or denies the payment request based on the Interceptor response.

Related articles