Infraestrutura de emissão multibandeira

Seu cartão no mercado. Sem reconstruir o mercado.

Emita, autorize e processe cartões Visa, Mastercard, Elo, UnionPay ou de marca própria em uma única plataforma. A QPay absorve a complexidade das bandeiras para sua equipe focar no produto.

Falar com o time Conhecer os modelos
✓ API REST ✓ BIN de teste ✓ Emissão + autorização + ledger
Mockup de um cartão QPay Platinum: chip, símbolo de aproximação, número mascarado terminando em 4417, nome do portador e validade.

Uma integração. As principais bandeiras.

Visa Mastercard Elo UnionPay Private label Arranjo fechado Visa Mastercard Elo UnionPay Private label Arranjo fechado
O problema

Lançar um cartão no Brasil é um projeto de anos

Antes do primeiro cartão chegar ao portador, é preciso se conectar a cada bandeira, entrar em escopo PCI-DSS, construir uma ponte por bureau de personalização e assinar contratos entre três ou quatro partes.

Conexão com as bandeiras
Sem a QPay: Uma conexão própria com cada bandeira, construída do zero
Com a QPay: API REST — a conexão com as bandeiras já é nossa
Dado de cartão e PCI
Sem a QPay: Escopo PCI-DSS completo para guardar dado de cartão
Com a QPay: Escopo reduzido — o PAN cifrado fica com a QPay
Embossing
Sem a QPay: Uma integração sob medida por embossadora
Com a QPay: Uma API de embossing, roteando para vários bureaus
Homologação e BIN
Sem a QPay: Meses de homologação com cada bandeira
Com a QPay: Registro de BIN pela própria API
Arranjo fechado
Sem a QPay: Construir emissão, autorização e liquidação por dentro
Com a QPay: A mesma plataforma, com bandeira ou sem nenhuma
Modelo operacional
Sem a QPay: Contratos e fluxos multipartes feitos à mão
Com a QPay: Processadora, emissor e embossadora modelados na plataforma
Para quem é

Três papéis, um tenant isolado para cada

01 · Produto financeiro

Emissores

Fintechs, bancos e varejo que querem colocar um cartão na mão do portador — nas principais bandeiras ou em arranjo fechado, de marca própria. Produto, BIN, regras de autorização, faturas e cartões — tudo por API e pelo console.

Fintech · Banco · Varejo
02 · Infraestrutura

Processadoras

Quem quer oferecer processamento a outros emissores, segurando a relação com a bandeira por eles — ou quem institui um arranjo fechado, em que a rede de aceitação é a que você credencia. Você administra os emissores abaixo de si, com os BINs e os templates que definir.

BIN Sponsor · Arranjo fechado
03 · Personalização

Embossadoras

Bureaus de personalização que produzem e entregam o plástico. Uma fila e um layout por emissor, na mesma API — sem uma ponte nova a cada cliente.

Fila · Layout · Produção
Modelos de negócio

Três formas de entrar, o mesmo processamento por baixo

O que muda entre eles é quem tem o BIN e quem responde pela relação com a bandeira. O que não muda é a plataforma: emissão, autorização, ledger, fatura e liquidação são os mesmos nos três.

Processadora BIN Sponsor

Você tem o BIN homologado e patrocina outras marcas para emitir embaixo dele. Vira a porta de entrada de quem não quer — ou ainda não pode — falar com a bandeira.

A bandeira conecta-se a você, que detém o BIN; de você saem várias emissoras afiliadas, cada uma com os seus próprios portadores.

Cada afiliada entra como um tenant isolado, com produtos, regras e faturas próprios — e você enxerga todas de cima.

Emissora full

Você tem o próprio BIN e responde direto à bandeira. Ninguém entre você e o portador, e nenhum custo de patrocínio no meio.

A bandeira conecta-se direto a você, que detém o BIN, e de você saem os portadores — sem ninguém no meio.

Na plataforma é um só tenant carregando os dois papéis: processa para si mesma e emite para os seus portadores.

Emissora afiliada

Você emite sob o BIN de uma processadora sponsor. Sem BIN próprio e sem homologação para esperar — o cartão sai com a sua marca do mesmo jeito.

A bandeira conecta-se à processadora sponsor, dona do BIN; dela vem você, a emissora afiliada, e de você saem os seus portadores.

É o caminho mais curto até o primeiro cartão — e o modelo não fica preso: dá para assumir o próprio BIN depois.

Em arranjo fechado, é o mesmo desenho sem o primeiro nó: não há bandeira para homologar, o BIN é seu e a rede de aceitação é a que você credencia. A plataforma se comporta igual — muda quem está na ponta de cima.

A plataforma

Da ideia ao cartão ativo, sem montar uma processadora do zero

Menos infraestrutura, mais produto. A QPay conecta emissão, autorização, ledger, faturas, segurança e operação de rede em uma camada única — pronta para você compor conforme o seu negócio.

Autorização em tempo real

Cada compra chega da bandeira, tem a segurança do chip conferida no HSM e volta respondida. Você vê o resultado, não a rede.

Ledger e faturas

Ciclos de faturamento, fechamento, pagamento, encargos, transferências entre contas e controles de conciliação — com contabilidade de partida dobrada por baixo.

Webhooks assinados

