rGateway is a payment orchestration layer. Your applications call one API; rGateway handles the PSPs and banks, routing, cascading, limits and reconciliation.
One integration for deposits, withdrawals and transaction flows.
Providers connected once, behind the API.
Rules choose the provider; eligible failures cascade to the next provider under those rules.
Payment methods, limits and fees managed centrally.
Transaction monitoring, reconciliation and payment analytics.
A deposit request arrives from the client app.
Routing rules select the preferred PSP for the card and country. It fails with a technical error. Because the rules, the provider and the payment network allow a retry for this customer, rGateway cascades to the next provider, which confirms. The wallet in rPAM is updated and the full attempt history is written for reconciliation and for rMIB’s payment-risk signals.
In this illustration the deposit completes; a decline that does not qualify for cascading stays declined, with the same single history. Finance reconciles one transaction; risk sees the signal.
Your PSP and bank credentials; cascading rules and provider support for retries; rPAM, rPlatform or your own application as the caller.
rGateway sits between your applications and your providers: applications call one API; providers are connected behind it. Which PSP and bank connectors are live is listed in the demo, not assumed.
Supported connectors are disclosed in the demo flow.
Wallets and deposits in the client journey — native.
Payment-risk signals — native.
Connected through API.
The demo is the API and the rules: connect a sandbox provider, define routing and cascading, run deposits and withdrawals and read the transaction history.
A rGateway environment with API access.
Payment methods, routing and cascading rules, limits and fees.
Configuration when production is activated.
A business email and company details. PSP credentials to connect your own providers.