Monitor every incoming payment in real time with PayStar Deposits: statuses, payment paths, similar payments, commissions and PSP reconciliation in one place.

1. Business level

1.1. Why you need the “Deposits” section

The “Deposits” section is a single window for all incoming payments of the merchant:

you see every payment: who paid, through which provider, in which flow and with what result;

you can quickly understand where the money got stuck — on the user side, the gateway, PayStar or the merchant;

you see commissions and financial postings, which makes this section the foundation for margin control and reconciliations.

In other words, this section answers the key question for the business owner:

How much money actually arrived, through whom, and with what losses along the way?

1.2. Key roles and their use cases

Owner / C-level

sees how money actually flows into the business;

understands which providers and channels boost revenue and which drag it down.

Operations team

investigates player complaints;

records where the failure occurred and what actions have already been taken.

Risk / Anti-fraud

detects suspicious behaviour patterns;

sees clusters of deposits by device fingerprint / IP / payment details.

Finance

reconciles successful deposits with PSP and merchant reports;

controls commissions, RR and margin per flow.

Support and Engineering

diagnose technical errors;

verify how exactly the payment went through gateways and callbacks.

1.3. How “Deposits” fits into the overall reporting picture

“Deposits” is drill-down to a single order level. Above it you have three layers:

Payment report / Orders report
Analytics in charts: distributions by statuses, merchants, flows, channels, gateways, currencies and payment funnels.

Summary report
Tabular results per period: number of orders, conversion, turnover, opening/closing balances, RR and commissions.

Reconciliation
Uploading Excel from a merchant or a gateway, automatically matching it with PayStar data and highlighting discrepancies.

For analytics and financial control people usually go top-down:
Payment report → Summary report → Deposits (specific cases).

For operations and support it’s the other way around:
complaint / problematic payment → Deposits → reports and trends if needed.

2.1. Main screen: deposits list

📸 Screenshot 1 — deposits list

At the top you have filters by key dimensions:

period (Created),

Status (init / created / processing / success / failed),

Merchant, Flow, Channel, Gateway, Integration,

Currency,

precise search by:

Deposit ID / Payout ID,

Merchant order ID,

Gateway order ID,

payment details and user parameters.

In the table for each record you see:

creation time, amount and currency,

order status,

identifiers in PayStar, merchant and gateway systems,

payment details (bank, masked card/wallet, etc.),

flow, channel and gateway,

in extended view — commissions and RR.

At the bottom you have the “Total amount” row and FULL / MERCH links:

aggregated sums for all filtered orders, broken down by currencies;

triggers to export either a full or a “merchant-safe” report.

2.2. Deposit details

📸 Screenshot 2 — deposit details card

In the deposit details card you see:

status, amount, currency, creation time;

IP, browser, language, payerIdentifier, email, country;

payment page URLs;

order identifiers in PayStar, the merchant and the gateway.

Available actions:

copy key fields (IDs, payment details) for communication with PSP/merchant;

add to blacklist a user or payment details (auto-decline of future attempts);

add a comment and assign an owner for the case;

create a task for engineering (for example, “check logs for this order”).

2.3. Payment path

📸 Screenshot 3 — Payment path

The “Payment path” block is the full timeline of the order:

user-side events (visits, clicks, repeated attempts),

requests to the payment gateway and PSP responses (codes and messages, raw JSON),

internal PayStar steps (status changes, cascade, errors),

outgoing callbacks to the merchant.

Here you can also:

resend a callback;

see the orderHistory from the gateway/merchant;

use the time axis to see exactly where the payment “got stuck” or failed.

2.4. Similar deposits (fingerprint)

📸 Screenshot 4 — Similar deposits block

For each deposit PayStar builds a fingerprint using dozens of signals:

IP and geo,

device and browser,

language and timings,

card/wallet details,

behavioural metrics.

The Similar deposits block shows payments where the similarity score exceeded a threshold.
This allows you to:

see all attempts from the same user/device,

