Emissão de cartões que gasta do saldo cripto ou fiat

Quase toda equipe descobre a mesma coisa quando começa a dimensionar um cartão: o cartão é a parte fácil. O difícil é tudo o que existe por trás dele, a lógica de autorização, o modelo de funding, o perímetro de compliance e a pergunta sobre onde o dinheiro realmente está quando um usuário aproxima o cartão para pagar.

Este guia percorre como a emissão de cartões funciona de ponta a ponta, a diferença entre emissor e adquirente, o que você realmente precisa para lançar um programa e uma decisão de design que muda todo o panorama: um cartão que gasta direto de um saldo cripto ou fiat em vez de um pool pré-carregado. Se você está dimensionando um lançamento mais amplo, comece pelo nosso guia sobre como criar uma fintech de pagamentos cripto e fiat e use este texto para a camada de cartões.

O que é emissão de cartões?

Emissão de cartões é o processo de criar e distribuir cartões de pagamento, virtuais ou físicos, que um titular usa para gastar a partir de uma conta. O emissor autoriza cada transação, movimenta os fundos e carrega o risco e as obrigações de compliance associadas.

Na prática, “emitir” não é uma ação única. É um programa: um conjunto de regras sobre quem recebe um cartão, como ele é financiado, no que pode ser gasto e como cada compra é autorizada em tempo real. O cartão em si, o plástico ou o token em uma carteira digital, é apenas a ponta visível desse programa.

Como a emissão de cartões funciona, de ponta a ponta

Em linhas gerais, a emissão segue um ciclo: um cartão é criado e vinculado a uma fonte de fundos, e cada compra é roteada pela rede de cartões de volta ao emissor para uma decisão em tempo real. O emissor checa limites, saldo e risco em milissegundos, e aprova ou recusa.

Este é o caminho completo de um cartão, do setup até uma compra concluída.

Etapa	O que acontece	Quem atua
Setup do programa	Definir regras, funding, limites e marca	Você + plataforma de emissão
Criação do cartão	É gerado e vinculado a um usuário e a uma fonte de fundos	Plataforma de emissão
Provisionamento	O virtual é instantâneo; o físico é fabricado e enviado	Plataforma + fabricante
Autorização	A rede roteia cada compra ao emissor para aprovar ou recusar	Rede de cartões + emissor
Compensação e liquidação	Os fundos são conciliados e liquidados entre emissor e adquirente	Emissor + adquirente via rede
Ciclo de vida	Bloquear, substituir, ajustar limites, encerrar	Você, pela API

A tabela acima também é um bom modelo mental de para onde vai o seu esforço de engenharia: quase nada é o cartão, e quase tudo é autorização, funding e ciclo de vida.

Emissor vs adquirente vs as redes de cartões

O emissor trabalha do lado do titular e o adquirente do lado do comércio, enquanto a rede de cartões fica no meio e roteia as mensagens entre os dois. Confundir esses três papéis é o erro mais comum no início.

Papel	De qual lado	Função central
Emissor	Titular	Cria cartões, autoriza o gasto, administra a conta e os fundos
Adquirente	Comércio	Credencia lojistas e recebe os pagamentos que eles cobram
Rede de cartões	Nenhum	Roteia as mensagens de autorização e liquidação entre os dois

Se você está construindo um produto em que seus usuários mantêm um saldo e o gastam, você está do lado da emissão. Você não credencia lojistas, então não precisa ser adquirente. O que você precisa é de acesso a um programa de emissão e uma forma de autorizar transações contra os fundos dos seus usuários.

O que é preciso para emitir cartões

Para emitir cartões você precisa de cinco coisas: acesso a um programa de cartões, um processador que autorize e liquide, tratamento de dados de cartão conforme o PCI DSS, KYC e AML sobre os seus usuários, e um modelo de funding. A pergunta é se você monta tudo isso por conta própria ou obtém por meio de uma única plataforma.

Existem duas rotas amplas até um programa em produção.

Operar o seu próprio programa. Você obtém as licenças, se torna membro da rede e monta você mesmo o processamento e a infraestrutura PCI. Isso dá o máximo de controle e melhor economia em escala no longo prazo, mas é lento, intensivo em capital e só faz sentido com volume alto.

