Event Setup and Configuration

This guide describes event setup and configuration at Galileo and within your own system. It also includes considerations for receiving and prioritizing events, as well as information on event delivery statuses reported by the CST Alerts Log.

Receiving events

In cooperation with Galileo, you select which events you want to receive, and then for each event, select which fields you want to include in the event message body. In the API reference, the Events API indexes (listed below) show which fields are included by default, and you can request to remove or add fields as desired.

In most cases, you receive events only for active accounts. The individual event descriptions specify which events are sent regardless of account status. You can set the MSGDA parameter to send other events regardless of account status.

Events prioritization

If an event is triggered with high frequency, it may delay the delivery of other event messages. To prioritize other events over the high-frequency event, Galileo can create a secondary queue for the high-frequency event.

For example, you can ask Galileo to create a secondary queue for the SETL: setl event, which is triggered every time an authorization is settled. Then, the events in the primary queue are delivered before the SETL events when there is a high volume of SETL events. It is also common for Galileo to create a secondary queue for BADJ: adj events.

Events with debit or credit amounts

Some transaction events that have an amount field do not explicitly use a negative sign to report a debit amount. For example, BPAY: billpay reports a successful bill pay debited from the customer’s account and always has a positive amount in the amount field. For your internal setup, make sure to note whether an event reports a debit or credit amount.

Events configuration at Galileo

During product configuration, you determine when and how you will receive Events API webhook messages from Galileo. The following are components of Events API configuration in Galileo’s system.

Format for receiving events and sending responses — Galileo can send you events in JSON format or as form data, and Galileo can receive your response in JSON or XML format. See About Events API in the API reference for examples.
URLs for receiving events — You provide URLs hosted by a server on your system where Galileo will send Events API webhook messages. You must provide separate URLs for the CV and Production environments.
Product parameters for events — Behavior for some events can be configured with product parameters. Work with your Galileo representative to decide which events you want to receive for each product and when they should be sent.
Events to enable in CV and Production — Galileo can enable different events in the CV and Production environments so that you can test an event in CV while disabling it in Production.
Frequency and maximum count for message retries — The RETRY parameter controls the maximum number of retries for an event message and the RTRDL parameter controls the delay between attempts. See “Retry” under About Events API in the API Reference for more information.

Your operational setup

The following are considerations for handling Events API webhook messages in your own system.

Forwarding events to customers — Determine whether you will send events to customers and how you will display them.
Account balance reporting — The value in the open_to_buy field may cause confusion if you display it to customers. Instead, use the Program API to display transaction history. See the Transaction History guide for more information about using data sources to display transaction history to customers.
Reporting and reconciliation — The datastore that you build with the Events API should not be used to perform reconciliation, run large reports, perform data analysis or build statements. Instead, you should create a separate datastore using the RDFs. See Building a datastore in the About the Raw Data Files (RDFs) guide for more information.

Transaction event timestamps and account balance

Although you can use event messages to track an account's transaction activity, you cannot use events to determine an account's balance at any given time. Keep in mind the following:

The timestamp in the event body corresponds to the time when the event occurred on the Galileo system, but the open_to_buy was captured later, during the message assembly.
You can add opentobuy_ts to your transaction-related events to see exactly when the open_to_buy was captured.
Event messages will likely not arrive on your system in the same order they were generated. Some events are delayed, and occasionally they do not arrive at all.
You should therefore interpret open_to_buy as being accurate as of opentobuy_ts, not as the result of the reported event.

See Transaction History for the recommended method to retrieve and present the latest customer data in your interface.

CST Alerts Log

In the Customer Service Tool, the Alerts Log displays a record of Events API messages that Galileo has sent as a result of activity on an account. The Alerts Log is located in the CST Account tab.

The Alerts Log displays the delivery status for each event. This table lists each event delivery status and describes the next step to take.

Status	Next step
Processed	None
Card holder has not opted to receive this alert	None
Error	Work with Galileo to determine why the event was not sent.
Queued to be sent	None. If there is a high volume of event messages, this message will be sent later. See Events prioritization for information on creating a secondary queue.
Product not configured for this msg_id	If you did not expect this event, there is no next step.
Alert Processing Not Completed	Work with Galileo to determine why the event was not sent.

To correlate a transaction with a CST alert, use the alert timestamp.

Galileo setup

Parameter	Level	Description
CDMSG	Product	Specifies which card status updates will trigger the `CSNT: card_status_change` event. For valid values see the Card Statuses enumeration.
MSGDA	Product	Specifies which events are triggered regardless of account status. Default: `BACT: card_activated` `BFID: failed_id` `CAPP: app_completed` `NACT: denied_auth_inactive_card` `PSUC: card_returned`
RETRY	Product	Maximum retries to send a message.
RTRDL	Product	Delay in seconds before resending a message. The delay increases exponentially for each retry by multiplying the square of the retry count by RTRDL. See Retry for an example and further details.