When a company starts selling online, the flow looks simple: order in, payment in, money in. But as the business grows, reality shifts — multiple payment methods, multiple banks, multiple providers, different fees, settlements on different dates, reports scattered across isolated dashboards. This is where a payment hub comes in: a single layer that centralizes cards, bank rails, PIX, LATAM methods, and crypto into one platform with a consolidated dashboard and unified API.
A payment hub is the central platform that connects multiple payment methods (cards, PIX, boleto, LATAM rails, crypto) and multiple providers (acquirers, sub-acquirers, banks) through a single API, with a unified dashboard for management and operations. Unlike a gateway (which connects to one provider) or an orchestrator (which routes across N providers of the same method), a hub groups all of a business’s financial infrastructure into a single integration layer.
In other words: a payment hub is the natural evolution when you realize that maintaining separate integrations for cards, PIX, and crypto (each with its own dashboard, webhook, and reconciliation) is costing more engineering and ops time than it delivers in value.
Imagine a typical operation with a Brazilian mix: 50% PIX, 40% card, 10% boleto. Without a hub, you have:
With a hub, you have a single API that exposes all 3 methods through consistent endpoints (/v2/charges with a method parameter). One dashboard showing the full picture. One webhook with a standardized payload. Consolidated reconciliation. A single SLA. And fees negotiated against the combined volume of all methods — which is almost always better than buying each method separately.
| Layer | Scope | Practical example |
|---|---|---|
| Gateway | 1 method, 1 provider | PIX API from a single bank |
| Orchestrator | 1 method, N providers | Card routing across 3 acquirers |
| Payment hub | N methods, N providers | PIX + Card + LATAM + Crypto, all orchestrated |
The ideal architecture for a mature operation is a hub and orchestrator on the same platform. That’s what BSPay delivers: a hub (multiple methods) with an orchestrator underneath each method (multiple providers per method). Result: one integration, full coverage, maximum redundancy.
A common objection: “I already have a card gateway and a PIX gateway — do I really need a hub?” Numbers usually answer. Consider an operation billing R$1M/month across 3 methods with 3 separate providers:
Migrating to a hub typically drops the average fee to 3.0-3.3% (0.9-1.2 percentage points saved = R$9-12k/month), cuts engineering maintenance in half, and adds automatic failover. The hub literally pays for itself — and it does so while freeing up the team.
BSPay is a payment hub built for digital businesses at scale. It covers PIX, cards (Visa, Mastercard, Amex, Elo, Hipercard), boleto, LATAM rails (SPEI Mexico, PSE Colombia, Khipu Chile, PagoEfectivo Peru), and crypto settlement (USDT, USDC) — all on the same REST API, the same dashboard, the same standardized webhook. Underneath, each method is multi-provider orchestrated for redundancy and aggregate fee negotiation.
Fees from 2.99% negotiable against the combined volume of all 5 methods. More than 30,000 active companies process on the platform today. Dedicated technical support via 24/7 WhatsApp group, a migration team that handles the move from any current stack, and zero contractual lock-in. See every feature on the home or talk to a specialist.
A gateway connects one method to one provider (e.g., the PIX API of a single bank). A hub connects multiple methods (PIX + card + boleto + crypto) to multiple providers for each — through a unified API. A hub is the natural evolution of a gateway when the operation has a mix of methods and meaningful volume.
Usually not. A hub negotiates fees against the combined volume of every method, which almost always beats the fees of each method bought separately. On top of that, the operational cost of maintaining N separate integrations (engineering, reconciliation, internal support) outweighs any price difference.
It works, but the real benefit shows up at scale. For operations under R$50k/month with a single method, a simple gateway is enough. Above R$100-300k/month with a mix of methods, a hub starts to pay for itself in operational savings.
Usually phased: migrate the lowest-volume method first (to validate), then the main methods. Each method takes 3-7 days of integration work. During the transition, the hub and the old gateways coexist. Typical full migration: 3-4 weeks.
Professional hubs come with native anti-fraud or plug-and-play integrations with external solutions (Signifyd, ClearSale, Kount, Sift). The differentiator is cross-method scoring: the hub spots when a customer tries to pay by card, gets declined, and switches to PIX minutes later — a common fraud pattern that isolated gateways simply don’t see.
Yes, especially well. Marketplaces need native split across every method (not just card); a hub delivers it. Digital product creators need recurring PIX, card, and crypto for international sales; a hub delivers everything through a single API.
Yes. You activate only the methods your operation actually needs. There’s no point enabling crypto if you only sell in Brazil — and no need to enable boleto if your audience is 100% digitally native. The admin panel controls method-by-method visibility.
No. The hub acts as your single contractual counterparty. It manages relationships with underlying acquirers, banks, and crypto off-ramp providers. You sign one master agreement and get access to the whole ecosystem — including future providers added to the hub without any new contract on your side.
