zendit developers Logo
Search zendit documentation

zendit ShieldWall

Optional transaction verification webhook for Zendit clients..

Bad Actors are Everywhere

Whether inside your network or intruders that compromise your network, bad actors are always looking for new avenues for fraud. Zendit’s ShieldWall gives an extra layer of protection from fraud beyond IP Whitelists and access tokens.

How ShieldWall works

ShieldWall is an optional webhook that is sent by Zendit to your webhook server to verify if a transaction is legitimate. If the transaction is recognized, a verification is returned to Zendit from your webhook and the transaction will proceed as expected. If the transaction is not recognized, a negative acknowledgement is returned by your webhook to Zendit and we immediately fail the transaction and mark it as blocked by ShieldWall.

The transaction flow works as follows:

Performance Considerations for ShieldWall

When implementing ShieldWall, all purchase transactions will require passing the verification step with the provided webhook. ShieldWall is expected to be lightweight enough to receive a response within 20 seconds. In the event that ShieldWall does not receive the verification within 20 seconds, the call to the webhook will time out and the transaction will be blocked as unverified. If the webhook is unreachable, all transactions that fail to be verified will automatically be blocked and a alert will be sent that transactions are blocked due to the ShieldWall webhook being unreachable. For longer outages or intermittent inability to reach ShieldWall, an hour alert will be sent if any transactions cannot get a response from the webhook.

Implementation Details

To implement ShieldWall, a webhook that receives both HEAD and POST traffic needs to be created. The HEAD request is used by Zendit when setting up the webhook to verify connectivity can be established. 

When a transaction is sent to Zendit, Zendit will POST the transaction information using the same format as the /transaction endpoint on the API (basic details) as follows:

{
  "amount": 0,
  "createdAt": "string",
  "currency": "string",
  "error": {
    "code": "string",
    "description": "string",
    "message": "string"
  },
  "log": [
    {
      "dateTime": "string",
      "status": "string",
      "statusMessage": "string"
    }
  ],
  "productType": "string",
  "status": "string",
  "transactionId": "string",
  "type": "string",
  "updatedAt": "string"
}

If the transaction is recognized, the Webhook should return a status 200 response. If the transaction is not recognized, the Webhook should return a 404 response. Any status other than 200 or 404 will be treated as a webhook failure and an alert will be sent notifying that the transaction was blocked because we could not verify it against the webhook server.

ShieldWall Alerts & Blocked Transactions

ShieldWall will only send alerts when the webhook is failing in the production environment. If the webhook is altered in the production environment, a security alert will be sent with a notification that the webhook has been changed. 

Transactions returned as unrecognized and blocked by ShieldWall are viewable in the transaction detail report and will be noted that they were blocked by ShieldWall. Alerts are not sent for transactions that were blocked by the 404 response from the ShieldWall webhook but an excessive number of transactions blocked should be investigated on the integration for a network intrusion or internal attempts to fulfill products using the production API key. IP Whitelisting should also be investigated for tightening security.
For help with a compromised API Key, contact Zendit support at support@zendit.io.