track repeated failed deposits around a disputed payment,

detect multi-accounting and bonus abuse schemes.

2.5. Financial postings and commissions

📸 Screenshot 5 — financial postings and commissions

For successful orders you see:

postings for merchant, gateway and referrals;

commissions and RR (merchant RR, gateway RR, total RR);

opening and closing balances.

This connects the technical status with the financial result: you see who earned how much on this particular payment.

2.6. Manual status change and security

📸 Screenshot 6 — manual status change

Users with elevated permissions can perform a manual status change on an order:

from the grid (in the Status cell) or from the order details;

the operation is treated as exceptional and requires deliberate action;

after changing the status, a Telegram notification is automatically sent to a service chat.

It is strongly recommended to review logs and the payment path beforehand, to avoid breaking financial reporting.

2.7. Export and reports

📸 Screenshot 7 — footer and export

From the “Deposits” section you have two export types:

FULL — full internal report with all fields (including PSP details, commissions and technical parameters);

MERCH — “trimmed” report for the merchant, without exposing PSP infrastructure (especially useful for payment aggregators).

Exports are generated asynchronously and are then available in the “File export” section.

3. Operational level: case studies

3.1. Case 1. Player complaint: money is debited, balance not updated

Scenario. A player sends a bank receipt/screenshot: money was debited, but the deposit is not visible in the merchant’s back office.

Steps in PayStar:

In “Deposits” find the payment:

by amount and time;

or by Merchant order ID, if available;

or via the Similar deposits block, if you only have IP/email.

Open the deposit card and the Payment path:

verify that the gateway status is Success;

check whether the callback was sent and accepted by the merchant.

If the callback was not processed:

click “Resend callback”;

log the action in a comment (who resent it and when).

If the issue repeats:

create a task for engineering (check merchant endpoint, logging);

escalate to the merchant if needed.

Result. The operator clearly sees where the payment got stuck and can document all actions taken on the complaint.

3.2. Case 2. Conversion drop on a specific gateway

Scenario. Conversion for deposits through gateway X is dropping, the decline rate is rising.

Steps:

In the Payment report, look at distributions by status and gateway — you see a spike of Failed for gateway X.

Go to “Deposits”:

filter by merchant (or all), period and gateway X;

open several orders and analyse error codes in the Payment path.

If the issue is massive and technical:

temporarily disable gateway X in routing or push traffic via cascade to another gateway;

send the PSP a list of Gateway order ID examples with a description of the issue.

After the fix:

enable the gateway again;

monitor conversion recovery in Payment report and in the “Deposits” section.

Result. The decision to re-route traffic is made based on actual order data, not “gut feeling”.

3.3. Case 3. Detecting suspicious deposits and blocking abuse

📸 Screenshot 10 — risk case with similar deposits and blacklist

Scenario. The risk team suspects bonus abuse or money laundering.

Steps:

Find one of the suspicious deposits by merchant, amount or gateway.

Open “Similar deposits”:

see all attempts with the same IP/device/payment details;

analyse amounts, frequency, time of day and user behaviour.

If the pattern is confirmed:

from the deposit card add to blacklist the payerIdentifier, email, IP, wallet, etc.;

record the reason and link to the internal case in comments.

If needed, export the order list (FULL) and attach it to the investigation report.

Result. The risk team gets a full-fledged tool for investigation and immediate response, without digging manually in raw databases.

3.4. Case 4. Preparing a report for a merchant (aggregator scenario)

📸 Screenshot 11 — filter by one merchant and MERCH export

Scenario. A payment aggregator prepares a report for a merchant and does not want to expose PSP infrastructure details.

Steps:

In “Deposits”:

filter by the required merchant and period;

optionally filter by currency/channel.

In the footer click MERCH:

the report will contain amounts, statuses and order IDs;

internal PSP details and their commissions will be excluded.

Send the report to the merchant as the official breakdown of their payments.

Result. The aggregator is transparent to the client on their volumes, but keeps its payment infrastructure private.

