Configure Interceptors
As a fintech company, you will be performing the following actions to implement the interceptors against the respective payment intercepting points (PIP):
- Configure a Payment Interceptor
- Simulate a payment
- Resume an intercepted payment
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 that is associated with an account holder. In a resource product, a resource is mapped to one or more payment instruments or form factors such as cards and so on. Resources are used to authenticate an Account Holder during payment transactions.
Retrieve a Resource Product
In this step, you’ll determine on which resource product you’ll be configuring the interceptor. To initiate this task, call the /resource_products endpoint. The response returns a unique identifier for every available resource product.
To retrieve a specific resource product, use the following endpoint:
To read more about Resource Product, see Resource Types. For more information on the /resource_products endpoint, see Core API Reference.
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 arePAYMENT_REQUESTED
andPAYMENT_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:
Example
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 e-commerce, ATM, or a POS transaction and verify the callback URL notification. 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 security requirements. You need to acknowledge the incoming interceptor request within 2000ms of request origination. In case the request is not acknowledged within 2000ms, payment will be failed.
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 request 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": "[email protected]",
"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. This 5000ms essentially starts from the moment you acknowledge the interceptor request. Specify the actionNameactionName
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 LifecycleFAILED
: The Payment Engine rejects the payment request and updates the state asPAYMENT_FAILED
To resume an intercepted payment, use the following endpoint:
Example
In the following example, you are resuming the payment by providing callback response as PASS_THROUGH or FAILED against a paymentRequestId.
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