The problem
A bank’s processing handles cards well and nothing else; adding Open Banking, wallets, local methods or a modern checkout means a project per method and a merchant cabinet that never got built. Merchants compare the bank’s offer with payment companies that give them a checkout in their language, tokens for subscriptions and a cabinet with reports, and the bank’s acquiring team answers with a PDF and an integration guide from years ago. The core is sound; the layer merchants see is missing.
What Tranzify adds
- A hosted checkout in 29 languages with cards, 3-D Secure, Apple Pay and Google Pay, Open Banking and local methods on one page, under the bank’s brand or a partner’s.
- A card vault with tokens for recurring payments, routed to your processing or to partner acquirers by rule, so a stored card works wherever the routing sends it.
- Every alternative method in the catalogue through one integration: the bank enables a provider, enters its account and writes a rule.
- Routing and cascading between your own terminals and partners, with limits and restrictions, versions and rollback.
- A merchant cabinet, reports, balances and settlements under your brand; partner networks under theirs.
- The journal of every payment for five years and the trace that support and audit open.
How the pieces fit
| Layer | Who provides it |
|---|---|
| Merchant agreements, settlement, risk | The bank, as today |
| Card processing and the acquiring licence | The bank’s core, connected as a terminal |
| Checkout, vault and tokens, 3-D Secure flow | Tranzify |
| Local methods, Open Banking, crypto rails | Providers in the catalogue, under the bank’s accounts |
| Routing between the core and partners | Tranzify, with the bank’s rules |
| Merchant cabinet, back office, reports | Tranzify, under the bank’s brand |
What stays yours
The licence, the merchants, the settlement, the risk and compliance decisions, the processing itself. Tranzify is the software layer; your teams operate it through the back office, and your security team can run it inside your own cloud account with your keys and your network rules.
For banks with partners
An acquirer that serves PSPs, ISOs and large merchants gives each a network: its own domain, brand, cabinet and checkout, with the bank’s terminals or the partner’s own. The bank’s operations team sees every network it is allowed to see from one admin panel; the partner sees only its own. Fees per network show the bank’s margin on each partner in the ledger.
How it starts
A connection to your processing in its test environment, a network under your domain, the checkout with your merchant identifiers for Apple Pay and Google Pay, the first merchant on the hosted page; then local methods and Open Banking as the bank signs with providers. Each step is a configuration, not a project.