Primer

Service Overview

Primer is a payment infrastructure provider headquartered in the United Kingdom. Its official positioning is "AI-powered unified payment infrastructure" with the line "Every payment moving in sync". It does not manufacture acquiring capability; it pulls the acquirers, fraud tools, 3DS and reconciliation systems a merchant already uses into one unified layer.

The three product lines are clearly drawn. Payments covers the acceptance path, Revenue covers whether the money actually ties out, and Platform covers operating observability. Together the goal is not "add one more payment method" but "run several payment methods at once and still reconcile them cleanly".

The team make-up explains the product's orientation. Core members came from Braintree, PayPal, Stripe, Adyen and Klarna, which collectively represent gateways, wallets, API-first infrastructure, global acquiring and buy-now-pay-later. Primer's structure is essentially an overlay of those experiences.

On coverage, the official site states that Primer for Partners provides 500+ connections spanning acquirers, alternative payment methods and fraud providers. Its compliance position is PCI-1, GDPR and SOC 2 Type-2 with 7x24 incident response — for a business that runs around the clock, the response commitment matters more in practice than the certification list.

The customer mix spans ecommerce, travel, gaming, fintech, digital content and iGaming: Printify, Lime, Cleeng, GetYourGuide, Airalo, loveholidays, New Look and Maisons du Monde sit across several verticals, while Checkout.com and dLocal appear as partner customers. That spread says it is building a horizontal layer rather than going deep in one vertical.

Key Strengths

• Payment operations treated as a first-class citizen: Fallbacks, Observability, Cost Insights and Reconciliation together assume you already run multiple providers and need to reconcile them properly. Most orchestrators treat operations tooling as a side feature; Primer puts it on the same layer.
• Failover is built in, not bolted on: Fallbacks automatically reroute a transaction to the next rail after the first declines it. For authorization-sensitive businesses this lands as revenue gained rather than cost saved.
• Network tokenization lowers the cost of switching rails: with Network Tokenization the card credential exists as a network token, so changing acquirers or adding rails does not force customers to re-enter cards, and renewals and repeat purchases continue uninterrupted.
• Reconciliation and cost insight sit in one product line: Reconciliation and Cost Insights both belong to Revenue, so "which rail is cheaper for this transaction" and "does the ledger tie out" are answered from one dataset instead of two spreadsheets that have to be cross-checked.
• Observability reaches the single-transaction level: Observability and Monitors remove the black box from payment failures and show exactly which step a transaction dropped at. The most expensive part of payment troubleshooting is time, and this layer converts it into headcount saved.
• 500+ connections and a two-way ecosystem position: partners provide 500+ connections according to the official site, and acquirers such as Checkout.com and dLocal also appear as partner customers, which means it is a layer acquirers accept rather than a competitor taking merchants away from them.

Product Ecosystem

Payments

Payments is the acceptance backbone, covering Checkout, 3D Secure, Fallbacks and Network Tokenization. The checkout component can be fully hosted or consumed only through backend APIs, letting an existing front end keep its own interaction design.

Revenue

Revenue answers whether the money ties out. Reconciliation consolidates flows from different providers, settlement cycles and currencies into one ledger view; Global Accounts manages multi-country accounts and balances; Cost Insights allocates the real cost of each rail down to the transaction level. All three assume the merchant already runs multiple providers.

Platform

Platform is the operations workbench. Workflows orchestrates operational actions, Monitors watches the key metrics, Observability provides single-transaction tracing, and AI Companion acts as an assistant for querying and troubleshooting. Apps and integrations connect external systems into the same layer.

Integrations and Developer API

An API plus webhooks, with checkout available hosted or componentized and native SDKs for iOS and Android. For a merchant retrofitting an existing checkout, starting with only failover and tokenization and moving reconciliation over later reduces the risk of a single big-bang change.

Limitations

• Meaningless without 2+ providers: multi-rail is the premise. A merchant with one acquirer pays orchestration-layer money for failover capability it cannot use.
• Opaque pricing: no standard rate card is published and pricing is negotiated on volume and module mix. Small and mid-size teams struggle to model total cost, and comparing across orchestrators is difficult.
• Cannot replace finance definitions: however good the reconciliation tooling is, accounting policy, revenue recognition and tax treatment remain with the merchant. Tooling guarantees data consistency, not compliant bookkeeping.
• Integration needs a dedicated owner: checkout changes, token migration, decline-code mapping and routing strategy tuning all need someone who understands payments; the business side cannot complete this alone.
• Not applicable to mainland China: domestic CNY acquiring and local clearing are out of scope, so mainland entities should be excluded outright.
• APAC depth must be verified per market: public customers and case studies skew to Europe and North America, so local method coverage, local teams and response times need checking market by market rather than assumed globally.

Use Cases

• Ecommerce running multiple acquirers (★★★★★): merchants already contracted with 2+ acquirers that need to split traffic by region or payment method; Payments and Revenue map directly onto routing and reconciliation.
• Travel and mobility (★★★★☆): high-ticket, multi-currency businesses with frequent refunds and changes, where failover and reconciliation address real operational complexity.
• iGaming and digital content (★★★★☆): extremely sensitive to authorization rates and payment success, and needing local payment methods per market, so a success-rate difference converts straight into revenue.
• Subscriptions and SaaS (★★★★☆): network tokenization keeps renewals running through rail changes, and cost insight makes each rail's real cost visible, which suits subscription-heavy businesses.
• Mainland China domestic acquiring (★☆☆☆☆): domestic CNY acquiring and clearing are out of scope; this is a hard limit rather than a roadmap gap.
• Early teams with 1 provider (☆☆☆☆☆): the worst fit. You get none of the orchestration benefit yet carry integration and subscription cost, so start with the acquirer's native capabilities.

Pricing

There are 5 main cost drivers:

• Transaction volume and ticket count — larger scale means more negotiating room
• How many acquirers and payment methods are connected
• Whether Revenue reconciliation and cost insight modules are enabled
• Complexity of settlement currencies and cross-border paths
• Whether custom checkout UI and localized payment methods are required

The table contains no rate figures because Primer does not publish a standard price list. Actual pricing follows the current official quote and your contract; request platform, transaction and module fees separately when scoping.

FAQ

• Does Primer acquire payments itself?
  No. It is a unified infrastructure layer, and acquiring stays with the acquirers you contract. Its value is consolidating multiple acquirers, 3DS, fraud and reconciliation into one layer so switching and failover do not require rewriting systems.

• Is it worth it with only one acquirer?
  No. Its core capability is choosing between rails and reconciling them, neither of which a single-rail merchant needs, while subscription and integration costs become pure overhead. Re-evaluate around the time a second acquirer goes live.

• Does failover increase cost?
  It adds a cost line but is not necessarily net cost. Failover means some transactions move to a more expensive rail, but in exchange transactions that would have failed outright are recovered. Measure the net effect against your own authorization baseline rather than industry averages.

• Does network tokenization require customers to re-enter cards?
  The first conversion of a card into a network token needs one interaction; afterwards a new acquirer or additional rail can use the existing token and the customer notices nothing. That is exactly why it matters most for subscriptions.

• Can a mainland China company use it?
  Domestic CNY acquiring and local clearing are out of scope, so mainland entities cannot. An offshore entity serving customers in Europe, North America or Southeast Asia can evaluate it, but actual local method coverage must be verified per target market.

Source: original 16IDC content. Product capabilities, supported countries and fee definitions follow the official documentation and your contract.