Why QPay¶
Launching a payment card product in Brazil is a multi-year effort for most organizations. Before the first card reaches a cardholder, you need to integrate with a card network's binary ISO 8583 protocol, achieve PCI-DSS compliance for card data at rest and in transit, build integrations with card personalization bureaus, and manage a web of multi-party agreements — all before generating a single transaction.
QPay was built to remove those barriers.
The problem¶
| Without QPay | With QPay |
|---|---|
| Direct ISO 8583 integration with the card network | REST API — no protocol knowledge required |
| Full PCI-DSS scope for card data storage | Reduced scope — QPay stores encrypted card data |
| Custom embosser integrations per bureau | Single Embosser API, multi-bureau routing |
| Months of network homologation work | BIN registration via API |
| Bespoke multi-party contracts and flows | Processor → Issuer → Embosser modeled in the platform |
Who it is for¶
QPay serves three types of organizations in the payment card ecosystem:
- Issuers — fintechs, banks, or any entity that wants to issue UnionPay cards to cardholders
- Processors — organizations that want to provide issuer processing services to other issuers, managing the card network relationship on their behalf
- Embossers — card personalization bureaus that physically produce and deliver cards
Each role gets a purpose-built API surface and an isolated tenant within the platform.
-
Features
Explore the specific capabilities QPay provides for each role in the ecosystem.
-
Use Cases
See how issuers, processors, and embossers use QPay in practice.