Usar patrocínio de BIN por meio de uma plataforma Card-as-a-Service. Uma instituição licenciada permite que você emita sob o seu Bank Identification Number e a sua associação à rede, e uma plataforma entrega a API, o processamento e a engenharia de compliance. Você tem o produto e a experiência; o relacionamento regulado fica sobre o patrocinador.

Abordagem	Time-to-market	Controle	Ideal para
Programa e licença próprios	Longo (muitos meses)	O mais alto	Emissores de alto volume com recursos regulatórios
Patrocínio de BIN + Card-as-a-Service	Semanas	Alto no produto, compartilhado nos trilhos	A maioria das fintechs e marketplaces

Para a grande maioria das equipes, o patrocínio de BIN por meio de uma plataforma é a decisão certa. É a mesma lógica do clássico construir versus integrar: construa o produto pelo qual seus usuários vêm até você, e integre os trilhos regulados que seriam idênticos em qualquer fintech competente. Para o lado das licenças dessa decisão, veja licenças para movimentar cripto e fiat: BCB, MSB, EMI e MiCA.

Tipos de cartão que dá para emitir

Os cartões se agrupam em quatro famílias de produto, pré-pago, débito, crédito e corporativo ou de despesas, e cada um pode ser virtual, físico ou os dois. O tipo certo segue o seu modelo de funding, não o contrário.

Tipo de cartão	Gasta de	Uso típico
Pré-pago	Um saldo carregado	Carteiras digitais, payouts, pagamentos a autônomos e creators
Débito	O saldo de uma conta vinculada	Contas de neobank, gasto do dia a dia
Crédito	Uma linha de crédito concedida	Produtos de crédito, rotativo
Corporativo / de despesas	Fundos da empresa com controles por usuário	Gasto empresarial, equipes, compras

Os cartões virtuais são provisionados na hora e são ideais para gasto on-line, tokens de uso único e pagamentos por carteira digital. Os físicos, plástico ou metal, importam quando os seus usuários pagam pessoalmente ou esperam um objeto premium. A maioria dos programas oferece os dois a partir da mesma conta.

Gastando direto de um saldo cripto ou fiat

A decisão de design que muda tudo é vincular o cartão a um saldo em tempo real em vez de um pool pré-carregado. Quando o cartão autoriza contra o saldo ao vivo, não há float para administrar, não há pré-carga para conciliar, e o valor permanece onde o usuário o controla até o momento do gasto.

É aqui que um ledger multimoeda unificado compensa. Um cartão vinculado a um saldo unificado pode gastar de fiat local ou de uma posição em stablecoin, com a conversão resolvida na autorização. O usuário recarrega com o que tiver; o cartão gasta na moeda do comércio.

Em uma arquitetura não custodial, isso também muda o seu perfil de risco. Como o usuário mantém o controle dos próprios fundos e cada movimentação precisa da aprovação dele, você opera o programa de cartões sem ter o dinheiro do cliente no seu balanço. Essa é uma conversa regulatória diferente da de uma conta de float custodial, e vale a pena entender os trade-offs em custódia custodial vs não custodial.

Criar um cartão que gasta do saldo é uma única chamada de API. Uma requisição realista se parece com isto.

curl https://api.tokelia.com/v1/cards \
  -H "Authorization: Bearer $API_KEY" \
  -H "Idempotency-Key: card_req_9f2c1a" \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "usr_8Kd2p",
    "type": "virtual",
    "funding_source": "balance_usdc_primary",
    "currency": "USD",
    "spend_controls": {
      "per_transaction_limit": 50000,
      "daily_limit": 200000,
      "allowed_categories": ["retail", "travel", "software"]
    },
    "three_d_secure": true
  }'

Dois detalhes importam aqui. O header Idempotency-Key faz com que uma requisição reenviada nunca crie um cartão duplicado, algo essencial quando as redes dão timeout. E funding_source aponta direto para o saldo do usuário, então a autorização roda contra fundos em tempo real, e não contra uma carteira separada que você precisaria manter recarregada. Em seguida, um webhook confirma cada evento posterior (autorização, recusa, liquidação) para que o seu ledger fique sincronizado.

