General Process Logic

The system automatically processes operations that, for various reasons, were not correctly completed in the external wallet.

The process consists of three sequential stages:

Search for unfinished operations

Rollback attempt

Retry execution of the operation

Each stage is triggered on a schedule, works independently, and includes protection against infinite retries.

Stage 1. Collection of Unfinished Transactions

Purpose of the Stage:
To find operations that are “stuck” — i.e., successfully initiated but did not receive a final result (deposit or rollback).

1.1 Process Initiation

The resolver service starts the process of collecting unfinished transactions on a timer.
The execution frequency is defined by a parameter on our side.

1.2 Selection of Candidate Operations

The system searches for operations that meet all of the following conditions:
• Operation type: withdrawal
• Operation status: successful
• Operation is not marked as ignore
• Operation is not in demo mode

The operation has no:
• deposit
• repeated deposit (second chance)
• rollback with the same tx_id

The operation is in a “suspended” state:
• older than the configured delay
• but not older than delay + 4 hours

This means:
• if the operation has been stuck longer than the allowed time — it is taken for processing;
• if the operation is too old — it is ignored;
• if the operation is still “young” — it waits for the next cycle.

1.3 Cache Filtering

For each found operation, a check is performed in Redis:
• if the operation has already been processed — it is skipped;
• otherwise, the operation is added to the list of new ones.

1.4 Data Preparation

For new operations, a FailedOperation record is created with the status:
• WaitingForRollback

1.5 Database Persistence

All new operations are saved to the database in a batch.
A flag indicating that the operation has been processed is stored in Redis.
TTL: 24 hours.

1.6 Stage Completion

The transaction is committed.
The operations then move to the next stage — rollback.

Stage 2. Rollback

Purpose of the Stage
To attempt to correctly cancel the operation if the deposit was not executed.

2.1 Process Initiation

The rollback process is triggered on a timer.
The execution frequency is defined in seconds.
The delay before a retry is also defined in seconds.

2.2 Operation Selection

Operations with the following status are selected from the failed_operations table:
• WaitingForRollback

2.3 Processing Execution

Each operation is processed individually.
Results are collected and saved in a batch.

2.4 Processing a Single Operation

Client overload protection (circuit breaker)
• The client error counter is checked in Redis.
• If the limit is exceeded:

the operation is temporarily skipped;

the retry is postponed.

Rollback attempt
• If the operation type is rollback → perform rollback.
• In all other cases, perform a corrective deposit with an amount of 0.

Successful result
Operation status:
• SuccessRollback

Non-critical errors
If the error indicates that the operation has already been processed (e.g., the transaction is not found or already closed):
• Operation status:

ResolvingNotNeeded
• A low-priority notification is sent.

Other errors
• The error counter is incremented.
• The next retry time is scheduled.
• If the number of attempts exceeds the limit:

The operation is marked as permanently failed.

A high-priority notification is sent.

2.5 Metrics

• Successful rollbacks are tracked separately.
• Errors and skips are also logged.

2.6 Result Persistence

All changes are saved to the database in a batch.

Stage 3. Retry

Purpose of the Stage
To re-execute the deposit if a rollback is not required or is not possible.

3.1 Process Initiation

The retry process is triggered on a timer.
The execution frequency is defined in seconds.
The delay before a retry is defined in seconds.

3.2 Operation Selection

Operations with the following status are selected from the failed_operations table:
• WaitingForRetry

3.3 Preparation

Transaction identifiers are extracted.
Deposit amounts are determined.
Operations are processed in parallel.

3.4 Processing a Single Operation

Client overload protection
• The client error counter is checked.
• If the limit is exceeded, the operation is temporarily skipped.

Deposit amount validation
• If the amount is not found:

the operation is moved to rollback.

Deposit retry
• A repeated deposit is executed.
• If necessary, the second chance mode is used.

Successful result
• Operation status:

SuccessDeposit

Non-critical errors
• If the operation requires no further actions:

Status:

ResolvingNotNeeded

A low-priority notification is sent.

Other errors
• The attempt counter is incremented.
• The next retry is scheduled.
• If the limit is exceeded:

the operation is moved to rollback;

a high-priority notification is sent.

3.5 Metrics

• Successful retries are counted separately.
• Errors and skips are tracked separately.

3.6 Result Persistence

All changes are saved to the database in a batch.

Rollback and billing resolver general flow

General Process Logic#

Stage 1. Collection of Unfinished Transactions#

1.1 Process Initiation#

1.2 Selection of Candidate Operations#

1.3 Cache Filtering#

1.4 Data Preparation#

1.5 Database Persistence#

1.6 Stage Completion#

Stage 2. Rollback#

2.1 Process Initiation#

2.2 Operation Selection#

2.3 Processing Execution#

2.4 Processing a Single Operation#

2.5 Metrics#

2.6 Result Persistence#

Stage 3. Retry#

3.1 Process Initiation#

3.2 Operation Selection#

3.3 Preparation#

3.4 Processing a Single Operation#

3.5 Metrics#

3.6 Result Persistence#