Payments API Capability Snapshot (v0.1)
A segment-aware overview of how payment APIs differ in structure, access, and intent.
This is an early snapshot of payment API capabilities, focused on the core infrastructure that powers global payments. This report covers card schemes (Visa, Mastercard), PSP/processors (Stripe), networks/infrastructure (SWIFT), and cross-border/account platforms (Wise, Currencycloud, Airwallex, Modulr, Banking Circle, Nium).
This snapshot uses the same segment-specific tier methodology documented in our Methodology page.
Scope of this snapshot
- •10 providers across card schemes, PSPs, networks, and cross-border platforms
- •Focus on sandbox availability, key capabilities, and category-specific features
- •Not yet covered: Open banking APIs, BaaS providers, banking APIs, identity/KYC services, regional payment rails
Capability overview
Segment Legend
| Provider | Category | Tier | Sandbox | Segment |
|---|---|---|---|---|
| Visa | Card Scheme | Tier C0 | ✅ Free with registration, mock data | Card scheme APIs |
| Mastercard | Card Scheme | Tier C0 | ✅ Free with registration, synthetic data | Card scheme APIs |
| Stripe | PSP / Processor | Tier P0 | ✅ Test mode + great DX | PSP / processor APIs |
| SWIFT | Network / Infrastructure | Tier I2 | ⚠ Contract-based access; no open public sandbox | Network infrastructure |
| Wise | Cross-Border Transfers / Multi-Currency Accounts | Tier X1 | ✅ Yes — mock/simulation environment | Cross-border / FX APIs |
| Currencycloud | FX / Multi-Currency / Payments | Tier X1 | ✅ Demo environment | Cross-border / FX APIs |
| Airwallex | Accounts / Payments / FX / Issuing | Tier X1 | ✅ Full API sandbox | Cross-border / FX APIs |
| Modulr | Embedded Accounts / Payments / Cards | Tier B0 | ⚠ Test environment (account required) | Banking infrastructure |
| Banking Circle | Banking & Payments Infrastructure | Tier B0 | ⚠ Test environment (requires onboarding) | Banking infrastructure |
| Nium | Payments / FX / Wallets / Compliance | Tier X1 | ⚠ Test environment (after registration) | Cross-border / FX APIs |
Note: Tiers are segment-specific (C0, P0, X1, I2, B0) and are not comparable across segments. See the Methodology page for full definitions.
Key observations
Most providers focus on transactional APIs. Nine out of ten providers in this snapshot offer transactional APIs (payments, payouts, FX, accounts) rather than infrastructure-grade reference data. This reflects their core use cases and segment focus rather than a capability gap.
Network infrastructure providers expose reference data.Network-level infrastructure providers like SWIFT are more likely to expose directory, validation, and tracking APIs. PSPs and cross-border platforms typically keep routing intelligence internal to their platforms.
Sandboxes are broadly available with varying depth.Sandboxes are widely available across card schemes, PSPs, and FX platforms, but the depth and realism of test data varies. Some use synthetic data; others offer full API sandboxes.
Infrastructure providers gate access behind contracts.Banking and network infrastructure providers (SWIFT, Modulr, Banking Circle, Nium) are more likely to require contracts or onboarding before granting test access, unlike card schemes and some PSPs which offer open registration.
Category-specific capabilities drive API design.Card schemes excel at payments and fraud APIs; cross-border platforms focus on FX and multi-currency accounts; infrastructure providers offer reference data and validation. Each category serves different needs.
Key patterns
Pattern #1 — Metadata lives at the network layer
Only infrastructure providers expose validation, directory, and routing metadata. PSPs don't — and it's not a limitation; it's their architectural model. When you need BIC directories, IBAN validation, or payment tracking, look to network infrastructure providers, not transactional platforms.
Pattern #2 — Sandboxes correlate with business model
Open, free sandboxes often appear in consumer-facing PSPs and card schemes. Contract-gated sandboxes often appear in infrastructure or banking providers. This reflects their target customers: developers vs. enterprises. Plan your evaluation timeline accordingly.
What this means for your decision-making
When choosing between these providers, the key takeaway is not who is "better", but which segment they belong to. PSPs optimise for transactions; infrastructure providers optimise for metadata and validation; cross-border platforms optimise for FX and wallets.
Use this snapshot to understand which category matches the problem you're solving, not to rank providers across categories. A Tier C0 card scheme and a Tier P0 PSP serve different purposes — comparing them directly misses the point of their architectural differences.
What's next
This snapshot represents v0.1 of API Radar's coverage. Future updates will expand to:
- Open banking APIs (PSD2, Open Banking UK, TrueLayer, Yapily)
- Banking-as-a-Service (BaaS) providers
- Banking APIs and core banking infrastructure
- Identity and KYC/AML APIs
- Regional payment rails and local schemes
- Deeper scoring on developer experience, documentation quality, and API latency
Future snapshots will include Open Banking, BaaS, and KYC providers to broaden cross-category comparability.
This series will grow to provide comprehensive ecosystem intelligence — like a research publication.
For detailed provider information, see our Coverage page. For methodology details, see our Methodology page.