Event Notification System (ENS) Guide

September 05, 2023 16:38

The Event Notification System (ENS) provides customers the ability to have specific automated interactions without the need of the Agent Web Console. When enabled, notifications from us are sent to you as a series of events formatted in XML. Upon receipt of the information, the receiving system sends a confirmation message to us verifying the data was received.

Examples include the assignment of a transaction to an agent, dynamic re-scores, a change in a customer’s network type, or updated information after the Reevaluate button has been selected. While it is typical for businesses to set up a single website/web server to receive such data, businesses with a high volume of transaction activity can configure multiple websites and servers; one for each event type. While events occur in real time, to avoid overwhelming your web server the data is queued and sent every 30 seconds by default. For more conformation, refer to ENS Facts.

The ENS Guide contains the following documentation:

Introduction to the ENS

As the system is being used to process requests, transaction risks are being calculated and recalculated. Each event is registered and sent to a URL that is specified by the customer. This provides the ability to monitor our events related to the your business.

There are four general classifications of events:

AWC Events (which are still labeled DMC Events): Events that are typically set in the AWC, such as changes to email, credit card, or postal address lists.
Workflow Events: Events that are associated with changes in the workflow queue, such as assigning a transaction to an agent.
Risk Change Events: Events that are associated with some change in transaction risk, such as a change detected in the buyer’s network type.
Special Alert Events: There is only a single event in this class; the change in score of a transaction previously approved to a score below the approve threshold.

The above events are either generated by an Agent or API action (refer to the note below) or by a System action. Agent actions are specific activities conducted by your company’s Risk Department staff as tasks are performed in the AWC. System actions are activities automatically performed by Kount related to the analysis and processing of transaction information submitted to the system.

You must provide us with the URL of that site and once received, ENS events are queued and sent to the specified website. Please see instructions for enabling the ENS feature and setting the the URL location in the How to Enable ENS within the Agent Web Console section of this document.

The typical setup is for you to configure a single website/server to receive all event information from us. However, you have the option to create separate sites for each individual event. While the use of this option is relatively rare, it is an advantage if you operate a business with an extremely high volume of transactions.

Note: While APIs are not required for Event Notification, an API can trigger an event. For this to occur, you must create a fictitious Agent user account for the API since the API must login to your system to initiate events. When you set up Event Notification, you must notify us of the username and email address of the API user. While the API is an entity rather than a person, it is still considered an Agent by the system for this purpose.

Retry Policy

If Kount posts a collection of events to the merchant’s endpoint and the post fails a timeout or any result other than an HTTP 200 response, we attempt to retry posting to the merchant’s endpoint using an exponential backoff.

These retries continue for 72 hours. At the end of the 72 hours, if the customer's endpoint has not been restored and the posts continue to fail, the events will expire and no further attempts will be made.

Event Delivery Chronology

Chronology is dependent upon whether a customer's endpoint is functional and active.

If the customer's endpoint remains functional, chronological delivery of events is guaranteed.
If the customer's endpoint is not functional, chronological delivery of events is not guaranteed.
If a customer's endpoint go down and then come back up, events posted after the endpoint comes back up are delivered in chronological order. However, those events that were attempted while the endpoint was down may not be delivered in chronological order and may be delivered out of sequence.

Was this article helpful?

1 out of 2 found this helpful