Compliance: KYC, AML e PCI DSS

Todo programa de emissão carrega três obrigações de compliance: verificar quem detém o cartão (KYC e AML), proteger os dados de cartão (PCI DSS) e monitorar o gasto contra fraude e sanções. Não são complementos opcionais; são o preço de tocar nas redes de cartões.

O KYC e o AML rodam no cadastro e continuam durante a vida do cartão, com checagem de sanções e PEP e monitoramento de transações. Para o panorama completo de como isso funciona em cripto e fiat, veja como funcionam o KYC e o AML em pagamentos cripto e fiat.

O PCI DSS regula como os dados de cartão (o PAN, o CVV e o PIN) são armazenados, transmitidos e exibidos. A forma mais limpa de lidar com isso é nunca tocar em dados brutos de cartão: uma plataforma que tokeniza os dados sensíveis e os entrega a partir de um cofre em conformidade mantém a maior parte da carga PCI fora dos seus sistemas. Os controles antifraude (regras de velocidade, 3-D Secure, bloqueio e geocontroles) ficam por cima disso.

Custos, time-to-market e o modelo de intercâmbio

A economia de cartões tem dois lados: os custos de operar o programa e a receita de intercâmbio ganha sobre o consumo. O intercâmbio é a tarifa que o lado do comércio paga em cada transação, parte da qual volta para o programa de emissão, e é a razão pela qual emitir cartões pode ser uma linha de receita, e não um centro de custo.

Linha de custo ou receita	Direção	Notas
Setup do programa	Custo	Único, varia por provedor
Custo por cartão	Custo	O virtual é o mais barato; plástico e metal custam mais
Transação / processamento	Custo	Por autorização e liquidação
Tarifas de rede	Custo	Definidas pela rede de cartões
Intercâmbio	Receita	Uma parte do consumo volta para o programa

Os números exatos variam por mercado, volume e programa, então trate isso como um referencial e não como uma cotação, e confirme a economia com o seu provedor. Quanto a prazos, uma integração Card-as-a-Service permite que equipes com experiência em APIs REST tenham um fluxo de cartão funcionando em semanas, em vez dos muitos meses que um programa com licença própria exige.

Uma nota sobre o Brasil e os mercados regulados

No Brasil, a emissão de cartões geralmente envolve uma entidade regulada, um banco ou uma instituição de pagamento autorizada e supervisionada pelo Banco Central do Brasil (BCB), quase sempre com participação em uma rede de cartões como a Visa. Empresas sem licença própria normalmente emitem em parceria com um patrocinador licenciado.

Esse padrão se repete em vários mercados: o perímetro regulado é definido localmente, e a rota compatível mais rápida para uma fintech quase sempre é emitir por meio de um parceiro licenciado, em vez de obter a autorização de emissão diretamente. Limites, categorias e requisitos evoluem, então confirme o marco regulatório vigente em cada mercado com assessoria local antes de comprometer uma data de lançamento.

Onde a Tokelia se encaixa

A Tokelia emite cartões virtuais, de plástico e de metal que gastam direto de um saldo não custodial cripto ou fiat, com envio instantâneo para qualquer cartão, atrás de uma única API com webhooks, idempotência e sandbox. O compliance (KYC/AML, checagem de sanções e tratamento de dados de cartão conforme o PCI) vem embutido na stack base, em vez de ser vendido como complemento. Os serviços de dinheiro são prestados pela Tokelia LLC, registrada como Money Services Business junto à FinCEN, com a banca regulada entregue por instituições licenciadas, de modo que você lança um programa de cartões com a sua própria marca sem custodiar fundos do cliente nem conectar separadamente um processador, um custodiante e um fornecedor de KYC.

Se você está dimensionando um programa de cartões, a forma mais rápida de testá-lo contra o seu próprio modelo de funding é percorrer um fluxo real com o nosso time. Fale conosco e consiga uma sandbox key.