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.

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

Interceptor flow

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

1. The Payment Engine receives a payment request.
2. The Interceptor flow triggers in various payment states if the fintech has configured an interceptor on PIPs. The Switch suspends the payment for a default configured timeout.
   
3. The fintech determines if the intercepted payment should succeed or fail and then responds to the Payment Engine.
4. The Payment Engine then allows or denies the payment request based on the Interceptor response.

Related articles