Unknown macro: {hivestonebreadcrumb}
Page tree
Skip to end of metadata
Go to start of metadata

As a fintech, you will be performing the following actions to implement the interceptors against a payment intercepting points (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:

GET

/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:

POST

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


Example

Request

Response

cURL sample
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"
        }
    }
}'
JSON sample
{
  "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 interceptor 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:

Payment sample after configuring an interceptor
{
  "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 FAILED 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.

  • FAILED: The Payment Engine rejects the payment request and updates the state as PAYMENT_FAILED.

To resume an intercepted payment, use the following endpoint:

POST

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 FAILED against a paymentRequestId.

Request

Response

cURL sample
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

About Interceptors

Know about various payment intercepting points.

button

Interceptors APIs

Learn more about Payment Interceptor APIs

button

About Events

Learn about supported Fusion events.

button

On this page:

Need Help?

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

  • No labels