Payment Orchestration
Route every payment and reconcile every account.
One integration in front of every payment provider you use. Route each deposit and withdrawal by country, currency, card brand, amount, fund source and customer profile. Retry with the next provider when one declines, and reconcile every transaction across your providers, your CRM and your trading platform.
A declined deposit isn't a delayed sale. It's a lost client.
The deposit form is the last step in your funnel, and usually the one that gets the least attention. When a payment fails there, the client often doesn't try again. They fund an account somewhere else.
Every point of approval rate is deposit revenue you already paid to acquire.
Issuers decline, risk rules trip, providers time out. Every failure lands on a client you have already paid to acquire.
When your primary PSP has an outage or tightens its risk appetite, deposits stop, and there is nothing behind it to take the traffic.
Weeks of integration work per PSP, then maintenance every time their API changes. So local payment methods in new markets wait.
Someone chose which provider handles which country and currency, wrote it into code or a spreadsheet, and that configuration has been ageing ever since.
The PSP says one thing, the CRM says another and the trading platform says a third. Finance reconciles two of them and hopes the third follows.
Which countries are blocked, what a new client's limit is, what happens on a bank holiday. None of it is enforced where the payment actually runs.
Your payments stack, with nothing in front of it.
Hover or tap a problem to see where it lives.
- Client cashier
- Your code: if (country == "IN") psp = LOCAL_1; else if (brand == "VISA") psp = CARD_A; else psp = CARD_A // no fallback
- PSP-A · Cards: Declined · issuer
- PSP-B · Cards: Integration project · in progress
- PSP-L · Local transfers
- PSP settlement: €500.00 settled. CRM: €500.00 credited. Trading platform: €0.00 · not synced
- blocked-countries.xlsx
Illustrative stack.
Keep your providers. Connect your business.
Fragmented systems slow decisions and create extra work. Bring your trading, payments and service providers into connected processes.
Add new partners and offerings with less disruption to the business.
- Where payments start: client portal widget, mobile apps and your systems, through the widget, SDKs or the API.
- FYNXT payment orchestration routes each payment, cascades it when a provider declines, and reconciles the result.
- One integration reaches your payment providers: PSP-A, PSP-B and PSP-L, with more added as you grow.
- Reconciliation legs: Financial CRM, with client wallets, and your trading platforms.
routing: rule 02 selected PSP-A
For your payments, finance, operations and compliance teams: routing rules, limits, transactions, reconciliation and reports.
For your clients: a multi-currency wallet with deposit and withdrawal flows, on web and mobile.
For platform operations: the provider marketplace, monitoring and multi-tenant administration.
When one provider declines, the next one tries.
Your PSPs sit in a priority order you set. When a provider declines, the transaction moves to the next one automatically, with no intervention from your team and no second attempt from your client. The deposit that would have failed outright gets another chance to land.
A declined payment is a lost deposit. Cascade it instead.
This session: 0 deposits sent · 0 recovered by cascade
Simulation. Providers, decline reasons and timings are illustrative.
Six dimensions. Two modes. Live optimisation.
Write routing rules on the attributes that decide whether a payment clears. Rank providers for a priority cascade or split traffic by weight, and let performance data move the order when a provider starts to struggle.
Your licence conditions, enforced at the routing layer.
The rules that usually live in a spreadsheet and one senior person's memory become configuration. Every transaction is checked against them before it reaches a provider.
Limits shown are examples. You set minimum and maximum amounts per currency, provider and customer profile, with separate withdrawal limits aggregated daily, weekly and monthly.
Duplicate detection runs on every transaction. Rule and limit changes go through approval, and every transaction keeps a complete audit trail.
Reconciliation that reaches your trading platform.
A standalone orchestrator owns one corner of the triangle. It checks its own ledger against the PSP and stops there. FYNXT runs the payment layer, the CRM and the trading-platform integration, so it validates all three corners at once and catches the discrepancies a two-way check can't see.
Your orchestrator reconciles to your ledger. Ours reconciles to your trading platform.
Settlement files matched to CRM records by transaction ID, amount and timestamp. Amounts and fees validated with currency conversion, and status kept consistent automatically.
Handling the other side of the money flow? TradeOps Control Center runs bulk balance operations on MT4/MT5.
The three reports a payments team actually needs.
Not a generic dashboard. Transaction detail, provider performance, and a cascade report that shows exactly what was recovered and where.
Transaction report builder
Drag the columns you need into the report, filter by date, provider, status and currency, sort and group, and save the configuration for next time.
Sample transaction report with the columns Transaction ID, Client, Date, PSP, Status, Currency, Amount and Cascade path, filtered by date, status and currency, with a saved configuration.
PSP totals
Approval and rejection rates by provider, transaction counts, a breakdown by payment method, fees collected and revenue attributed per provider in standardised USD, with trend comparison against earlier periods.
Sample PSP totals, 1–16 Sep 2026 vs 1–16 Aug 2026, all payment methods.
- PSP-A: 4,812 transactions, 88.6% approved, 11.4% rejected, fees $6,140, revenue $1.94M, trend +1.2 pts.
- PSP-B: 3,105 transactions, 85.1% approved, 14.9% rejected, fees $4,020, revenue $1.21M, trend −0.6 pts.
- PSP-L: 2,244 transactions, 90.3% approved, 9.7% rejected, fees $1,380, revenue $0.41M, trend +0.4 pts.
- PSP-C: 1,190 transactions, 81.7% approved, 18.3% rejected, fees $1,910, revenue $0.52M, trend −2.1 pts.
Cascading report
First-attempt success and failure reasons, success rate and volume at each cascade level, and the transactions and value recovered, with recommendations on where the order could improve.
Sample cascading report.
- Level 1: 10,000 attempts, 8,720 approved.
- Level 2: 1,280 attempts, 190 approved.
- Level 3: 1,090 attempts, 60 approved.
- Recovered: 250 transactions, $96,400.
- First-attempt failure reasons: Issuer decline 46%, Risk rule 27%, Timeout 15%, Authentication not completed 12%.
- Recommendation: Move PSP-C above PSP-D for Mastercard · USD. It approved more level-2 retries over the last 30 days.
- Export to CSV, PDF, Excel or JSON
- Streaming export for large datasets
- Password-protected, encrypted exports
- Scheduled daily, weekly, monthly or custom
- Time-zone aware
- Role-based recipients by email
A new provider is configuration, not a project.
Adding a PSP stops being an engineering project. FYNXT comes with a library of pre-configured connectors, and anything that isn't in it is built in a low-code TypeScript environment, tested in a sandbox that mirrors production, and switched on.
Serving a new market's local payment methods becomes a configuration task, not an engineering commitment.
Timelines depend on the provider and your requirements.
Connector configuration: export const connector = defineConnector({ name: "psp-local-in", operations: ["deposit", "withdrawal", "refund"], currencies: ["INR"], countries: ["IN"], mapStatus: (res) => (res.state === "SUCCESS" ? "approved" : "declined"), });
Simplified illustration.
Keep the providers you already use. FYNXT fronts them, and adding more is configuration.
The deposit flow your clients actually complete.
A multi-currency wallet sits beside the client's trading accounts in your portal, and a deposit takes three steps. FYNXT decides which gateways to show based on the transaction type, amount, currency and location, and shows fees before the client confirms.
Tokenised. Encrypted. Audited.
Payment data is the most sensitive data a financial institution holds. FYNXT tokenises it, encrypts it in transit, puts sensitive changes behind approval, and records who did what.
How FYNXT payment orchestration compares.
Most firms aren't choosing between two vendors. They're choosing between orchestration and the direct integrations they already run. Here's how the four approaches line up.
| Capability | FYNXT | Standalone orchestrator | CRM payment module | Direct PSP integrations |
|---|---|---|---|---|
| Pre-configured connectors | Connector library, plus low-code builds | Varies, often broad | Limited list | One per integration built |
| Adding a provider | Configuration in a low-code environment | Vendor-dependent | Vendor request | An engineering project |
| Priority cascade on decline | Yes | Usually | Rare | Hand-coded, if at all |
| Weighted distribution | Yes | Usually | Rare | No |
| Routing dimensions | Country, currency, card brand, amount, fund source, customer profile | Typically three or four | One or two | Whatever you built |
| Performance-driven re-prioritisation | Yes | Sometimes | No | No |
| Reconciliation reach | PSP ↔ CRM ↔ trading platform | PSP ↔ own ledger | PSP ↔ CRM | Manual |
| Cascade recovery reporting | Dedicated report | Sometimes | No | No |
| Jurisdictional controls (allow/block lists, regional groups) | Built into routing | Partial | Partial | Hand-coded |
| Customer profile tiers (VIP, Standard, New, Restricted) | Yes | Rare | Rare | No |
| Client widget with SDKs, designed for WCAG 2.1 | Yes | Usually | Basic | Build it yourself |
| Native to CRM, client portal and trading stack | Yes | No | CRM only | No |
| Capability | FYNXT | Standalone orchestrator |
|---|---|---|
| Pre-configured connectors | Connector library, plus low-code builds | Varies, often broad |
| Adding a provider | Configuration in a low-code environment | Vendor-dependent |
| Priority cascade on decline | Yes | Usually |
| Weighted distribution | Yes | Usually |
| Routing dimensions | Country, currency, card brand, amount, fund source, customer profile | Typically three or four |
| Performance-driven re-prioritisation | Yes | Sometimes |
| Reconciliation reach | PSP ↔ CRM ↔ trading platform | PSP ↔ own ledger |
| Cascade recovery reporting | Dedicated report | Sometimes |
| Jurisdictional controls (allow/block lists, regional groups) | Built into routing | Partial |
| Customer profile tiers (VIP, Standard, New, Restricted) | Yes | Rare |
| Client widget with SDKs, designed for WCAG 2.1 | Yes | Usually |
| Native to CRM, client portal and trading stack | Yes | No |
| Capability | FYNXT | CRM payment module |
|---|---|---|
| Pre-configured connectors | Connector library, plus low-code builds | Limited list |
| Adding a provider | Configuration in a low-code environment | Vendor request |
| Priority cascade on decline | Yes | Rare |
| Weighted distribution | Yes | Rare |
| Routing dimensions | Country, currency, card brand, amount, fund source, customer profile | One or two |
| Performance-driven re-prioritisation | Yes | No |
| Reconciliation reach | PSP ↔ CRM ↔ trading platform | PSP ↔ CRM |
| Cascade recovery reporting | Dedicated report | No |
| Jurisdictional controls (allow/block lists, regional groups) | Built into routing | Partial |
| Customer profile tiers (VIP, Standard, New, Restricted) | Yes | Rare |
| Client widget with SDKs, designed for WCAG 2.1 | Yes | Basic |
| Native to CRM, client portal and trading stack | Yes | CRM only |
| Capability | FYNXT | Direct PSP integrations |
|---|---|---|
| Pre-configured connectors | Connector library, plus low-code builds | One per integration built |
| Adding a provider | Configuration in a low-code environment | An engineering project |
| Priority cascade on decline | Yes | Hand-coded, if at all |
| Weighted distribution | Yes | No |
| Routing dimensions | Country, currency, card brand, amount, fund source, customer profile | Whatever you built |
| Performance-driven re-prioritisation | Yes | No |
| Reconciliation reach | PSP ↔ CRM ↔ trading platform | Manual |
| Cascade recovery reporting | Dedicated report | No |
| Jurisdictional controls (allow/block lists, regional groups) | Built into routing | Hand-coded |
| Customer profile tiers (VIP, Standard, New, Restricted) | Yes | No |
| Client widget with SDKs, designed for WCAG 2.1 | Yes | Build it yourself |
| Native to CRM, client portal and trading stack | Yes | No |
Columns describe the common shape of each approach, not any specific vendor. Capabilities vary by vendor and release, and we're happy to go through a specific comparison in a demo.
The ones payments teams actually ask.
Still weighing it up?
Bring your provider list, your markets and how you reconcile today. We'll walk through routing, cascade and reconciliation against what you already run.
Ready to stop losing deposits?
Bring your provider list and your markets. We'll map routing, cascade and reconciliation against what you run today.
What changes
- Declines get another provider, not a lost client.
- New providers become configuration, not a project.
- Routing and compliance rules live in the system, not in someone's head.
- Reconciliation exceptions are surfaced and tracked, not hunted.