BridgerPay: payment routing, retries and reconciliation for funding operations

BridgerPay orchestrates payments across multiple service providers, acquiring connections and payment methods. Its financial-institution proposition covers pay-ins, payouts and consolidated reporting. For an FX broker, the relevant task is coordinating client funding across countries and providers while preserving a usable transaction record. The orchestration layer supplies routing and visibility around those connections; each financial provider’s commercial and settlement arrangement remains distinct.[9]

Retry is a sequence of processing attempts, not a way to make every declined card acceptable. BridgerPay describes analysis of decline codes, payment types and behavioral patterns, with fallback between connected providers and support for recurring and wallet payments. It also describes maintaining a unified 3DS session through eligible retries. The practical purpose is to recover a transaction affected by a temporary or provider-specific issue. A decline that calls for the transaction to stop should not be interpreted as permission for an unlimited sequence of alternative attempts.[2]

The checkout offer ranges from a payment link to a server-side MPI integration. An embedded widget places the payment journey inside the merchant’s existing interface; Blox provides modular components, while mobile options cover Android and iOS. These routes imply different amounts of work in the broker’s client portal and different handling of the payment interface. Tokenization can reduce exposure to raw card data, but the checkout page’s PCI-scope-reduction claim does not establish that the merchant has no remaining card-security responsibilities.[4]

For financial customers, BridgerPay describes connections to CRM, ERP and billing systems alongside payment reporting and fraud rules. The useful integration is the link between a payment event and the broker’s own customer and ledger records: a completed checkout, a processing response and an internal account credit are different records even when the user experiences them as one deposit. The published feature material supports these integration categories, but does not establish a native connector for every named broker CRM or a common schema across all providers.[10]

Its financial-institution page lists RedAcre for trading operations, YourPropTrading for prop firms and Saphyte for CRM and payment workflows.[9]

Network tokenization is offered for recurring and card-on-file payments as well as routing flexibility. BridgerPay describes network-issued credentials that can be updated as card details change and used across provider connections. A network token is constrained to authorized uses rather than being a freely reusable replacement card number. The product’s portability proposition is useful when considering a provider change, but it is not a published contractual promise that every existing token can be exported or moved to any new processor without additional enrollment or configuration.[17]

The January 2026 website terms explicitly place payment-orchestration services under a separate written Subscription Agreement. The website terms therefore do not establish a customer’s service price, renewal commitment or termination rights.[8]

The product material gives no numerical platform tariff or standard minimum monthly bill. A demo or sales discussion is the public entry route. The OS’s list of capabilities does not establish which operations are included in every agreement or how they are charged.[1]

A payment setup has two closely related configuration layers. The checkout determines which payment options are presented and how the customer enters the flow; the route determines the sequence of connected providers used to process the payment. BridgerPay’s router uses country-level arrangements and drag-and-drop ordering. A new provider connection therefore has an operational effect only when it is placed into the relevant route and the intended traffic reaches it. This is also why a change to visible payment methods is not necessarily a change to the processing sequence.[3]

The transaction walkthrough follows the customer’s selected method into card and issuer context, authentication, tokenization, provider selection and retry handling. Country, currency and method availability can affect the checkout before processing begins. The routing stage then considers such factors as the provider’s status and the transaction’s characteristics. This is a useful distinction for implementation: testing only the final approval response misses the earlier decisions that determine whether a customer sees the correct method and whether the intended provider receives the request.[16]

The A/B tool is described as an experiment on live payments. The provider’s language about low disruption should be read in that context: the test changes the route taken by the allocated traffic. Comparisons are most informative when the team understands which country group, provider order and authentication configuration differ between the variants. The published controls support iterative migration; they do not constitute a guaranteed improvement in approval rates.[18]

The public enquiry route does not specify a universal support timetable or incident SLA. Escalation responsibilities belong in the service agreement, particularly when an issue involves both orchestration and a connected provider.[1]

