Infraestrutura · Payments
O pagamento do mundo inteiro, estupidamente simples no seu software.
Pegamos o maior processador de pagamento de software do planeta — o mesmo trilho que cobra por trás dos produtos que você já usa — e reduzimos ele a uma pergunta só: “esse cliente pode entrar?”. A resposta vem na hora, do seu lado, em 224 ms medidos. Você recebe, e o controle de quem pode usar o quê vira uma linha de código em vez de um subsistema.
Comece de graça, sem cartão e sem falar com vendedor: a chave sai na hora. O trilho de hoje é assinatura recorrente no cartão.
O que você ganha
Cinco trabalhos que você nunca mais faz.
Não é que fiquem mais fáceis. É que ninguém do seu time escreve nenhum deles.
Você não escreve
Guardar quem pagou, e mexer nisso toda vez que muda
Quem é assinante, de qual plano, até quando, e o vínculo com o cadastro dele no processador. Toda vez que o seu produto muda, isso muda junto. Do nosso lado já está pronto e versionado — do seu, deixa de existir.
Você não escreve
Escutar o processador e entender o que ele avisou
Conferir se o aviso veio mesmo dele, separar pagamento aprovado de recusado, decidir o que cada um significa para o acesso do cliente e o que fazer com os avisos que você não conhece. São 377 linhas do nosso lado. Do seu, passam a ser zero.
Você não escreve
Guardar a resposta e descobrir quando ela venceu
Quem guarda essa resposta para ganhar tempo herda o problema mais chato: saber a hora de jogá-la fora. Aqui você pergunta direto e recebe em 224 ms medidos — a resposta é sempre a de agora.
Você não escreve
Conferir na mão quando um aviso se perde
Aquele script de madrugada que compara o seu banco com o painel do processador e corrige as diferenças. Ele só existe porque a informação vivia em dois lugares que discordavam. Com um lugar só, não sobra o que conferir.
Você não escreve
Avisar o seu cliente que a cobrança aconteceu
Boas-vindas, recibo, pagamento recusado, conta desativada. Cada um precisa sair uma vez só, mesmo quando o processador reenvia o aviso três vezes — e é isso que dá trabalho, não escrever o texto. Sai com o nome do SEU sistema, e você reescreve o texto no painel sem tocar em código.
Por que isso acontece
Receber o pagamento é a parte fácil. Difícil é ter certeza depois.
A integração você já fez, e ela funcionou — o dinheiro entra. O que não acaba nunca é a dúvida do dia seguinte. O processador te manda avisos soltos — “fulano pagou”, “o cartão do beltrano falhou” — e o seu produto precisa de outra coisa: uma lista confiável de quem pode entrar agora. Traduzir uma coisa na outra é um trabalho que ninguém pediu, e é exatamente a parte que a gente já escreveu.
Você provavelmente já viu pelo menos um destes
- Quem cancelou continua entrando o aviso de cancelamento se perdeu, ninguém percebeu, e o acesso seguiu aberto. Você só descobre quando compara o dinheiro que entrou com a lista de quem está usando — e os números não batem.
- Quem pagou fica de fora esse é o pior dos dois, porque ele te procura na hora. E enquanto você investiga, ele já contou para alguém que o seu produto cobrou e não liberou.
- Ninguém no time responde “esse cliente pode entrar?” sem procurar a resposta está espalhada entre um campo no banco, o painel do processador e a memória de quem fez a integração. No dia em que essa pessoa sai da empresa, sobra o painel.
- E a pergunta que ninguém quer ouvir numa reunião “a gente tem certeza de quem está pagando agora?”. Se a resposta demora mais que alguns segundos, ela está guardada no lugar errado.
Repare que nenhum destes é sobre dinheiro perdido e isso é de propósito. Ninguém aqui sabe quanto um acesso errado custa no seu negócio, e não vamos inventar um número para te impressionar. O que dá para afirmar é o que você mesmo consegue conferir hoje: esses casos existem, dá para contar quantos são, e todos têm a mesma causa — a informação mora em dois lugares que discordam. Resolver a causa é o que a gente faz.
O caminho inteiro
Instala, pergunta, recebe.
Quatro blocos — e o segundo você roda agora, do seu terminal, sem criar conta.
1 · Instalar
Um pacote, e o provider na raiz
São 36.486 bytes de ESM sem build step: o package.json aponta direto para o fonte, então não há bundler nosso no seu caminho. Ele já vem com a tabela de preços, o portal do cliente e o controle de acesso por feature prontos — por isso traz @mantine/core junto. Quem quer só as rotas HTTP não precisa do pacote: são dois GET, em qualquer linguagem.
$ bun add @ciromaciel/payments-react
import { PaymentsProvider }
from '@ciromaciel/payments-react'
<PaymentsProvider
publicKey="pk_…"
gatewayId="gw_…"
>
<App />
</PaymentsProvider>2 · Perguntar
A pergunta que sua aplicação faz de verdade
A pergunta do seu produto não é “esse cliente pagou?” — é “esse cliente pode usar isso agora?”. A resposta sai do nosso banco na hora, sem precisar consultar o processador. E este comando funciona neste instante, com a chave desta própria página: cole no terminal e veja a resposta antes mesmo de criar conta.
$ curl "https://payments.worker.myinfrastructure.click\
/sdk/v1/permissions\
?publicKey=pk_1f01ce76…\
&userId=teste-inexistente"
{"message":"Permissions retrieved",
"data":{
"hasActiveSubscription":false,
"subscriptions":[],
"features":[]}}3 · Receber
Um endpoint, e nós registramos os eventos por você
Você aponta uma URL e um POST em /gateways/:id/auto-setup registra os cinco eventos no gateway. Cada evento é verificado por assinatura antes de qualquer processamento: sem segredo configurado, o endpoint recusa com 400 antes de ler o corpo.
POST /webhook/:gatewayId
// verificação, antes de processar
await gateway.webhooks
.constructEventAsync(
payload, signature, secret
)
// assinatura inválida → lança
// → HTTP 4004 · Proteger
O hook é conveniência. O servidor é a autorização.
Duas linhas de defesa, cada uma no seu lugar. No frontend, useHasFeature lê do contexto sem ida à rede: instantâneo para esconder um botão ou trocar uma tela. No servidor, a chave secreta autoriza de verdade — é ela que decide acesso. O SDK já entrega os dois lados prontos, na divisão que qualquer produto sério de pagamento adota.
// frontend: só esconde a UI
const pode = useHasFeature(
'react-sdk-access'
)
// servidor: isto é o que vale
fetch(url, { headers: {
Authorization: 'Bearer sk_…'
}})Model Context Protocol
Seu agente administra a operação. Sem código no meio.
A verdade sobre as assinaturas já mora aqui — o que faltava era o agente conseguir perguntar sem alguém escrever a integração. São 11 ferramentas em 3 escopos, na revisão 2026-07-28, a stateless. Ele administra: lê métricas, investiga inadimplência, cria plano, gera link de cobrança. Ele não é um meio de pagamento — quem paga é o cliente, no checkout do gateway.
O que o servidor NÃO oferece
- Apagar plano, feature ou gateway, regenerar as chaves, cancelar assinatura não existem como ferramenta. Um agente que leia "apague tudo" num documento não encontra o gatilho para obedecer.
- Nenhuma ferramenta devolve credencial a chave do processador não entra nem sai por aqui. Onde ela importa, vai um preview — sk_live_…4242 — e o modo. Segredo que passa por contexto de LLM vaza em log e em transcript.
- Alterar assinatura ativa fica num escopo separado porque gera fatura imediata no cartão de uma pessoa real. Ela é a única marcada como destrutiva, e a secretKey não a alcança: exige um login que diga quem mandou.
O endereço termina no id do projeto, e isso não é enfeite de URL um token identifica uma pessoa, e uma pessoa administra vários projetos. O id vira a audiência do token, então um consentimento dado a um projeto não vale nos outros — é a checagem anti confused deputy da RFC 8707. Conectar em /mcp sem o id é recusado com uma mensagem dizendo onde copiar o endereço certo.
Como o agente entra
Nenhuma chave no arquivo.
O token nasce no navegador e vale só no projeto que você aprovou.
OAuth 2.1
Você aprova no navegador, uma vez
Sem header nenhum no comando. Na primeira chamada o servidor responde 401 apontando para o metadata; o cliente descobre o authorization server sozinho, abre o navegador e você aprova. O token vale só naquele projeto — o id no endereço vira a audiência dele. Em automação sem navegador, a secretKey do projeto conecta direto, mas ela não libera alterar assinatura ativa.
$ claude mcp add --transport http \
infrastructure-payments \
https://payments.worker.myinfrastructure.click/mcp/<id-do-projeto>
→ 401 WWW-Authenticate
→ descobre o auth server
→ abre o navegador
✓ token com aud= este projeto ▊O que muda na prática
A pergunta que você faria ao banco
O agente não adivinha o id do gateway nem o modo em que ele está: começa perguntando ao projeto. É a primeira ferramenta do catálogo por isso — e é ela que responde se a operação está cobrando de verdade ou rodando em sandbox.
Você: "quem está inadimplente?"
→ payments_get_project
gateway prod · mode: live
→ payments_list_subscriptions
{ status: "past_due" }
3 assinaturas. A mais antiga
falhou há 11 dias. ▊Segurança
Sem adjetivo. Só o que o código faz.
Nenhuma palavra como “seguro” ou “confiável” aqui. Só o que dá para conferir.
O que existe hoje
- Nenhum dado de cartão passa por aqui não existe campo de número, validade ou código de segurança em lugar nenhum. Quem mostra o formulário de pagamento é o gateway, no site dele.
- Suas credenciais ficam embaralhadas no banco a senha que desembaralha mora fora dele, e nunca é gravada junto. Quem abrisse o banco veria texto sem sentido.
- Todo aviso de pagamento é conferido antes de valer o gateway assina o que envia, e a gente confere a assinatura antes de ler o conteúdo. Aviso sem assinatura válida é descartado.
- Duas chaves, dois papéis a pública monta a tela e pode ficar visível no navegador. A secreta libera acesso e fica no seu servidor. Você troca qualquer uma delas sozinho, pelo painel.
O que ainda não temos, dito pelo nome certificações formais, testes automatizados e página de status. Nenhum deles impede um SaaS de cobrar hoje, e todos estão no caminho — você lê isso aqui em vez de descobrir depois.
Sendo justo
O processador resolve o mundo inteiro.
Nós resolvemos o seu software.
O processador cru, direto
Onde ele já resolve sozinho
Pix, boleto e carteiras digitais
Ele tem
Cobrança avulsa, split e marketplace
Ele tem
Antifraude, disputas e chargeback
Ele tem
Faturamento, impostos e nota fiscal
Ele tem
Certificação, uptime público e post-mortem
Ele tem
Documentação e SDK em toda linguagem
15 anos
Vá direto nele se
Você precisa de qualquer coisa acima
O processador é excelente — para os problemas dele.
Infrastructure Payments
Nós não substituímos o processador: rodamos em cima dele, com a sua chave, e escondemos a complexidade que ele te entrega crua. O que você ganha é uma resposta só, do seu lado, para a pergunta que a sua aplicação faz o dia inteiro.
- Uma consulta responde quem pode usar o quê, em 224 ms medidos
- A assinatura já chega traduzida em permissão, não em evento
- Os subsistemas de assinatura que você não escreve nem mantém
- Os e-mails de cobrança saem com a sua marca, e o texto é seu
- Cinco eventos tratados e verificados por assinatura
- Os limites e os bugs conhecidos publicados nesta página
- Acesso a quem escreveu o código, sem fila de suporte
A régua
Os cinco eixos que decidem a escolha
A mesma tabela em toda página de produto do Infrastructure. Cada linha traz o número que medimos, a data e o método — não uma promessa. Duas linhas aqui são desfavoráveis, e continuam na tabela.
Sair e levar tudo
Um curl, sem ticket
Uma rota devolve seus assinantes, planos e status em JSON quando você quiser — no primeiro dia e no último, sem ticket, sem espera e sem falar com vendedor. É o suficiente para reconstruir a camada de permissão em qualquer lugar. Cobranças, eventos e CSV entram na próxima versão do export.
Onde mora a verdade da assinatura
No seu lado
O registro é nosso, chaveado pelo id da assinatura no gateway, e a consulta de permissão responde sem sair para a API dele. É o único eixo em que somos mais rápidos do que perguntar ao gateway — e é o motivo da página existir.
Pix recorrente nativo
Não
O trilho de hoje é cartão recorrente, e ele está pronto: assinatura, renovação, falha de pagamento e cancelamento, todos tratados. Pix ainda não entrou no código — se a sua cobrança é Pix, vale conferir esta linha antes de integrar. Ela muda aqui no dia em que mudar no código.
Custo em R$
R$ 0, sem cartão
Não há cobrança ligada: os quatro planos em produção voltam isLive: false, porque a chave configurada é de teste. Quando houver cobrança real, o preço estará publicado aqui antes de valer.
Latência de leitura para usuário em São Paulo
Não medido de SP
O que medimos: 224 ms de processamento no servidor (mediana de 12 amostras, 26/08/2026), num total de 506 ms — dos quais 286 ms são handshake de conexão. Mas a nossa medição saiu de Boston, não de São Paulo. Enquanto não medirmos de SP, esta linha fica assim.
Se algum destes números não bater no seu caso, escreva. A gente mede de novo e corrige a linha.
Preço
Os planos vêm da API, ao vivo
FAQ
As objeções, na ordem em que elas aparecem
Achou um limite que não está escrito aqui?
Fala direto com quem escreveu o código. Se você encontrou onde quebra, a gente quer publicar isso na página antes do próximo visitante descobrir sozinho.
Pega uma chave e roda o curl. Leva dois minutos.
Sem cartão e sem “fale com vendas”: a chave sai na hora e o primeiro curl responde antes de você criar conta. O trilho de hoje é cartão recorrente, no maior processador de software do mundo — se é isso que o seu produto cobra, você integra hoje.