Payment Gateway vs Payment Orchestration vs Core Fintech Software: How to Choose (2026)

Payment gateway

A gateway is the technical connection between where a payment is initiated — a checkout page, an app, a terminal or an API call — and the processor or acquirer that authorises it. It collects payment details securely, formats and sends authorisation requests, returns results, and usually offers refunds, captures and reporting. If it handles card data, it is in scope of the PCI Data Security Standard. A white-label gateway lets a business offer this to its own merchants under its own brand.

Payment orchestration

Orchestration sits one level up. It connects to several gateways, PSPs and alternative payment methods through one integration and decides where each transaction goes, using rules based on cost, country, card type or provider availability. Typical features include provider-agnostic token vaults, retries and fallbacks when a provider fails, fraud and 3-D Secure hooks, and consolidated reconciliation. Orchestration is mainly a merchant- or PSP-side tool for resilience, coverage and cost control.

Core fintech software

Core fintech software runs a financial product for end customers: onboarding and KYC/KYB, customer profiles, multi-currency accounts with an internal ledger, transfers, FX, card management, sometimes crypto wallets and exchange, plus AML workflows, transaction monitoring, CRM and back-office administration. It is closer to what a neobank or e-money business operates than to a checkout tool.

None of these categories is itself a regulated institution. In the EU, PSD2 Annex I lists regulated payment services, including the execution of payment transactions and the acquiring of payment transactions(Directive (EU) 2015/2366). Running gateway or orchestration code does not authorise you to provide those services. Likewise, core software that displays an IBAN or a card balance relies on a bank or EMI that actually holds the account and on an issuer that is a member of the card scheme or sponsored by one. Crypto custody and exchange in the EU need MiCA authorisation where in scope.

You can verify a European partner's status on the EBA register. In Switzerland, a payment business that is AML-supervised through an SRO (FINMA: SROs) still needs regulated banking and payment providers for accounts, cards and settlement.

You want to serve merchants (acquiring-side business)

You need a gateway with merchant onboarding, checkout, refunds and reporting, plus one or more acquirers or PSPs to process and settle. Orchestration becomes valuable once you have several acquirers, sell across regions or need resilience. Your regulated dependency is the acquirer.

You want to serve end customers (accounts, cards, crypto)

You need core fintech software and regulated partners for accounts, issuing and, where relevant, custody. A gateway may be added later for pay-ins. Your main work is onboarding, ledger accuracy, AML monitoring and customer support.

You are buying a payment company

Start from the business model the entity is approved for and the providers it can actually use, then choose software to match. A Swiss payment company for sale with a fiat-and-crypto business model points towards core fintech software; a merchant-services strategy points towards a gateway and, later, orchestration. Buying an entity and licensing software are separate contracts with separate risks.

The products below show how vendors position themselves. Descriptions summarise each vendor's own website as accessed on 11 October 2026. They are vendor claims, not independent tests, and no product is presented as better than another.

• Spreedly (unaffiliated) describes itself as a payments orchestration platform with modules for connecting payment methods, a vault for stored credentials and token portability, workflow-driven routing optimisation, and fraud and 3-D Secure tooling.
• Primer (unaffiliated) describes checkout, a centralised vault, no-code payment workflows, network tokenisation, fallbacks to secondary processors, 3-D Secure, observability and reconciliation across providers.
• SAMFPay (affiliated) is described by its vendor as standalone payment gateway and orchestration software, separate from and independently licensed from SAMFCore, covering pay-in, orchestration and payout workflows under the licensee's brand, with configurable provider priorities, fee rules and approval workflows within an agreed scope. The vendor page describes a proposed perpetual licence with optional source code where authorised, and states that commercial availability, white-label and licensing rights are subject to final contractual authorisation. It is software, not an acquirer.
• SAMFCore (affiliated) is described by its vendor as a modular platform for onboarding and KYC/KYB, multi-currency accounts and internal ledger, payments through selected banking-provider connections, card management through issuing-provider connections, crypto wallets through custody connections, AML workflows and transaction monitoring, CRM and back office. It is software connected to providers the customer selects; it is not a bank, EMI or card issuer.

Most gateway and orchestration products are offered as hosted services: the vendor runs the infrastructure, carries much of the PCI scope for the vault and charges ongoing fees. Some vendors license software you deploy yourself, and a few offer source-code access. Owning or licensing code gives control over roadmap, data location and vendor exit, but moves hosting, security testing, upgrades, incident response and compliance evidence to your team.

• Hosted: faster integration, shared security responsibility, recurring fees, less control over roadmap and data residency.
• Licensed deployment: more control and possibly lower variable cost, but you operate it; PCI and security obligations increase.
• Source code: only valuable if you have engineers to maintain it; check exactly what is delivered, escrow terms and IP ownership.

Draw the funds flow before choosing software. In card acquiring, the acquirer receives scheme settlement and pays the merchant, net of fees; the gateway reports it. With orchestration, each underlying PSP settles separately, so reconciliation across providers becomes a core requirement. In a customer-account model, the bank or EMI holds funds and your ledger must reconcile to its statements every day. If your company would ever hold merchant or customer money itself, that is a legal question — safeguarding in the EEA, deposit-taking rules in Switzerland — not a software setting.

We do not publish or compare vendor prices. Use this matrix to collect comparable quotes and internal estimates.

1. Write down which regulated partner provides each service (acquiring, accounts, issuing, custody) and confirm the software has a working, maintained integration with it.
2. Ask for a live demonstration on test data of the exact flows you need, including refunds, chargebacks or returns, and failure handling.
3. Get the licence in writing: scope, term, territories, white-label rights, IP ownership, and precisely what source code (if any) is delivered and when.
4. Review security evidence: PCI DSS status where card data is handled, recent penetration tests, encryption and key management.
5. Check ledger design: double-entry, reconciliation against partner statements, audit trail and reporting exports.
6. Confirm AML/KYC tooling and how it maps to your obligations and your SRO or regulator's expectations.
7. Clarify hosting, data residency, uptime responsibilities, support hours and escalation.
8. Plan the exit: data and token export, notice periods and transition assistance.

For the corporate and regulatory side of a transaction, combine this with the acquisition checklist.