Magic Search adds a practical investigation tool to the dashboard. BridgerPay describes searches using customer information, transaction and merchant-order identifiers, provider order IDs, card last-four digits and decline reasons or codes. Partial and case-insensitive searches can be combined with filters. This helps the payment team connect a customer’s report to the relevant record without relying on one exact identifier. It remains important to distinguish an order from the individual attempts associated with it when tracing a retry or a provider-specific decline.[12]

The documented role is payment orchestration. Its routing and reporting tools do not establish an acquiring permission or guarantee a financial provider’s acceptance of every business and country. A broker still needs the specific provider arrangement that supports its funding and payout use case.[9]

The published prohibited-business policy includes illegal investment schemes and certain unlawful financial activity. Restricted businesses require prior written compliance approval; the list is not exhaustive. These rules should not be read as a blanket declaration that every FX brokerage is either accepted or prohibited.[8]

BridgerPay states PCI DSS Level 1 compliance and describes annual audits, quarterly scans, TLS 1.3, AES-256 encryption and role-based access. It identifies Google Cloud as its hosting infrastructure and describes a cloud-based operation rather than an on-premises deployment. Those statements concern payment-data security and infrastructure. PCI status is not a financial-services licence, and the public description does not replace the scope of the current assurance documentation or the customer’s own integration responsibilities.[7]

The privacy policy covers website, merchant and checkout information. It says personal data may be retained for up to three years after the relationship ends, with longer retention where required or permitted by law, followed by deletion or anonymization. A request to delete data therefore does not imply immediate removal of every payment or compliance record.[8]

The company describes the product as emerging from the difficulty of managing cross-border payments through separate providers. Its stated model is provider-agnostic orchestration: one place to connect payment options and control their operation. That background helps explain the emphasis on configurable routes, consolidated information and reconciliation rather than a single proprietary payment method. The current public offer spans several merchant sectors, with a specific financial-institution proposition alongside broader commerce uses.[11]

BridgerPay’s September 2026 announcement identifies Ran Cohen as co-founder and chief executive and describes the unveiling of Bridger AI at its Connect Plus event on 9 September. The announcement expanded the product story from payment operations toward specialist AI assistance. Its significance is a change in product direction, while the current availability labels on the product page remain important for understanding which parts are actually offered now.[14]

Operator

Bridger AI Limited

Service scope

Payment orchestration, checkout, routing, retries, payout operations and reconciliation across connected payment providers.

Customer types

Financial institutions; FX brokers with supported payment-provider arrangements; Fintech firms; Online merchants

Delivery

SaaS; API; Hosted

Pricing publication

Not disclosed

Platforms

Bridger OS; Bridger Retry; Bridger AI

Integrations

RedAcre; YourPropTrading; Saphyte

Pricing scope

No numerical orchestration tariff established; a separate Subscription Agreement governs the service.

Implementation

Configure provider connections, checkout methods and routes; weighted live-traffic tests support staged changes.

Support

Public demo/enquiry route and dashboard investigation tools; a universal service-response commitment is not published.

Permissions and regulatory scope

Payment orchestration is the documented role. PCI assurance concerns data security; acquiring, merchant acceptance and settlement arrangements remain provider-specific.

Provider metadata checked 20 Oct 2026Source 8Source 9Source 4Source 18Source 1Source 7

Kanji turns transaction and provider context into answers for payment teams, including country performance, approval or decline patterns and provider selection, according to BridgerPay. This is a decision-support role. The suite announcement does not establish that every specialist can alter live routes or run operations for every customer. Account-level access remains distinct from an announced capability, and the product page retains coming-soon labels for the other four specialists.[15][14][6]

Reconciliation extends beyond checking whether the initial payment was approved. BridgerPay describes importing provider settlement files, comparing them with its transaction records and flagging missing or mismatched amounts. Its calendar presents expected net receipts after provider fees and commissions, with provider-level detail and data available through an API. That makes it useful for payment operations and cash forecasting. A calendar amount or matched report is still a different piece of evidence from a receipt appearing in the broker’s bank account.[5]