Learn how to configure a Payment Interceptor

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.

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) whose functionality you can extend are PAYMENT_REQUESTED and PAYMENT_AUTHORIZATION_RECEIVED. To know more about these states, please see Payment Lifecycle.

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.

What You'll Learn

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.

Configure a Payment Interceptor

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.

Retrieve a Resource Product

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

Add an Interceptor

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 (actionName) whose functionality you can extend are PAYMENT_REQUESTED and PAYMENT_AUTHORIZATION_RECEIVED. To know more about these states, please see Payment Lifecycle.

To add an Interceptor for a specific Resource Product, use the following endpoint:

api/v1/ifi/{ifiID}/resource_products/{resourceProductID}/interceptors


Example

Request

Response

curl -X POST \
  https://fusion.preprod.zeta.in/api/v1/ifi/140827/resource_products/e15b4f9b-5488-443b-b401-263465cc66ba/interceptors \
  -H 'authorization: {{auth-token}} \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -d '{
    "actionName": "PAYMENT_REQUESTED",
    "connectionConfig": {
        "endpoint": "http://127.0.0.1",
        "headers": {
            "k1": "v1"
        }
    }
}'
{
  "ifi": 140827,
  "id": "d0bc6d3c-4769-4ea2-a145-928e97c39132",
  "resourceProductId": "e15b4f9b-5488-443b-b401-263465cc66ba",
  "actionName": "PAYMENT_REQUESTED",
  "connectionConfig": {
    "endpoint": "https://webhook.site/38b85364-3071-45f5-9d49-d390b4d7025b",
    "headers": {
      "k1": "v1",
      "k2": "v2"
    }
  },
  "status": "ACTIVE",
  "createdAt": "Apr 16, 2020 3:21:48 PM",
  "modifiedAt": "Apr 17, 2020 2:59:41 PM",
  "headers": {}
}

Note a unique identifier, id, actionName and endpoint returned in the response parameter associated with the newly created Interceptor.

Simulate a Payment

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"
      }

Resume an intercepted payment

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.

Request

Response

curl -X POST \
  https://fusion.preprod.zeta.in/api/v1/ifi/140827/resources/127ee225-9f35-4027-adf0-f582f4da04f8/payments/287053001811/resume \
  -H 'authorization: {{auth-token}} \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -d '{
  "paymentRequestId": "T00001_111111_200413225441_163251477338_ff936322-287f-43e4-9497-a86d94bd97a9",
  "actionName": "PAYMENT_REQUESTED",
  "response": "PASS_THROUGH"
}'

N/A

Related Articles

Payment Lifecycle

Know about various payment events and its lifecycle.

Interceptors APIs

Learn more about Payment Interceptor APIs

Create Card Orders

Learn how to create card orders

On this page:

Need Help?

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