Os sete produtos
Antes de decidir
Como nos comparamos
vs. Supabase
Postgres gerenciado, fatura em dólar
vs. Clerk
Login pronto, suporte em outro fuso
vs. Stripe
Cobrança global, assinatura como evento
Se o seu produto é global e cobra em dólar, as ferramentas de lá provavelmente são a escolha certa.
Infraestrutura RiLiGar · 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 @riligar/payments-react
import { PaymentsProvider }
from '@riligar/payments-react'
<PaymentsProvider
publicKey="pk_…"
gatewayId="d58b834d-…"
>
<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 9 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 \
riligar-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.
RiLiGar 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 da RiLiGar. 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.