Eventos de cartão, fatura, transação e operação entregues ao seu endpoint, com assinatura, retentativa e trilha de entrega auditável.

Motor de regras

Regras de autorização por BIN, emissor ou cartão, com acesso aos campos EMV da própria transação. Escritas no console, avaliadas na hora.

Auditoria de rede

Cada mensagem que entrou e saiu da rede, campo a campo, mascarada — a resposta que a sua equipe precisa quando o portador liga.

Clearing e liquidação

Os arquivos de liquidação da rede processados e conciliados contra o que foi autorizado, com as diferenças apontadas.

HSM e criptografia

Validação de ARQC, geração de ARPC e verificação de PIN dentro do HSM — e os issuer scripts, como a troca de PIN no chip, saem selados pelo mesmo módulo, com a resposta do cartão registrada de volta. PAN e CVV cifrados em repouso, nunca em log.

App do portador

Saldo, extrato, fatura, bloqueio e, via parceiro de arranjo, área Pix e pagamento de contas. Tudo numa API voltada ao portador — pronta para o seu app, ou para o nosso.

Customização

Você escolhe onde a QPay entra

Nem toda operação quer a mesma coisa. Quem já tem embossadora não vai trocar; quem já tem motor de decisão não vai desligar. A plataforma abre nos pontos onde isso importa e assume o resto — e a escolha é por emissor, não por contrato.

Embossing

Traga a embossadora com quem você já trabalha, ou use uma das que já estão na plataforma.

O cartão criado na QPay segue por um de dois caminhos — a fila de uma embossadora já integrada à plataforma, ou a fila da embossadora do próprio cliente — e nos dois casos o plástico termina embalado, a caminho do portador.
Embossadora já integradaEscolha uma das que já estão na plataforma e comece sem integrar ninguém.layout do emissor → fila da embossadora
A sua embossadoraEla entra como um tenant de embossadora, com fila e layout próprios — a mesma API.layout do emissor → a sua fila

Nos dois casos é a mesma API de embossing — não existe ponte sob medida por bureau, e trocar de embossadora não é reintegrar.

Quem decide a compra

Use o ledger da plataforma, ou mantenha o seu autorizador como a palavra final.

A compra sai da maquininha e chega à QPay, que a encaminha para o ledger da plataforma — saldo, limite e fatura — ou para o autorizador do próprio cliente; nos dois caminhos a resposta volta autorizada.
Ledger da plataformaSaldo, limite e fatura do nosso lado — e a compra já sai contabilizada.POST /authorization → ledger da QPay
O seu autorizadorA QPay chama a sua API pelo mesmo contrato e obedece à sua resposta.POST /authorization → o seu endpoint

É uma configuração por emissor, trocável no console: apontou para o seu autorizador, quem decide é você; sem ele, o ledger decide e ainda contabiliza, fatura e concilia.

E, nos dois caminhos, o motor de regras

Regras suas, escritas num editor visual no console e aprovadas por um segundo par de olhos antes de valer — e aí valem na hora, sem deploy nem janela. Elas rodam em três camadas — BIN, emissor e cartão, nessa ordem — e a primeira que bate encerra a compra com o motivo que você escolheu.

DUPLA CUSTÓDIA Quem escreve a regra não é quem aprova. Ela só passa a valer depois do segundo par de olhos — e fica registrado quem escreveu, quem aprovou e quando.
BIN Se uma compra em e-commerce, num cartão Platinum, passar de R$ 50.000 entre 2h e 7h da manhã → nega como suspeita de fraude
Emissor Se a compra vier de fora do país e o chip informar que a verificação do portador falhou → nega como transação não permitida
Emissor Se for em posto de combustível, acima de R$ 1.000, num cartão sem senha digitada → nega como excede o limite de valor
Cartão Se este cartão for usado fora do Brasil, em qualquer valor → nega como cartão restrito
Passou Nenhuma regra bateu — a compra segue para quem decide: o ledger da plataforma ou o seu autorizador → autoriza

Valor, canal, perfil do cartão, hora, país, ramo do estabelecimento, parcelas e o que o chip reportou na compra — tudo isso entra numa regra, e as condições se combinam como você quiser.

Segurança

O dado sensível fica do nosso lado da linha

Reduzir escopo PCI não é uma cláusula de contrato — é uma decisão de arquitetura. O PAN nunca chega ao seu banco de dados, e as operações de chave nunca saem do HSM.

Cifrado em repouso

PAN e CVV guardados cifrados, como o PCI DSS exige — nunca em texto claro, nunca em log.

Chaves no HSM

ARQC, ARPC e verificação de PIN acontecem dentro do módulo. A aplicação não vê chave.

Isolamento por tenant

Toda consulta carrega o tenant de quem pediu. Um emissor não alcança o dado de outro, nem por acidente.

Dados protegidos

Os dados do portador e do emissor são gerenciados de forma segura, conforme o PCI DSS.

Falar com o comercial

Comece pelo sandbox, não pela reunião

Conte o que você quer emitir e em que papel entra. Respondemos com acesso ao sandbox e um BIN de teste — se funcionar, aí falamos de contrato.

Antes de falar com alguém, a documentação está aberta Já é cliente? Entre no console

Usamos estes dados só para responder ao seu contato.