Interceptors

Interceptors are HTTPS endpoints that return a response payload. The host of the interceptor (ex: fintech product) then consumes the response and incorporates it in the request flow. Each interceptor point provides a request payload contract that specifies the behavior of the flow based on the response sent by the interceptor.

Fusion Interceptors

Using Fusion interceptors, a fintech product can intercept a payment request going out to a merchant on a particular card network. Based on its risk system architecture, compliance, and policies the interceptors can enable Fusion to either approve or reject that request.

For instance, consider the following use cases :

• Assume a card defaulter is trying to withdraw some cash. As a fintech product, you can intercept a cash withdrawal request immediately and block that transaction right away.
• Another classic use case is the 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 the Fusion Interceptor Blog.

Fusion Interceptors enable a fintech product to proactively take business decisions that aren’t part of the actual workflow. Fusion waits for the interceptor to respond, and based on the response payload, it triggers the next event. Fusion APIs allow a fintech product 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

Consider a credit payment scenario. A typical interceptor flow would look something like this:

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 a stipulated amount of time and send acknowledgment 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