Use Cases¶

Fintech issuing UnionPay debit cards¶

A Brazilian fintech wants to offer a UnionPay debit card to its customers. They have no existing relationship with UnionPay, no HSM infrastructure, and no experience with ISO 8583.

Without QPay, they would need to negotiate directly with UnionPay for a BIN range, build or license an ISO 8583 authorization engine, deploy HSM infrastructure for cryptographic operations, integrate with one or more card bureaus, and staff a team with payment network expertise.

With QPay, the fintech becomes an issuer tenant under an existing QPay processor. They integrate the Issuer API — a REST API they can explore in the sandbox in an afternoon. They define card products using templates their processor already has approved with UnionPay. When a customer requests a card, the fintech calls POST /issuer/cards/create. QPay handles the rest: BIN assignment, embosser routing, and authorization processing when the card is used.

Time to first card: days, not months.

Bank becoming an issuer processor¶

A mid-size Brazilian bank wants to offer issuer processing services to fintech clients — acting as the intermediary between fintechs and the UnionPay network.

With QPay Processor Core, the bank registers its homologated BINs and configures data preparation templates via API. Each fintech client is onboarded as an issuer tenant under the bank's processor tenant. The bank manages the UnionPay relationship; QPay handles the ISO 8583 protocol, real-time authorization routing, and cryptographic validation for every transaction.

The bank's fintechs integrate only the Issuer API — they have no visibility into the network layer. When a cardholder swipes at a terminal, QPay receives the authorization request from UnionPay, looks up the card, validates the transaction cryptogram, and calls the issuer's callback to get an approval or decline decision.

Result: The bank enters the issuer processing market without building a network gateway from scratch.

Card personalization bureau joining the network¶

A card personalization bureau wants to service QPay issuers without building bilateral integrations with each one.

With QPay, the bureau is registered as an embosser tenant. Issuers configure their card products to route production jobs to this embosser. When an issuer creates a card, QPay places a job in the embosser's queue automatically.

The bureau polls GET /embosser/pending-embossing on a schedule to fetch pending jobs, personalizes the cards in their facility, and calls POST /embosser/update-cards to report success or failure per card. The bureau has no direct technical relationship with any individual issuer — QPay is the single integration point.

Result: One integration, access to all QPay issuers that choose the bureau.