Arquitetura da plataforma

Um núcleo, várias superfícies — como a plataforma funciona na prática.

Um percurso pela plataforma a partir do livro-razão: as contas, o KYC, os cartões e as criptomoedas que partilham um único núcleo de partidas dobradas, como um pagamento percorre o caminho da criação à reconciliação, e onde ficam a camada de apps, a consola do operador e a linha regulada.

Fale connosco Ver os produtos

O núcleo

Um só livro-razão por baixo de tudo.

No centro da plataforma está um único livro-razão de contas. Cada conta — a carteira de um cliente, o saldo de um comerciante, uma conta de comissões, uma conta de liquidação — é um nó nesse livro-razão, e cada movimento de valor é um lançamento por partidas dobradas: uma conta debitada, outra creditada, com os dois lados sempre iguais. O livro-razão é append-only. Os registos nunca são editados nem apagados; uma correção é um novo lançamento em sentido contrário, pelo que é sempre possível reconstituir o historial completo de como um saldo chegou ao valor atual. Contas, estado de KYC, cartões emitidos e endereços cripto ligam-se todos 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 lançar-se num único saldo sem uma camada de reconciliação a coser sistemas separados.

01Partidas dobradas: cada lançamento fica equilibrado, débitos iguais a créditos
02Append-only: as correções são novos registos, nunca edições
03Um só modelo de conta para moeda fiduciária, cartões e cripto
04O estado de KYC acompanha a conta, não fica numa tabela à parte

Um pagamento, de ponta a ponta

Um pagamento, da criação à reconciliação.

Um pagamento não é uma só chamada, mas um ciclo de vida curto, e cada fase é um estado que o livro-razão e os seus sistemas conseguem ver. Cada mudança de estado emite um webhook e cada escrita é idempotente — a mesma chave repete-se com o mesmo resultado, por isso um pedido repetido nunca cobra duas vezes.

01
Criar
Abre-se uma intenção: montante, moeda, contas envolvidas. Ainda nada se movimentou — o livro-razão regista um lançamento pendente.
02
Autorizar
A rede verifica fundos e risco e coloca uma retenção. Num cartão, é a autorização; numa transferência, o débito fica reservado.
03
Capturar
O montante retido é confirmado. O livro-razão lança as partidas dobradas que efetivamente movem o valor entre as duas contas.
04
Liquidar
Os fundos são compensados na rede subjacente — esquema de cartões, banco ou blockchain — e as contas de liquidação reconciliam-se com dinheiro real.
05
Reconciliar
A plataforma confronta os seus próprios lançamentos com o relatório de liquidação da rede; o que não bate certo é sinalizado, não escondido.

Webhooks e idempotência estão presentes em todas as extremidades deste fluxo. Os seus sistemas sabem que um pagamento avançou ao receber um evento, não por polling, e qualquer pedido repetido após um timeout resolve-se — através da sua chave de idempotência — para o mesmo resultado, pelo que uma repetição nunca cobra duas vezes. O serviço que executa a autorização e a captura é o gateway de pagamentos.

A camada de apps

Apps whitelabel por cima, uma só plataforma por baixo.

O núcleo expõe capacidades; a camada de apps transforma-as em produtos. Cada app para o cliente — web e mobile — é um cliente whitelabel que apresenta as mesmas contas, pagamentos e cartões com a sua própria marca. A personalização assenta em tokens: cores, tipografia, raio e espaçamento vêm de um sistema de design tokens (PDS), pelo que o operador redesenha toda a superfície alterando tokens, sem fazer fork da app. A mesma plataforma pode apontar para direções muito diferentes — um neobanco de consumo, uma app de acquiring para comerciantes, um programa de emissão de cartões, uma on/off-ramp cripto ou uma ferramenta interna de operações — sem se tornar cinco produtos separados. É uma só plataforma com visuais diferentes, cada um configurado e não reconstruído.

