Swaps
Swaps allow a merchant to exchange one crypto asset for another directly inside the platform. The main goal is to provide a fast, controlled conversion flow without manual work in external services.
In the dashboard, this appears as a dedicated section with:
a swap creation form,
a confirmation screen,
a list of all swaps,
a swap details view with status and execution data.
How a swap works
The flow is built as a managed lifecycle, where each stage has a clear role.
Request creation The merchant selects the source asset, target asset, and amount. At this stage, the platform allows only assets and directions that are actually supported for this specific merchant.
Preliminary calculation (estimate) The platform calculates the expected outcome and shows terms before execution starts. This estimate is approximate, as market conditions, routing conditions, and network fees may change.
Confirmation and amount reservation After confirmation, the operation is locked in and the source amount is reserved immediately. This protects the process from balance changes between estimation and actual execution start.
Route execution The platform runs the swap using internal route selection logic. If several routes are available, it picks the one with the best expected outcome. For some cross-network directions, a specialized route may be used.
Finalization and crediting After execution is completed, the platform records the actual result and credits the target asset. This final credited value is treated as the swap result.
What to understand about amounts
The estimate and the final credited amount may differ. This is a normal part of swap business logic.
The confirm-stage estimate is a quote, not a permanent fixed value. At confirmation, the merchant sees the best available estimate at that moment. However, between confirmation and final execution, the request passes through processing stages and network confirmations. During that time, market conditions may shift. Because of this, the final value is determined by actual execution, not frozen forever at form time.
The final result depends on the real execution route and its operational steps. The same swap pair may be executed through different routes depending on liquidity and network constraints. Each route has its own execution profile and cost structure. The platform therefore finalizes the amount only after the real route is completed and all factual execution parameters are known.
Fees are composed of multiple components. The outcome is affected by a combination of factors: network costs, route-level operational costs, and the platform system fee. These are applied automatically in final settlement. The merchant receives an amount that reflects the real end-to-end cost of the operation under current conditions.
Pre-execution checks
Before execution starts, the platform validates key conditions. These checks prevent invalid or high-risk operations from entering processing.
Asset pair availability for this merchant. The platform verifies that selected assets are active in the merchant account and can be used in the chosen swap direction. This avoids cases where assets exist globally in the platform but are not available in the merchant’s current setup.
Direction and network/token rule validation. The platform validates that the selected “from/to” combination matches supported swap scenarios. If the direction is blocked by platform rules or infrastructure limitations, execution is stopped before launch and a clear error is returned.
Available balance sufficiency check. The system checks available balance, not only total balance. This is important because part of funds may already be reserved by other operations. If available funds are insufficient, the swap is rejected before execution, preventing downstream failures.
Minimum amount threshold in USD equivalent. Swaps have a minimum threshold to keep operations economically meaningful relative to network and routing costs. The entered amount is converted to USD equivalent and checked against this minimum. If it is below the threshold, the platform does not start execution and returns a clear reason.
Target infrastructure readiness for crediting. Before launch, the platform confirms it can safely receive and credit the resulting asset in the target network. This reduces the risk of partial scenarios where execution is initiated but result delivery cannot be finalized properly.
Merchant-facing statuses
The dashboard uses clear high-level statuses:
New - swap created and queued for processing,
In progress - execution is running,
Finished - swap completed and result credited,
Rejected - execution did not complete successfully and was rejected.
Additional internal service sub-stages exist, but they are abstracted into clear external statuses for the merchant.
What happens on failures
The service is designed not to leave swaps in an undefined state. If a swap cannot be completed safely within allowed checks, it moves to rejected status and source funds are returned according to platform rules.
This gives the merchant a predictable outcome:
either successful conversion with credited result,
or safe termination with rejection and refund.
What the merchant sees in history
The swap list is not only for tracking active operations, but also for financial history. Each entry includes key data: creation time, swapped assets, current status, and final outcome after execution. This makes swaps a transparent, controllable part of the merchant’s financial workflow inside the platform.
Last updated