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 Kount 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 Kount 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’s 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 in Kount and will be sent to a URL that is specified by the customer. This provides the ability to monitor Kount events related to the customer's 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* 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.
Kount must be provided with the URL of that site and once received, ENS events will be queued and sent to the specified website. Please see instructions for enabling the ENS feature and setting the the URL location in the Enabling 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 Kount. 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.
*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 Kount 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.
If Kount posts a collection of events to the merchant’s endpoint and the post fails, that is, a timeout or any result other than an HTTP 200 response, Kount will attempt to retry posting to the merchant’s endpoint using an exponential backoff.
These retries will 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 should go down and then come back up, events posted after the endpoint comes back up will be 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.