White Label
Custom payment solutions
Unlock business growth with custom payment solutions tailored to your needs. Discover secure, flexible options for seamless transactions today.
-
Solutions
European Banks
A ready-to-use white-label payment processing solution under your brand
Low-Risk PSPs
The ultimate white-label payment gateway for low-risk PSPs
iGaming and Forex
Built for high-risk. tuned for high approve rates. Fully Branded as Yours.
- Resources
Open Workout Challenge: Smart Routing Optimization
How we tackled a hefty flow of transactions, dozens of restrictive rules, and synchronous operation, teaching Smart Routing to avoid unnecessary ‘push-ups.’
Background: The 30-Second Rule
In our system, a default timeframe of 30 seconds is allocated for a transaction to start and finish, meaning it should obtain a final status of “Success” or “Declined.” The entire process—from the moment the API request enters our system to receiving the final response from the ultimate acquirer or PSP—is allotted these 30 seconds.
These 30 seconds are necessary to avoid creating queues in synchronous integration mode. While awaiting a response from the acquirer or PSP, we maintain a network connection with them.
Synchronous Mode
We establish a network connection and keep it open from the first request until the final result. Since simultaneous connections are limited by hardware, if the limit is reached, new requests face service denial.
Asynchronous Mode
Optimized for high loads. We send a request and terminate the connection immediately. We then wait for a callback (notification) with the result, freeing up resources for other requests in the meantime.
Usually, 30 seconds in synchronous integration mode is more than enough. However, if the acquirer takes a long time to respond, and we cannot obtain the final status within 30 seconds, the transaction remains "Incomplete."
The Problem
Our tenant faced an issue with a PSP that did not support asynchronous mode. A major merchant interpreted our “Incomplete” statuses as “Declined” and cascaded transactions to a second acquirer. This caused double debiting because the first transaction was actually successful—our system just timed out before receiving the confirmation.
The Investigation
Logs showed the PSP responded in 18 seconds with a success message. Yet, our system timed out. We discovered the transaction was delayed inside our own Smart Routing for over 12 seconds.
We discovered that our tenant’s system had created 30 aggregative rules at the PSP level. These rules applied to every transaction and checked limits for 30 different currencies.
“If the transaction amount is greater than N for the current month where: transaction currency = A, transaction type = payment, transaction status = success, then decline.”
The Flaw: The system performed calculations for all 30 currencies for every single transaction, regardless of the transaction's actual currency. Because the merchant had over a million transactions, accessing the database 30 times to aggregate monthly totals for every new request took 12+ seconds. Combined with the PSP's 18-second response, this exceeded the 30-second limit.
The Solution
To address this, we added the ability to set a precondition for a rule in Smart Routing. The system can now determine whether to execute a specific rule (and trigger the heavy calculations) or skip it entirely.
Optimized Logic
Currency Matching Precondition
The system now looks at the transaction currency in the precondition of the rule and compares it with the incoming transaction.
- Match Found: The calculation of aggregated values is triggered only for that specific currency.
- No Match: The rule is skipped, and no database calculation is performed.
Now, out of 30 rules, only one is effectively triggered. Smart Routing processes all aggregative limiting rules in less than a second, as expected.
In Conclusion
We discovered this problem because a series of circumstances coincided:
-
High Transaction VolumeA large flow of payment transactions for our tenant.
-
System-Wide Limiting RulesDozens of limiting rules applied at the PSP level. With fewer rules, Smart Routing would have finished in 1-2 seconds.
-
Slow External ResponseA long response from the acquirer or PSP (more than 15 seconds).
-
Synchronous InteractionIf communication had been asynchronous, we would have completed the transaction in 35-40 seconds without issues.
Relevant articles
Oct. 17, 2024, 9:37 a.m.
The Case from Our Experience: Teaching Smart Routing to Avoid Unnecessary “Push-ups”
