Why integration with a rate aggregator disrupts payouts
Rate discrepancy occurs at the junction of two different views of price. The aggregator polls sources at its own frequency and caches the response on the storefront, while the exchanger recalculates the rate from its own order book at the moment of execution.
Between display and confirmation, from a second to several seconds pass, and in a volatile market that is enough for the rate discrepancy to exceed the acceptable threshold. The user sees one number, in fact agrees to another — and the order is either rejected or goes to support.
Rejected orders are rarely the result of a single cause. Usually it is a set: a partner's reserve limit, a failed check, a region restriction, and various error codes that the aggregator does not parse.
It returns a generic "unavailable" to the storefront, and the client goes to the next exchanger, even though the deal was technically possible.
Duplicate orders are a separate class. When the connection breaks, the client or the aggregator itself repeats the request, and if the pair does not have an agreed idempotency key, one operation turns into two. If the exchanger executes both — we get a double deal and an investigation instead of an exchange.
Peak load reveals everything at once. A surge during a sharp market move produces dozens of requests per second, partner limits trigger, some responses arrive with a timeout. Orders hang in an unknown status, and no one can say whether it is executed or not. We analyze how this is closed.
What changes in the exchanger after connecting the stream
Rate updates stop being a manual operation: the aggregator provides a stream by subscription, and the storefront receives the value within seconds after publication at the source.
Between them — normalization (aggregators calculate the rate differently: with the network fee, deal direction, minimum amount) and a delta filter that does not jerk the storefront on noise fluctuations.
The value passes a gap check: if the rate goes beyond the deviation boundary, there is no publication, and an event goes to monitoring.
Order conversion grows not from the "best rate," but from its consistency.
The client sees a number, it is locked for the duration of checkout and goes into the calculation without discrepancies — it was precisely the difference between the storefront and actual execution that gave the main share of abandoned forms.
Automatic order closing rests on a status model: creation, reserve, payment, network confirmation, payout.
Events from the provider and node are processed idempotently, so a repeat does not create a second order, and only cases with a mismatched amount or source silence go to manual review.
Load resilience is predictable degradation, not "a more powerful server." Orders go through a queue, limits per account and direction are checked at the entrance, and when the aggregator is unavailable, the storefront works on the last valid rate with an explicit stale flag. A traffic peak leads to slower processing, not double charges and lost orders.
After connection, we look at four values: the delay from rate publication to the storefront, the share of orders closed without an operator, the share of abandoned forms, and the number of refusals due to rate discrepancy. This is the measurable shift that can be seen when comparing before and after.
Connection methods: from a ready-made module to your own gateway
An exchanger has three fundamentally different paths into rate aggregators, and the choice between them is not based on solution popularity, but on order volume and on who is responsible for quote discrepancies.
Below is a comparison of connection options with their limitations, so that the scheme matches the load, and not the other way around.
The key difference between schemes is where the logic of matching the rate and order status lives. In a ready-made module, the platform holds it; in your own gateway, you do; and with a liquidity intermediary, it is smeared between the parties.
This determines how quickly you will see a discrepancy and whether you can roll back an erroneous quote.
| Option | When it fits | Scheme limitations |
|---|---|---|
| Ready-made aggregator module | Small and medium order flow, need a quick start without your own infrastructure | Rate and request retry logic is someone else's: the platform sets update rules, fine-tuning statuses is unavailable |
| Your own gateway to platform APIs | Dense flow and several aggregators at once, need a unified order log and idempotent processing | Requires your own queue, request rate control, and on-call duty for discrepancies |
| Liquidity intermediary | Need access to market depth and rapid expansion of the platform list | An extra link in the chain: longer confirmation, harder to investigate an incident for a specific deal |
| Direct agreements with the platform | Large volume and strict margin requirements | Long negotiations and a separate integration for each partner |
The limitations of a scheme manifest not at the start, but at peak load: when the platform changes the response format, some orders hang in an intermediate status.
Therefore, we fix the connection option before development — by the number of platforms, expected flow, and who is on call for rate discrepancies.
Integration stages: from exchange scheme to handover
Integration with a rate aggregator is not "connect the API and serve the rate." The aggregator brings flow, and the discrepancy between the rate on its storefront and the actual deal terms in the exchanger immediately hits conversion.
That is why the integration stages are structured so that each ends with a verifiable result, not a report.
- Exchange scheme audit. We analyze rate sources, priority between them, manual edits, rounding, and spread. The output is a flow map and a list of discrepancies with actual deal terms.
- Scheme design. We choose the model: polling on a schedule or event-based transfer. We define the order of sources, behavior when one of them is unavailable, and the rule by which the rate is considered stale.
- Setup and test loop. We set up an isolated loop with the aggregator's test environment: field mapping, error and limit handling, duplicate deduplication, response log for reconciliation.
- Load check. We run the aggregator's traffic profile with bursts and look at behavior under delays: we serve the last confirmed rate or mark it as outdated.
- Acceptance scenarios. We reconcile the rate for all pairs with the reference, check partial source unavailability, and rollback to the previous exchange scheme.
- Stream switchover. We transfer traffic in shares, comparing the refusal share and conversion on the new and old channel. Full switchover — after the metrics converge.
- Work acceptance and handover. We hand over the scheme, on-call policy, and metrics, and fix what we consider an incident and in what order we respond.
Before the stream switchover, no stage is considered complete "by eye": each has a criterion by which we jointly accept the result.
Exchange schemes, access, and handover policies
Integration is considered delivered not when rates arrive, but when the customer can change the set of sources without reading source code.
Therefore, by the end of the work, you retain a set of artifacts — we go through it at acceptance together with your engineers, rather than handing over an archive "for memory."
- Settings handover. Working mapping configurations: which aggregator response fields go into the rate, the deviation threshold between sources, timeouts, and the number of request retries. For each parameter — a comment on what will change in behavior if it is shifted.
- Flow scheme. The request path from client to rate fixation: where the cache is and how long it lives, where the queue is, at what point the backup source connects, and when payout is blocked. With failure points and how each is handled.
- Access rules. Roles and scopes: who edits the source list and priority between them, who changes thresholds, who sees only the log. Aggregator keys — in a secret store, with rotation and without output to logs.
- Documentation. Description of response fields and formats, an error code reference for each source, the procedure for connecting a new aggregator — from test key to inclusion in the production selection.
- Failure policy. What the system does and what people do when a source is unavailable, when rate discrepancies exceed the threshold, when refusals spike. With the order of switchover, notification, and re-enablement.
- Investigation log. Tracing for each rejected rate: which source responded, in what time, and by which rule the value did not pass. Without this, an incident turns into correspondence with the aggregator.
- Test loop. Recorded source responses and failure scenarios, so that new selection rules are tested before production traffic.
We update the package with every rule change — otherwise the documentation diverges from system behavior within a month.
Case: how an exchanger stopped losing orders from the stream
The exchanger received orders from three rate aggregators, and each went through an operator: rate reconciliation, manual transfer of payment details, deal confirmation.
At peak, this was 40+ orders per hour, and when the rate deviated by fractions of a percent, some orders went at the old price or were lost in correspondence — up to 12% of requests per day.
Reaction time to a rate change reached 15 minutes; per shift, an operator made about 60 manual edits.
We connected the exchanger to BestChange and the other aggregators directly: a unified rate service collects quotes, normalizes them, and sends them to the aggregator, while an incoming order is created automatically with a check by external identifier — duplicates from different sources do not turn into two deals.
The aggregator's response may arrive with a delay, so the order is queued, and the rate is locked at the moment of confirmation, not at the moment of sending.
Metrics before and after
Share of lost orders — from 12% to 1.5%. Reaction time to a rate change — from 15 minutes to 20 seconds. Manual edits per shift — from 60 to 4, and only disputed cases and large amounts remained. On the same visitor flow, turnover grew by about a third: some orders simply stopped going past.
We separately closed the desynchronization: a log of rate discrepancies and notification of the on-call person when the deviation exceeds the threshold.
The integration case showed that the bottleneck was not in attracting traffic, but in the manual link between the aggregator and the exchanger core.
How does direct connection differ from working through an intermediary?
The difference is who owns the price stream.
With a direct connection, the exchanger itself contacts the sources and builds its own rate table, while working through an intermediary it receives a ready-made number — recalculated, with someone else's margin baked in, and without access to the source data.
Rate control is the first discrepancy. With a direct connection, the spread, rounding step, and volatility reaction rules are set by the exchanger itself: you can tighten the margin on a popular direction and raise it where the flow is thin.
An intermediary does not give such settings, it sends a single value, and everything between the source and that value remains closed.
Update speed depends on how many layers stand between the source and the storefront.
A direct connection carries a rate change in one step; with an intermediary, an intermediate link and its own buffer are added — during a sharp market move, the calculation on the client side lags, and the order goes at a price that no longer exists.
Transparency of failures is structured similarly. With a direct connection, you can see which source did not respond, how many times, and with what delay — the failure is localized and closed pointwise.
Through an intermediary, a top-level error arrives, and it is unclear whether the problem is with it or the counterparty: diagnostics drag on, and the client sees a hung calculation.
The main cost of working through an intermediary is dependence on the partner. It changes limits, the set of directions, and rounding rules unilaterally, and the connection may drop without warning.
Therefore, in practice, a hybrid is more often chosen: key directions are handled directly, while rare ones are covered by an aggregator as a safety net.
Frequently asked questions about connection and order flow
Connecting to rate aggregators almost always raises the same doubts — about an intermediary, rate jumps, and the fate of an already flowing stream. Below are substantive answers, without generic formulations.
We work through an intermediary — will the transition be painful?
There is no need to break the scheme: we set up a direct connection in parallel, and for some time both channels work simultaneously.
We compare rates, limits, and order statuses, and disconnect the intermediary only after the data matches — the direction stops losing on its markup and on the delay in rate transmission.
What happens to orders during sharp rate jumps?
The aggregator's rate lives for a limited time, so the order locks the value at the moment of confirmation, not at the moment of request. When the market moves, the deviation threshold triggers: the deal is not closed at a stale price, but recalculated or returned to the client.
How long does connection take and what about current orders?
A typical timeframe is from two to four weeks: access and currency pair mapping, then the test loop and rollout into the production stream.
The existing channel accepts orders as usual the whole time, history and statuses remain in place, and we introduce the new loop with a share of traffic.
How is junk flow filtered out?
At the entrance — rules by amount, currency pair, and request frequency; at the exit — reconciliation with the platform's reputation labels. An order that does not pass the threshold does not reach the operator, and the share of canceled deals falls several times over.
Let's discuss the task and come back with an estimate and plan
To come back with a work estimate and connection plan, rather than general formulations, we need a picture of your current exchange scheme with rate aggregators. The more accurate the source data, the fewer assumptions in the estimate and the more predictable the first release.
- Which rate aggregators are already connected and under which model: link click-through, rate retrieval via API, direct order transfer. Note where you hit request rate limits.
- Exchange format: how rates, limits, and directions arrive, how often the cache updates, and what happens on the exchanger side when data desynchronizes with the source.
- Flow volumes: how many directions and currency pairs are in operation, how many requests per minute arrive at peak, what share refusals make up on current connections.
- How conversion is calculated: at what point the transition to you is recorded and at which step the main part of the flow is lost.
- Recalculation rules: rate rounding, fees, minimum and maximum amounts, the procedure for accounting during a sharp market move.
- Access and test environments for aggregators, request limits, the procedure for approving rollout to the production loop.
- Responsible parties on both sides and the allowable downtime window during traffic switchover.
With this set, our engineers build the exchange scheme, mark bottlenecks, and determine what is closed by the aggregator's standard tools and what requires a separate layer.
Describe the task in any convenient form — we will come back with a work estimate, a stage-by-stage connection plan, and a list of risks that should be removed before the start.