PSP software: the platform a payment service provider runs on, licensed instead of built
PSP software is everything a licensed payment service provider needs between its merchants and its acquirers: the gateway and checkout the merchants integrate, the vault and the routing that decide where a payment goes, the cabinets the merchants and the operations team use, and the ledger that finance settles against. Tranzify licenses that platform to PSPs, so that the licence, the contracts and the money stay with the PSP and the engineering does not.
The modules
| Module | What the PSP gets |
|---|---|
| Gateway API | one REST contract for cards, local methods, Open Banking, crypto and payouts; signed webhooks |
| Hosted checkout | a payment page in 29 languages under the PSP’s brand, with 3-D Secure, wallets and local methods |
| Card vault | tokens that work across acquirers; recurring and one-click payments |
| Orchestration | routing by country, BIN, amount and method; cascading on declines; limits and restrictions |
| Alternative methods | the catalogue of local methods and Open Banking providers, enabled per network |
| Payouts | single and mass payouts on local rails, with balances and limits |
| Cabinets | the merchant cabinet and the admin panel: merchants, terminals, fees, users, roles, audit |
| Finance | balances per merchant and currency, fees, rolling reserve, settlement requests, reports |
| Operations | a trace per payment, webhook resend, support tickets, notifications |
| White-label | a network per brand or partner, isolated down to the database row |
A PSP’s day on the platform
Sales signs a merchant and onboarding creates it in the admin panel with its documents, fees and limits; the merchant opens its cabinet under the PSP’s brand, takes its keys and goes live on the hosted checkout the same day. Operations watches approval rates per terminal, moves a weight in the flow builder when an acquirer slows down, and activates the version; support opens a payment’s trace when a merchant asks and resends the webhook; risk limits a merchant whose chargebacks rise; finance approves the settlement requests against the ledger and exports the day. No ticket to a developer in any of it.
Build or license
Building the stack takes a team of engineers a year before the first merchant pays, and the integrations never end: every provider changes its API, every scheme its rules. Licensing moves that work to a vendor whose only product is the platform; the PSP’s engineers work on what differentiates it. The build-versus-buy page has the comparison in detail, module by module.
What a PSP should look at
- The catalogue in its markets: the local methods, the Open Banking providers and the acquirers, with their status, and the time to add one that is missing.
- The routing: whether the operations team can read and change the rules without a release, and whether every change is versioned.
- The ledger: balances per currency, fee rules that match the acquirers’ contracts, reserves, settlements, reconciliation with the providers’ statements.
- The journals: how long every attempt is kept, and whether support can open a payment’s whole chain.
- The deployment: where the platform can run, who holds the keys, how the data leaves.
Migration
A PSP rarely starts from zero. Tranzify runs side by side with the previous platform while merchants move one by one, and imports payment history for reports. Merchants on the hosted checkout change a link; API merchants map their flow in the sandbox and switch keys when their tests pass. The migration page describes the path and the checklist.
Deployment
In the Tranzify cloud or in the PSP’s own AWS account, with the same images and the same release process. Journals of every payment are kept five years and logs ten; the data belongs to the PSP.
Updated: 2026-11-08