01Clientes whitelabel web e mobile sobre APIs partilhadas
02Temas por tokens (PDS): redesenhe por configuração, não por fork
03Cinco direções de exemplo — neobanco, acquiring, emissão, ramp, ops
04Novas superfícies configuram-se, não se reconstroem

Operações

Opere a partir da consola, com o motivo registado.

Por trás de cada app há uma consola de operador. É aí que um agente de suporte consulta uma conta, um analista de risco bloqueia um cartão ou um responsável de operações reverte um lançamento. O acesso de leitura é amplo; as ações privilegiadas não. Tudo o que movimenta dinheiro, altera limites ou toca nos fundos de um cliente exige um motivo declarado antes de ser executado e grava um registo de auditoria imutável — quem agiu, sobre quê, quando e porquê. O acesso segue o princípio do menor privilégio, por isso cada operador vê e faz apenas o que o seu perfil permite. É este o modelo do Protocore Center, a consola do operador, e a mesma postura está presente em todos os sistemas da plataforma: as ações sensíveis são deliberadas, atribuíveis e revisíveis a posteriori.

01Leitura ampla, escrita controlada — as ações privilegiadas são a exceção
02Motivo obrigatório antes de qualquer ação que toque em fundos
03Registo de auditoria imutável: quem, o quê, quando, porquê
04Menor privilégio por perfil de operador

A ponte cripto

Cripto e moeda fiduciária no mesmo livro-razão.

Na plataforma, a cripto não é um silo separado; um endereço cripto é apenas mais uma conta no mesmo livro-razão. Uma on/off-ramp converte entre moeda fiduciária e ativos digitais na periferia — o cliente carrega um saldo com cartão ou transferência e recebe cripto, ou vende cripto e levanta para uma conta bancária. O valor on-chain pode liquidar até uma rede bancária: um pagamento on-chain recebido é creditado na conta, convertido e pago a um IBAN, de modo que o destinatário vê dinheiro normal numa conta bancária normal. Como as duas pernas são lançadas num único livro-razão de partidas dobradas, um movimento que começa on-chain e termina numa transferência bancária é um historial único e reconciliado, não dois sistemas reconciliados à mão.

01Um endereço cripto é uma conta como qualquer outra
02On/off-ramp: moeda fiduciária e ativos digitais convertidos na periferia
03Liquidação on-chain até ao pagamento num IBAN
04Um historial reconciliado nas duas pernas

A superfície de desenvolvimento

APIs, webhooks e uma sandbox para desenvolver.

Tudo o que as apps fazem, fazem-no através de uma API documentada — criar uma conta, abrir um pagamento, emitir um cartão, iniciar uma ramp. Exemplos ilustrativos de chamadas: POST /v1/wallets ou POST /v1/payments; o estilo é REST, com uma chave de idempotência em cada escrita. As mudanças de estado são entregues por webhooks, para que os seus sistemas reajam a eventos em vez de fazerem polling. O desenvolvimento faz-se num tenant sandbox — uma cópia isolada da plataforma com redes de teste, onde pode percorrer o fluxo completo da criação à reconciliação sem movimentar dinheiro real. O que cada produto lhe expõe, e em que 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 cada mudança de estado — por eventos, sem polling
03Tenant sandbox com redes de teste, isolado da produção
04Âmbito e limites definidos por faixas de acesso de cada produto

O limite, com franqueza

A Protocore constrói o software. A licença assegura a linha regulada.

Um produto de pagamentos junta duas coisas: a autorização regulada para deter e movimentar dinheiro, e o software que o instrui, regista e reconcilia. A Protocore constrói o software. A atividade regulada — deter fundos de clientes, emitir contas, movimentar dinheiro numa rede — 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 concebida para se ajustar às redes reguladas que trouxer, e para manter os dados dos cartões na rede, sem nunca passarem pelos seus servidores; não substitui essa autorização, tal como nenhum software a substitui. Onde passa a linha regulada é uma decisão que toma com o seu parceiro, e a arquitetura foi pensada para assentar bem de qualquer um dos lados.