PayStar Events is a unified audit log for payments, limits and Issues with alerts to Telegram/Slack and webhooks, speeding up incident investigation.

Events is a unified log of everything that happens with payments, limits, Issues and configuration in PayStar.
The same events can be:

viewed in the admin UI (Events section),

delivered to Telegram and Slack,

sent to your own HTTP endpoint as webhooks (details: https://apidoc.paystar.uk/events).

Currently, the Events section is available in the PayStar admin and used by internal teams for monitoring and investigations; webhooks and notifications are already available to merchants via documentation.

Why Events matters

Events helps you quickly answer three key questions:

What is happening in the system?
Are limits being triggered? Do we see unknown statuses from PSPs? Are there many new Issues?

Who did what and when?
Which manager created or updated an Issue, changed a channel, or modified routing?

Why did a specific incident occur?
You can reconstruct the chain: from payment statuses and limit triggers to the Issue that was opened.

Events is especially useful for:

support and account managers — when working with merchant complaints;

risk teams — when monitoring limits and blacklists;

integration teams — when debugging and monitoring PSPs.

Events UI overview

The Events section has two tabs: Charts and History. At the top, you have a date filter and a user filter.

Date and user filters

Date — the date picker in the top-left sets the time range. All charts and the event list only show what happened in this period.

User — a search field for the actor.
Type a user name/login and History will show only events initiated by this user (rows with their avatar). Automatic events (limits, statuses, PSP Integration) are not filtered by this field.

The Daily / Weekly / Monthly switches define the time scale: by days, weeks or months.

Charts: aggregated overview

The Charts tab gives you a quick overview. It shows donut charts by event category:

Payments — payment status events (ORDER STATUS UPDATED, ORDERS UNKNOWN, etc.),

Limits — limit triggers,

Routing (pipeline rule) — routing rule changes,

Pipeline, Channels, Merchants, Cashiers, Commission, Settlements, Issues — activity around configuration and incidents.

On top, there is a line chart showing the dynamics of events over time.

For the selected period (Daily / Weekly / Monthly) you can see:

whether there are spikes in errors/limits,

when exactly the most events occur,

which categories are currently generating the most noise.

History: detailed event feed

The History tab is a chronological list of all events for the selected period.

Each row contains:

on the left — a source icon: a user avatar or e.g. PSP Integration,

in the center — a short title (LIMIT EXCEEDED, ORDER STATUS UPDATED, ISSUE ADDED, ORDERS UNKNOWN, etc.),

on the right — the exact timestamp.

Automatic vs user events

Rows with an avatar and user name are actions performed by real admin users (Issue created/updated, configuration changes, etc.).

Rows without a name or marked as PSP Integration are automatic system or PSP events: limit triggers, PSP status updates, low-level system events.

Expanding event details

Clicking a row opens a detail card with:

the event type (LIMIT EXCEEDED, ORDER STATUS UPDATED, NEW ISSUES - …, etc.),

key parameters (merchant, limit type and limit value; operation type and status transition for a payment),

the exact timestamp in UTC,

technical identifiers (order UUID, limit ID, Issue ID),

text tags (#Limit, #OrderStatus, #Issue, #PSP Integration, etc.).

At this stage, navigation to entities is done by copying IDs and using them in other sections (Order, Issue, Limits, etc.).

What gets logged

At the time of writing, Events includes, among others:

Payments

ORDER STATUS UPDATED — deposit or payout status changes;

ORDERS UNKNOWN — responses from PSPs that could not be mapped to expected statuses.

Limits and blacklists

LIMIT EXCEEDED — limit triggers (e.g. per-user requisites count, turnover limits for merchants).

Issues

ISSUE ADDED, ISSUE UPDATED;

aggregated blocks like NEW ISSUES - 64.

Integrations

events from PSP Integration — everything that comes from the integration layer.

Configuration

actions related to Pipeline and Routing (pipeline rule),

changes in Channels, Merchants, Cashiers, Commission, Settlements — reflected through counters on Charts and individual events in History when changes occur.

Typical usage scenarios

1. Investigating a merchant complaint about a deposit

In the date filter, choose the relevant time range.

Search by Order ID or by tags in event descriptions (#OrderStatus, #Issue, etc.).

In History, you see the full chain:

status changes (ORDER STATUS UPDATED),

potential LIMIT EXCEEDED,

any related Issues.

Using IDs, you open the order or Issue in their respective sections and reconstruct the full story.

2. Detecting PSP problems

In Charts, you notice a spike of ORDERS UNKNOWN or an unusual increase in Payment errors.

You switch to History and check which PSP integrations are most frequently mentioned in these events.

Based on this, you adjust routing, open an Issue or contact the PSP.

3. Monitoring team activity

In the User field, select a specific manager.

In History, you see their actions: which Issues they created, what settings were changed.

The time-based view helps you understand reaction speed and workload.

Subscribing to Events: Telegram, Slack and webhooks

The UI isn’t the only way to work with Events.
The same event stream can be delivered to external systems.

Telegram and Slack

Events can send selected event types to:

a working chat in Telegram (via a bot),

a channel in Slack.
Frame 27.png

You can receive, for example:

limit triggers (LIMIT EXCEEDED),

unknown statuses from PSPs (ORDERS UNKNOWN),

new Issues and other important events — directly in your team messengers.

Messages are formatted for quick scanning: a short title, key fields and identifiers.

Webhooks to your endpoint

If you need to plug in your own monitoring or automation, you can set up webhooks:

configure an HTTP endpoint on your side,

select which event types should be delivered,

receive JSON payloads with all necessary information.

Payload formats, examples and implementation details are described in the merchant documentation:
https://apidoc.paystar.uk/events

Summary

Events is:

a unified event log for payments, limits, Issues, configuration and integrations;

a UI with two modes — Charts for overview and History for details;

a single event stream that can be mirrored to Telegram, Slack and your own systems via webhooks.

With it, incident investigations and monitoring of your payment infrastructure take minutes instead of hours.

Unified audit log

Why Events matters#

Events UI overview#

Date and user filters#

Charts: aggregated overview#

History: detailed event feed#

Automatic vs user events#

Expanding event details#

What gets logged#

Typical usage scenarios#

1. Investigating a merchant complaint about a deposit#

2. Detecting PSP problems#

3. Monitoring team activity#

Subscribing to Events: Telegram, Slack and webhooks#

Telegram and Slack#

Webhooks to your endpoint#

Summary#