Features¶

For Issuers¶

Card lifecycle management via REST API Issue, block, unblock, and monitor cards through a clean HTTP API. No ISO 8583 knowledge, no binary protocol parsing — just JSON.

Reduced PCI-DSS scope Card PANs and CVVs are stored encrypted by QPay using AES. Your systems never handle plaintext card data, significantly narrowing the scope of your PCI-DSS compliance assessment.

Flexible card product model A card product combines a card template (from your processor), a card layout (visual design sent to the embosser), and an embosser assignment. This model lets you run multiple card offerings — different designs, different bureaus — under the same integration.

Batch card issuance Issue hundreds of cards in a single API call using the batch endpoint. Monitor production status per card with a single batch ID.

Certificate-based HSM integration QPay uses your ECC P-256 issuer certificate to establish cryptographic trust for transaction authorization (ARQC/ARPC). PIN material is always encrypted before reaching the platform — your HSM stays in control.

A hosted ledger, if you want one Every card needs an account behind it. If you do not want to build a ledger, use QPay's: join it with one API call and you get double-entry accounting, per-currency fund segregation, cardholder checking accounts, and credit limits — without writing a ledger yourself. See QPay Ledger Core.

Credit card invoicing out of the box Billing cycles, statement closing, payment allocation, interest and late fees, and a set of read-only reconciliation controls that re-derive the ledger's own invariants. Configure the cycle per card product and QPay runs the jobs for you. See Credit Card Invoicing.

Bring your own ledger instead Already have a core banking or accounting system? Implement the Ledger Callback API and register your endpoints, TLS trust anchor, and HMAC signing secret. One field on your issuer record decides which ledger QPay calls, and it is reversible.

For Processors¶

Card network integration already built The UnionPay ISO 8583 authorization protocol is implemented inside QPay. Register your BINs and configure your card templates via API — the network communication layer is handled for you.

Multi-issuer tenancy Serve any number of issuer clients under a single processor integration. Each issuer gets an isolated tenant with its own users, products, and cards. You manage the relationship; QPay enforces the isolation.

Real-time authorization The QPay Processor Core runs an ISO 8583 TCP server (port 9999) that handles real-time card authorization. When a UnionPay transaction arrives, QPay looks up the card, validates cryptograms, and calls back to your issuer for the authorization decision.

BIN and template management Register BIN ranges and configure card templates per BIN via API. Issuers under your processor pick from the templates you expose to them.

For Embossers¶

Simple polling API No direct relationship with each issuer required. Poll GET /embosser/pending-embossing to retrieve jobs queued for your bureau, and call PUT /embosser/update-cards to report production outcomes.

QPay routes the work When an issuer creates a card assigned to your embosser, it appears in your queue automatically. The routing is configured at the product level — you receive the jobs without any bilateral integration per issuer.

Platform-wide¶

Standard OAuth2 authentication All APIs use JWT bearer tokens issued by a Keycloak-backed identity service. Client credentials (machine-to-machine) and user tokens are both supported. No proprietary auth scheme.

Tenant isolation at every layer Every database query, every API call is scoped to the authenticated tenant. Cross-tenant data access is not possible by design.

Sandbox environment A fully isolated sandbox at sandbox.qpay.quecto.com.br mirrors the production platform. Develop and test your integration before going live, with simulated embossing and authorization flows.

OpenAPI documentation Every API surface is documented with interactive Swagger UI panels — see the API Reference.