Arquitetura da plataforma
Um núcleo, várias superfícies — como a plataforma realmente funciona.
Um passeio pela plataforma a partir do ledger: as contas, o KYC, os cartões e as criptomoedas que compartilham um único núcleo de partidas dobradas, como um pagamento percorre o caminho da criação à conciliação e onde ficam a camada de apps, o console do operador e a fronteira regulada.
O núcleo
Um único ledger sob tudo.
No centro da plataforma está um único ledger de contas. Toda conta — a carteira de um cliente, o saldo de um lojista, uma conta de tarifas, uma conta de liquidação — é um nó nesse ledger, e toda movimentação de valor é um lançamento em partidas dobradas: uma conta é debitada, outra é creditada, e os dois lados são sempre iguais. O ledger é append-only. Os lançamentos nunca são editados nem apagados; uma correção é um novo lançamento em sentido contrário, de modo que o histórico completo de como um saldo chegou ao valor atual pode sempre ser reconstruído. Contas, estado de KYC, cartões emitidos e endereços cripto se vinculam ao mesmo modelo de conta, e é por isso que uma autorização de cartão, uma transferência bancária e um depósito on-chain podem ser lançados em um único saldo, sem uma camada de conciliação costurando sistemas separados.
- 01Partidas dobradas: todo lançamento fecha, débitos iguais a créditos
- 02Append-only: correções são novos lançamentos, nunca edições
- 03Um único modelo de conta para moeda fiduciária, cartões e cripto
- 04O estado de KYC acompanha a conta, não fica em uma tabela paralela
Um pagamento, de ponta a ponta
Um pagamento, da criação à conciliação.
Um pagamento não é uma única chamada, mas um ciclo de vida curto, e cada etapa é um estado que o ledger e os seus sistemas conseguem enxergar. Toda mudança de estado emite um webhook, e toda escrita é idempotente — a mesma chave reproduz o mesmo resultado, então uma requisição repetida nunca cobra duas vezes.
- 01
Criação
Uma intenção de pagamento é aberta: valor, moeda, contas envolvidas. Nada foi movimentado ainda — o ledger registra um lançamento pendente.
- 02
Autorização
O trilho verifica saldo e risco e faz uma reserva. Em um cartão, isso é a autorização; em uma transferência, o débito fica reservado.
- 03
Captura
O valor reservado é confirmado. O ledger lança a partida dobrada que de fato move o valor entre as duas contas.
- 04
Liquidação
Os recursos são compensados no trilho subjacente — bandeira de cartão, banco ou blockchain — e as contas de liquidação são conciliadas com dinheiro real.
- 05
Conciliação
A plataforma confronta seus próprios lançamentos com o relatório de liquidação do trilho; o que não bater é sinalizado, não escondido.
Webhooks e idempotência estão presentes em todas as pontas desse fluxo. Seus sistemas sabem que um pagamento foi movimentado ao receber um evento, e não por polling, e qualquer requisição que você repita após um timeout se resolve — por meio da sua chave de idempotência — no mesmo resultado, de modo que uma repetição nunca cobra em duplicidade. O serviço que executa a autorização e a captura é o gateway de pagamento.
A camada de apps
Apps whitelabel por cima, uma só plataforma por baixo.
O núcleo expõe capacidades; a camada de apps as transforma em produtos. Cada app voltado ao cliente — web e mobile — é um cliente whitelabel que exibe as mesmas contas, pagamentos e cartões com a sua própria marca. O tema é orientado por tokens: cores, tipografia, raios de borda e espaçamentos vêm de um sistema de design tokens (PDS), então o operador reestiliza toda a superfície alterando tokens, sem fazer fork do app. A mesma plataforma pode ser direcionada para rumos bem diferentes — um neobanco para consumidores, um app de adquirência para lojistas, um programa de emissão de cartões, um on/off-ramp cripto ou uma ferramenta interna de operações — sem virar cinco produtos separados. É uma só plataforma com visuais diferentes, cada um configurado em vez de reconstruído.
- 01Clientes whitelabel web e mobile sobre APIs compartilhadas
- 02Temas orientados por tokens (PDS): reestilize por configuração, sem fork
- 03Cinco direções de exemplo — neobanco, adquirência, emissão, ramp, operações
- 04Novas superfícies são configuradas, não reconstruídas
Operações
Opere pelo console, com o motivo registrado.
Por trás de cada app há um console do operador. É nele que um agente de suporte consulta uma conta, um analista de risco bloqueia um cartão ou um líder de operações estorna um lançamento. A leitura é ampla; as ações privilegiadas, não. Qualquer ação que movimente dinheiro, altere limites ou toque nos recursos de um cliente exige um motivo informado antes de ser executada e grava um registro de auditoria imutável — quem agiu, sobre o quê, quando e por quê. O acesso segue o princípio do menor privilégio: cada operador vê e faz apenas o que o seu perfil permite. Esse é o modelo do Protocore Center, o console do operador, e a mesma postura está presente em todos os sistemas da plataforma: ações sensíveis são deliberadas, atribuíveis e auditáveis depois do fato.
- 01Leitura ampla, escrita controlada — ações privilegiadas são a exceção
- 02Motivo obrigatório antes de qualquer ação que toque em recursos
- 03Trilha de auditoria imutável: quem, o quê, quando, por quê
- 04Menor privilégio por perfil de operador
A ponte cripto
Cripto e moeda fiduciária no mesmo ledger.
Na plataforma, cripto não é um silo separado; um endereço cripto é apenas mais uma conta no mesmo ledger. Um on/off-ramp converte entre moeda fiduciária e ativos digitais na borda — o cliente recarrega o saldo com cartão ou transferência e recebe cripto, ou vende cripto e saca para uma conta bancária. O valor on-chain pode ser liquidado até um trilho bancário: um pagamento on-chain recebido é creditado na conta, convertido e pago a um IBAN, de modo que o destinatário vê dinheiro comum em uma conta bancária comum. Como as duas pontas são lançadas em um único ledger de partidas dobradas, uma movimentação que começa on-chain e termina em uma transferência bancária forma um único histórico conciliado, e não dois sistemas conciliados na mão.
- 01Um endereço cripto é uma conta como outra qualquer
- 02On/off-ramp: moeda fiduciária e ativos digitais convertidos na borda
- 03Liquidação on-chain até o pagamento em um IBAN
- 04Um único histórico conciliado nas duas pontas
A superfície de desenvolvimento
APIs, webhooks e um sandbox para você desenvolver.
Tudo o que os apps fazem, eles fazem por uma API documentada — criar uma conta, abrir um pagamento, emitir um cartão, iniciar um ramp. Chamadas ilustrativas são como POST /v1/wallets ou POST /v1/payments; o formato é REST, com chave de idempotência em toda escrita. As mudanças de estado são entregues como webhooks, para que seus sistemas reajam a eventos em vez de ficar consultando. O desenvolvimento acontece em um tenant de sandbox — uma cópia isolada da plataforma com trilhos de teste, onde você executa o fluxo completo, da criação à conciliação, sem movimentar dinheiro de verdade. O que cada produto expõe para você, e em qual nível, é definido pela sua faixa de acesso; as páginas de cada produto detalham o que cada faixa inclui.
- 01API REST documentada, escritas idempotentes
- 02Webhooks para toda mudança de estado — orientado a eventos, sem polling
- 03Tenant de sandbox com trilhos de teste, isolado da produção
- 04Escopo e limites definidos por faixas de acesso de cada produto
A fronteira, sem rodeios
A Protocore constrói o software. A licença cuida da fronteira regulada.
Um produto de pagamento é duas coisas combinadas: a autorização regulada para guardar e movimentar dinheiro e o software que instrui, registra e concilia essa movimentação. A Protocore constrói o software. A atividade regulada — guardar recursos de clientes, emitir contas, movimentar dinheiro em um arranjo — fica com a licença do próprio operador ou de um parceiro licenciado: um banco, uma EMI ou uma instituição de pagamento. A plataforma foi feita para se encaixar nos trilhos regulados que você trouxer e para manter os dados de cartão no trilho, sem nunca passar pelos seus servidores; ela não substitui essa autorização, e nenhum software substitui. Onde fica a fronteira regulada é uma decisão que você toma com o seu parceiro, e a arquitetura foi desenhada para ficar bem posicionada de qualquer lado dela.
- 01Uma camada de software, não uma licença
- 02A atividade regulada fica com o operador ou com um parceiro licenciado
- 03Os dados de cartão ficam no trilho, fora dos seus servidores
- 04Feita para se encaixar nos trilhos regulados que você trouxer
Onde isso se conecta
Siga um fio mais adiante.
Cada conceito desta página tem um espaço mais completo — as definições, os produtos e as faixas de acesso que detalham o que cada nível inclui.
Idempotência, webhooks, liquidação, IBAN virtual, SCA — definidos.
O serviço que executa a autorização e a captura.
Ações privilegiadas com motivo obrigatório e auditadas.
Valor on-chain liquidado até um IBAN.
Moeda fiduciária e ativos digitais convertidos na borda.
O que cada produto inclui, nível por nível.
Quer a arquitetura para o seu projeto?
Conte o que você está construindo. Voltamos com um desenho de sistema e com o ponto onde fica a fronteira regulada — não com uma apresentação comercial.