3.5. Case 5. Technical anomaly and manual status correction

📸 Screenshot 12 — anomalous status and manual correction

Scenario. The gateway returns a non-standard status, the order gets “stuck” in Processing, but in fact the money has already been returned to the user.

Steps:

Using Payment report or the deposits list, find the red/anomalous order.

In the Payment path confirm:

that the gateway indeed returned a non-mapped status;

that the transaction was not processed (or was reversed).

After verification:

an administrator manually changes the order status to the correct one (failed / other final status);

the system sends a Telegram notification about the manual change.

As a follow-up:

update the status mapping so that these responses are handled automatically in the future.

Result. Even with non-standard PSP responses the system remains controlled and transparent.

3.6. Case 6. Connecting with reports and reconciliation

Scenario. The finance team is preparing a monthly reconciliation with a PSP and sees discrepancies.

Steps:

In the Summary report review:

the number of successful orders and turnover for a specific gateway in the period;

compare it to the PSP report.

In the Reconciliation module upload the PSP report:

get a list of matches and mismatches.

For disputed lines:

click the ID and open the corresponding order in “Deposits”;

use the Payment path to see what actually happened.

Build the final report based on:

PSP data,

PayStar data,

the set of specific orders for each disputed line.

Result. Reconciliation turns from an “Excel battle” into a manageable process with a solid evidence base for every disputed payment case.

“Deposits” section in PayStar

1. Business level

1.1. Why you need the “Deposits” section

1.2. Key roles and their use cases

1.3. How “Deposits” fits into the overall reporting picture

2. Navigation in the “Deposits” section

2.1. Main screen: deposits list

2.2. Deposit details

2.3. Payment path

2.4. Similar deposits (fingerprint)

2.5. Financial postings and commissions

2.6. Manual status change and security

2.7. Export and reports

3. Operational level: case studies

3.1. Case 1. Player complaint: money is debited, balance not updated

3.2. Case 2. Conversion drop on a specific gateway

3.3. Case 3. Detecting suspicious deposits and blocking abuse

3.4. Case 4. Preparing a report for a merchant (aggregator scenario)

3.5. Case 5. Technical anomaly and manual status correction

3.6. Case 6. Connecting with reports and reconciliation

“Deposits” section in PayStar

1. Business level#

1.1. Why you need the “Deposits” section#

1.2. Key roles and their use cases#

1.3. How “Deposits” fits into the overall reporting picture#

2. Navigation in the “Deposits” section#

2.1. Main screen: deposits list#

2.2. Deposit details#

2.3. Payment path#

2.4. Similar deposits (fingerprint)#

2.5. Financial postings and commissions#

2.6. Manual status change and security#

2.7. Export and reports#

3. Operational level: case studies#

3.1. Case 1. Player complaint: money is debited, balance not updated#

3.2. Case 2. Conversion drop on a specific gateway#

3.3. Case 3. Detecting suspicious deposits and blocking abuse#

3.4. Case 4. Preparing a report for a merchant (aggregator scenario)#

3.5. Case 5. Technical anomaly and manual status correction#

3.6. Case 6. Connecting with reports and reconciliation#

1. Business level

1.1. Why you need the “Deposits” section

1.2. Key roles and their use cases

1.3. How “Deposits” fits into the overall reporting picture

2. Navigation in the “Deposits” section

2.1. Main screen: deposits list

2.2. Deposit details

2.3. Payment path

2.4. Similar deposits (fingerprint)

2.5. Financial postings and commissions

2.6. Manual status change and security

2.7. Export and reports

3. Operational level: case studies

3.1. Case 1. Player complaint: money is debited, balance not updated

3.2. Case 2. Conversion drop on a specific gateway

3.3. Case 3. Detecting suspicious deposits and blocking abuse

3.4. Case 4. Preparing a report for a merchant (aggregator scenario)

3.5. Case 5. Technical anomaly and manual status correction

3.6. Case 6. Connecting with reports and reconciliation