Alerting
Before setting up alerts in Connect, you must request Webhooks via your Sales representative. The Sales representative needs to contact Presales and ask them to submit a request to the development team.
The Webhook request must contain the following information:
Tenant ID
Tenant identifier
For example, tenant-abc123
Tenant name
The official tenant name
For example, Acme_Corporation.Ltd
Environment
The Connect node where the Webhooks are needed.
For example, https://connect.cloud.paycomplete.com
Message type - What type
What type of message do you need Webhooks for?
For example, 'transaction' or 'transaction-with-box-content'
Use case description
A short explanation of what the queue will be used for
Webhooks are manually created by PayComplete™ based on the request you have submitted. The team creates SQS queues for message creation in AWS SNS SQS. Your SNS protocol can then process these messages.
Once you have Webhooks in place, you use the Alerts form in Connect to configure alerts for these messages:
Machine transactions
Machine contents (transaction + box contents)
Machine online status change
User balance change
Based on the message types, you can create alerts and define:
Sites
Machines
Machine UUID
The status that triggers the alert
The triggering event
Some triggering events, such as High-frequency anomaly and Volume anomaly, have mandatory time filters
The recipients of the alerting emails.
You can configure alerts to be sent one of several different ways. Supported delivery methods are: email, an AWS SNS webhook, a webhook URL, and, when enabled for a tenant, an integration.
The filters shown in each step depend on the selected triggering event and the features enabled for the tenant. One triggering event can have a step or filters that other triggering events don't have.
Scope — Defines which entities the alert applies to. Depending on the alert type, this can include: sites, machines, machine UUIDs, device IDs, or transaction device IDs.
Status — Limits the alert to a particular operational or message status, for example, when a machine is connected, disconnected, catching up, or when a message changes from or to a selected status.
Events — Defines event-based conditions that trigger the alert, such as errors being raised or cleared, door opening or closing, an error code/severity, or duress alarm activation/deactivation.
Transactions — Filters alerts related to transactions. The available options may include transaction type and subtype, transaction box ID, adding box content, and webhook-related transaction data.
Thresholds — Defines numeric conditions that must be met before an alert is sent. These can include transaction amounts, cash or box-content counts, ratios, product counts, and user-balance limits. Where applicable, you can also select a currency or percentage.
Time — Restricts the alert to a time-of-day window. You can configure a start and/or end time; if both are available. The start time must be earlier than the end time.
Recipients — Defines where the alert notification is delivered. You can add multiple recipients.
Warning
It's important to think through the alert cases before setting up alerts.
Be cautious when setting up alerts for errors. If not done correctly, you can receive an alert message every time the error message is sent. If the message is sent every second, you will get 3600 alerts per hour. Not just once per error.
See also