Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Div
classdeveloper-cookbook-inner-page-title
HTML Table
classtagline-page-title
Table Row (tr) Table Cell (td)
classtitle-text
Learn about Fusion

Interceptors

and various intercepting points

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

Note

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) whose functionality you can extend 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. 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

HTML Table
classdeveloper-cookbook-next-steps
Table Row (tr)
Table Cell (td)
classnext-steps-table-content

Configure Interceptors

Know about interceptors configuration.

Button Hyperlink
titlebutton
typestandard
classhyperlink-overlay
urlConfigure Interceptors

Table Cell (td)
classnext-steps-table-content

Interceptors APIs

Learn more about interceptor APIs.

Button Hyperlink
titlebutton
typestandard
classhyperlink-overlay
urlPaymentInterceptor APIs

Table Cell (td)
classnext-steps-table-content

About Events

Learn about supported Fusion events.

Button Hyperlink
titlebutton
typestandard
classhyperlink-overlay
urlAbout Webhooks and Fusion Events

Panel
Div
classalignLeftIcon

On this page:

Table of Contents
maxLevel1
Table of Contents
minLevel4
classhide-schema

Div
classhelp-box

Need Help?

Drop a mail at fusion-support@zeta.tech or call us on 080-6690 5995.