The problem
A payment company integrates provider after provider: each with its own API, statuses, callbacks and quirks. Every new market means weeks of work, and a decline at one provider is a lost payment unless someone built a fallback. Volumes grow, and the rules that decide where a payment goes live in code, in a spreadsheet and in the head of the person who wrote them. When an acquirer raises its fees, lowers its approval rate or goes down for an hour, moving traffic takes a release.
Orchestration turns that into configuration. Providers become adapters inside one platform; the decision about where a payment goes becomes a rule that operations can read, change and roll back; and a decline becomes the start of the next attempt instead of the end of the sale.
What Tranzify does
- One contract for every provider. The client’s merchants integrate once, through one API and one hosted checkout; acquirers, local methods, Open Banking providers, crypto providers and payout rails are adapters inside the platform with one set of statuses.
- Rules, not code. Conditions on amount, customer country, IP country, card country, scheme, BIN ranges and time windows; each path ends in a cascade of terminals with priorities and weights, so traffic can be split between two acquirers 70/30 or sent to a local provider for one country only.
- Cascading. A decline, a timeout or a provider’s error moves the payment to the next terminal automatically; what a terminal already accepted is never charged twice, and the payer does not see the attempts.
- Limits and restrictions. Per-terminal limits in a window (an amount per day, a count per hour), country and method restrictions, all evaluated before a provider is called, so a provider’s contractual caps are never exceeded by accident.
- A visual flow builder. Flow blocks, condition blocks and terminal blocks drawn on a canvas; the canvas and the rules are stored together as one version with an author and a date.
- Versions and rollback. A change is a new version; an administrator activates it, and the previous version stays. If approval rates drop after a change, the previous flow is back in one click.
How a payment finds its terminal
- The merchant creates a payment: amount, currency, method, customer, and the card’s BIN or the payer’s bank where the method has one.
- The platform evaluates the active flow of the merchant’s network from the top: each condition block tests the payment’s fields and sends it down one branch.
- The branch ends in a route group: an ordered list of terminals, each a provider account with its own currency, limits and fees, with a priority and a weight.
- The first terminal by priority and weight that passes its limits is called. On a decline, a timeout or an error, the next one is called, until a terminal accepts or the group is exhausted.
- Every step is written to the payment’s journal: the version of the flow, the branch taken, each terminal tried, the provider’s raw answer and the time it took. The payment trace in the back office shows the whole path.
| Condition | Examples |
|---|---|
| Amount | below 50, between 50 and 1 000, above 1 000 in the payment’s currency |
| Customer country, IP country, card country | the same or different, in a list, not in a list |
| Scheme and BIN range | Visa, Mastercard, UnionPay, Troy; a list of BIN ranges of one issuer or one card level |
| Method | card, a specific local method, Open Banking, crypto, payout |
| Time window | business hours of an acquirer, weekends, a maintenance window |
| Merchant and network | per merchant rules inside the shared flow of a network |
What the numbers look like
The saved payments are the ones a cascade recovers: a second acquirer that accepts what the first declined, a local provider that is up when the primary is down, a time window that keeps traffic away from an acquirer’s nightly maintenance. The reports count them per terminal, so the effect of every rule change is visible within days, not at the end of the month. The blog post on measuring cascade recovery describes the method.
Where it is used
Routing runs for cards, alternative methods, Open Banking, crypto and payouts alike, in every region of the catalogue: a PSP with three acquirers and a dozen local methods, an acquirer that sends foreign cards to a partner, a fintech that routes by country of the customer’s bank. The industries pages describe the typical flows for iGaming, forex, marketplaces and subscriptions; the catalogue of payment methods and the catalogue of providers show what each terminal can be.