Reducing Operational Friction in Payment Processing

Payment infrastructure rarely becomes unstable because of one major failure. More often, complexity accumulates gradually:

• transaction requests stop fitting neatly into predefined API structures;
• provider responses become difficult to interpret;
• retry logic grows outside the platform itself;
• routing decisions slowly turn into manual operational work.

Individually, these issues may look minor. Over time, they create friction across integrations, support, risk operations, and merchant experience. The latest updates across Checkout and Gateway infrastructure focus on exactly these layers of payment processing — not on adding more complexity, but on moving more of it into predictable system behavior.

More flexible transaction data handling

Token creation requests and Gateway transactions (payment, payout, authorization) now support up to three additional custom fields. Technically, this is a small update. Operationally, it solves a very common PSP problem.

As payment ecosystems grow, standard request structures inevitably become too rigid for real business flows. PSPs start working with custom merchant logic, internal scoring systems, additional identifiers, regional requirements, or sensitive business-related parameters that simply do not fit into predefined fields — and that usually creates fragmented logic outside the payment flow itself.

Now this information can be transferred directly inside the transaction request. For widget-based payments, merchants can also collect additional customer information during the confirmation step through dedicated fields on the payment page.

Better visibility into provider errors

Another update improves transaction diagnostics and provider error visibility. Previously, if no mapping existed for a provider error, the platform returned F.0999, the message parameter contained a generic response, and the original provider context was often unavailable.

For PSP teams, this created a familiar situation: the transaction failed, but the actual reason remained hidden somewhere between provider logic and internal processing. The updated behavior changes this flow.

Most merchants will never notice this change directly. But inside day-to-day payment operations, it changes the speed of investigation significantly. When PSPs work with multiple acquirers and constantly changing processing channels, generic errors create unnecessary blind zones. Returning more provider context directly inside the transaction flow reduces this ambiguity and makes troubleshooting faster and more predictable.

New cascading logic for H2H transactions

The largest update in this release is the new cascading solution for host-to-host card transactions. The platform already supported cascading payments before: merchants could retry failed transactions manually by excluding failed gateways through additional_data.excluded_gateways, while widget-based payments already supported automatic retry behavior.

The new approach moves cascading deeper into the platform itself. When the Enable cascading payments (h2h) option is activated for a merchant, and multiple card gateways are available, the platform can now automatically retry failed payments through another available gateway without requiring additional retry requests from the merchant.

The merchant receives only the final transaction result:

• successful;
• or the final failed result after all available gateways have been exhausted.

The customer also receives only the final email notification. At the same time, every transaction attempt remains fully visible inside the back office and reporting system.

Why this matters

Cascading is rarely just about retries. For many PSPs, especially in high-risk environments, routing exists inside unstable conditions:

• approval rates fluctuate throughout the day;
• providers temporarily degrade under load;
• one acquiring channel starts slowing down during peak traffic hours;
• another becomes unstable for specific regions or card types.

In these situations, manual retry orchestration quickly turns into a fragile layer of additional logic around the payment flow. The new H2H cascading model allows the platform itself to absorb part of this instability automatically.

Gateway priority management through Smart Routing

If gateway prioritization is required, routing sequences can be configured through Smart Routing. The configuration uses:

"rule_flow_type": "Object"
"method":         "Sequential"

PSPs can then define gateway order and routing priorities through dedicated rules. Even simple conditions are enough to create sequential routing behavior, although more advanced logic can also be added when needed. The solution currently supports:

• Card payment transactions
• Recurring payments
• Flows with and without 3-D Secure authentication

Predictable behavior matters more than feature count

Large-scale payment systems are rarely defined by one major feature release. More often, maturity is built through smaller architectural decisions that gradually reduce friction across the processing environment:

• clearer diagnostics;
• more reliable routing behavior;
• cleaner integration structures;
• fewer manual recovery scenarios;
• less fragile retry logic.