Pagamentos para quem constrói com IA: o app que você gerou já pode cobrar hoje

Para colocar pagamento num app feito com vibe coding, você dá à sua ferramenta de IA duas coisas: a referência da API em heropay.tech/llms.txt e um prompt que diga exatamente onde a chave mora, quem define o preço e quem confirma o pagamento. Com isso, Claude, ChatGPT, Cursor, Lovable e outros escrevem a rota que chama POST /payment_links, a tela que abre o checkout com Pix, boleto e cartão, e o webhook assinado que libera o acesso. Você testa no sandbox gratuito, troca a chave e vá pro ar. Pix e boleto custam R$ 0 por transação; cartão, 3,49% por transação aprovada, em até 12x (preços).

Criar conta sandbox · Ler a documentação

Por que o app gerado por IA não gera receita sozinho?

A dor em uma frase: a IA monta a tela de preços em cinco minutos, mas o botão "Assinar" não cobra ninguém, porque cobrança exige conta num provedor, chave, backend e confirmação de pagamento, e nada disso vem no primeiro prompt.

Quem faz vibe coding chega ao "funciona na minha tela" muito antes de chegar ao "alguém me pagou". O app está publicado, tem usuários de teste, tem até lista de espera. Falta a peça que transforma uso em dinheiro, e essa peça depende de um provedor de pagamento que a IA conheça bem.

A feature que resolve: o link de pagamento do HeroPay. Uma chamada devolve a URL de um checkout hospedado com Pix, boleto, cartão em até 12x, Apple Pay e Google Pay. Seu app não guarda cartão, não desenha formulário de pagamento e não passa por fila de homologação. Se você nem quer backend agora, crie o link no painel e peça à IA um botão que abra a URL.

A conta em reais. Um micro-SaaS com 100 assinantes de R$ 49,90 fatura R$ 4.990 por mês. Quanto fica com o gateway em cada método:

Verificado em setembro/2026. Fontes: heropay.tech/precos, stripe.com/br/pricing, abacatepay.com e a documentação pública da AbacatePay.

A leitura honesta: como o cartão do HeroPay não tem parte fixa, ele sai mais barato que Stripe e AbacatePay no cartão à vista em qualquer valor de venda. Contra a Stripe, a diferença é de 0,5% do valor mais R$ 0,39 por cobrança; contra a AbacatePay, de 0,01 ponto mais R$ 0,60. No parcelado, que na AbacatePay sobe para 4,00% em 2 a 6x e 4,50% em 7 a 12x, a folga cresce (R$ 6,88 contra R$ 8,48 numa venda de R$ 197 em 6x). No Pix, o HeroPay ganha sem discussão: R$ 0 em qualquer volume, sem convite. O que pesa contra o HeroPay aqui não é a taxa, é a integração: ele não tem botão "conectar" no Lovable, no v0 ou no Bolt, e entra pela função de servidor que a IA escreve. Para um app de ticket baixo, ofereça o Pix primeiro (e Pix Automático na assinatura) e deixe o cartão como segunda opção.

Por que a integração de pagamento é onde o vibe coder trava?

A dor em uma frase: a IA inventa endpoint, manda valor em reais onde a API espera centavos e libera acesso quando o usuário volta da página de obrigado, e você só descobre na primeira venda que não foi paga.

A maioria das ferramentas de IA aprendeu pagamento lendo a documentação do Stripe. Quando você pede "integra Pix", ela chuta um contrato que não existe, ou puxa um tutorial antigo. O resultado é uma tarde de erros 404 e 422 que você não sabe ler.

A feature que resolve: a referência da API escrita para máquina. O llms.txt do HeroPay traz autenticação, ambientes, todos os grupos da API, valores em centavos, paginação, gatilhos de webhook e as pegadinhas documentadas (como o gatilho payment_credit_cart_refused, com "cart"). As docs abertas em docs.heropay.tech trazem cada endpoint com exemplo, para a IA conferir o contrato em vez de adivinhar. E o sandbox é idêntico à produção, então o que funcionou no teste é o que roda no ar.

A conta em reais. Cada semana que o app fica sem cobrar é receita zero. Se 30 pessoas da sua lista de espera pagariam R$ 49,90 por mês, uma semana de integração travada adia R$ 1.497 de receita mensal recorrente (exemplo ilustrativo: troque pelos seus números). Com o prompt pronto abaixo, a integração no sandbox cabe numa tarde.

O prompt pronto para qualquer ferramenta de IA

Funciona em Claude, ChatGPT, Cursor, Lovable, v0, Bolt e outros. Cole como está e troque só o que está entre colchetes. Para instruções específicas de cada ferramenta (onde ficam os segredos, como publicar a função), veja Lovable, v0 e Bolt, Cursor e Claude.

Leia https://heropay.tech/llms.txt e use como referência única da API HeroPay. Não invente endpoints nem campos que não estejam lá. Se algo faltar, pare e me pergunte.

O QUE VENDO
- Produto: [ex.: "Plano Pro mensal do meu app de roteiros de viagem"]
- Preço: [ex.: R$ 49,90]
- Tipo: [pagamento único | assinatura mensal]
- Métodos: Pix, cartão em até [12]x e boleto

REGRAS DE SEGURANÇA (não negociáveis)
1. A chave HEROPAY_API_KEY e a URL base HEROPAY_API_URL ficam só em variáveis de ambiente do servidor. Nunca no código do navegador, nunca com prefixo VITE_ ou NEXT_PUBLIC_, nunca no repositório, nunca em log.
2. O preço vive numa tabela "products" no banco. O navegador manda só o identificador do produto. Nunca aceite preço vindo do cliente.
3. Valores em centavos, inteiros: R$ 49,90 é 4990. O mínimo da API é 500.
4. Quem marca um pedido como pago é o webhook, nunca o retorno do usuário à página de obrigado.

O QUE CONSTRUIR
A. Tabela "orders": id, user_id, product_key, amount_cents, status (pending, paid, refunded, canceled), checkout_url, paid_at, created_at. O usuário só lê os próprios pedidos e nunca escreve em status, amount_cents ou paid_at.
B. Rota de servidor "create-checkout": exige usuário logado, recebe product_key, busca o preço no banco, cria um pedido pending e chama POST {HEROPAY_API_URL}/payment_links com os headers Authorization: Bearer {HEROPAY_API_KEY}, Accept: application/vnd.herospark.com; version=1 e Content-Type: application/json. No corpo, dentro de "payment_link": name, price_cents, max_installments, payment_methods ["pix","credit_card","bank_slip"], absorbs_fees true e src igual ao id do pedido. Se for assinatura, inclua period "monthly". Salve data.offer.url em checkout_url e devolva ao navegador só essa URL e o id do pedido.
C. Página do pedido: mostra "Aguardando pagamento" enquanto status = pending e atualiza sozinha. Libera o acesso só quando status = paid.
D. Rota pública "heropay-webhook", só POST: valide o header X-HeroPay-Signature, que é o HMAC SHA-256 do corpo BRUTO da requisição com o segredo HEROPAY_WEBHOOK_SECRET, usando comparação em tempo constante e o formato do valor descrito na documentação de webhooks. Assinatura inválida: responda 401 e não faça nada. Leia cart.src para achar o pedido. Em spark_payment_confirmed, marque paid só se o valor bater e só se ainda estiver pending (idempotente, o retry pode repetir o evento). Em refunded ou chargeback_request, marque refunded e revogue o acesso. Responda 200 rápido.

ENTREGA
Liste os arquivos criados, mostre a URL pública do webhook e um comando curl para eu registrar o webhook no sandbox (POST {HEROPAY_API_URL}/webhook). Depois, rode a checagem: procure HEROPAY_API_KEY fora do código de servidor e me diga onde encontrou (a resposta certa é "em nenhum lugar").

O prompt é deliberadamente chato nas regras de segurança. É ali que o código gerado por IA costuma falhar, e é o assunto da próxima dor.

O código de pagamento que a IA gerou é seguro?

A dor em uma frase: o código que a IA escreveu funciona, mas você não sabe se ele deixa alguém comprar seu plano por R$ 5, ler as vendas da sua conta ou forjar um pagamento.

Não é paranoia. O relatório de segurança de código gerado por IA da Veracode (2025), que testou mais de 100 modelos, encontrou falhas de segurança em 45% das tarefas, com risco maior justamente em validação de entrada e referência direta a objetos (Veracode, 2025 GenAI Code Security Report). Em pagamento, esses erros viram dinheiro perdido.

Os três furos mais comuns em integração de pagamento feita por IA:

1. Chave no front. A IA coloca o token num arquivo que vai para o navegador. Qualquer pessoa abre o DevTools e copia.
2. Preço vindo do cliente. A rota aceita price_cents do navegador. Alguém edita a requisição e paga R$ 5 por um plano de R$ 197.
3. Webhook sem validação. A rota que marca pedidos como pagos é pública e não confere de onde veio o evento. Um curl forja o "pago".

A feature que resolve: o HeroPay reduz a superfície de ataque por desenho. O checkout é hospedado, então cartão nunca passa pelo seu código. Os webhooks chegam assinados com X-HeroPay-Signature (HMAC SHA-256 do corpo bruto), com retry automático, e o campo src devolve em cart.src o id do seu pedido, sem casar por e-mail ou valor (segurança).

A validação da assinatura, em Node, fica assim:

import crypto from "node:crypto";

// X-HeroPay-Signature carrega o HMAC SHA-256 do corpo bruto.
// O formato exato do valor (codificação e eventual prefixo) está na
// documentação de webhooks em docs.heropay.tech: passe em `codificacao`
// o que ela indicar e remova o prefixo, se houver, antes de chamar.
export function assinaturaValida(
  corpoBruto: string,
  assinatura: string | null,
  codificacao: BufferEncoding,
): boolean {
  if (!assinatura) return false;
  const esperada = crypto
    .createHmac("sha256", process.env.HEROPAY_WEBHOOK_SECRET!)
    .update(corpoBruto, "utf8")
    .digest();
  const recebida = Buffer.from(assinatura, codificacao);
  return recebida.length === esperada.length && crypto.timingSafeEqual(recebida, esperada);
}

A conta em reais. Se a rota aceita preço do navegador e 50 pessoas descobrem, cada uma pagando R$ 5 por um plano de R$ 197, são R$ 9.600 que não entram (exemplo ilustrativo). Validar o preço no servidor custa uma linha no prompt.

O prompt de auditoria, para rodar depois que a IA terminar

Revise a integração de pagamento deste projeto como um auditor de segurança. Para cada item, responda SIM ou NÃO e mostre o arquivo e a linha:
1. HEROPAY_API_KEY aparece em algum arquivo que vai para o navegador?
2. Alguma rota aceita preço, valor ou desconto vindo do cliente?
3. A rota do webhook valida X-HeroPay-Signature com HMAC SHA-256 do corpo bruto e comparação em tempo constante?
4. O webhook é idempotente (o mesmo evento duas vezes não libera acesso nem crédito em dobro)?
5. Algum ponto libera acesso sem status "paid" gravado pelo webhook?
6. Valores são inteiros em centavos em todo o fluxo?
Corrija o que estiver errado e me mostre o diff.

Como um app feito com IA pluga no HeroPay?

A arquitetura típica tem quatro peças, e as três primeiras cabem num único prompt:

Se o produto for assinatura, acrescente os eventos subscription_activate, subscription_update e subscription_cancel, e o cancelamento pela API em POST /recurring_payment/cancel (assinaturas).

A chamada central que a IA vai escrever:

curl -s -X POST https://api.beta.heropay.tech/payment_links \
  -H "Authorization: Bearer $HEROPAY_API_KEY" \
  -H "Accept: application/vnd.herospark.com; version=1" \
  -H "Content-Type: application/json" \
  -d '{
    "payment_link": {
      "name": "Plano Pro mensal",
      "price_cents": 4990,
      "max_installments": 1,
      "absorbs_fees": true,
      "payment_methods": ["pix", "credit_card", "bank_slip"],
      "period": "monthly",
      "src": "pedido_8f2c"
    }
  }'

A resposta traz data.offer.url, a URL do checkout já com ?src=pedido_8f2c. Esse src volta em cart.src em todos os webhooks daquela compra.

Registrar o webhook no sandbox, um registro por gatilho:

for trigger in spark_payment_confirmed refunded chargeback_request; do
  curl -s -X POST https://api.beta.heropay.tech/webhook \
    -H "Authorization: Bearer $HEROPAY_API_KEY" \
    -H "Accept: application/vnd.herospark.com; version=1" \
    -H "Content-Type: application/json" \
    -d "{\"webhook\":{\"trigger\":\"$trigger\",\"webhook_url\":\"https://SEU-APP/api/heropay-webhook\",\"request_method\":\"post\"}}"
done

Mini-case: do app gerado numa tarde à primeira venda

Um fluxo ilustrativo, sem cliente real por trás. Uma designer cria no Lovable um app que gera roteiros de viagem, e quer cobrar R$ 49,90 por mês pelo plano com roteiros ilimitados.

1. Manhã. Ela cria a conta sandbox no HeroPay, guarda o token nos segredos do Lovable e cola o prompt desta página. O Lovable cria a tabela orders, a função que chama POST /payment_links e a função do webhook.
2. Almoço. Registra os três gatilhos com o curl acima. Clica em "Assinar" no preview, o checkout abre em outra aba, ela paga com os dados de teste. O log da função mostra spark_payment_confirmed chegando com cart.src igual ao id do pedido, e a página muda para "Pagamento confirmado".
3. Tarde. Roda o prompt de auditoria. A IA encontra uma rota antiga que aceitava price_cents do front e corrige. Ela testa o caminho triste: voltar do checkout sem pagar não libera nada.
4. Fim do dia. Troca o token e a URL base pelos de produção, registra os webhooks de novo na API de produção e publica. Sem fila de homologação.

O que ela não precisou fazer: desenhar formulário de cartão, gerar QR Code de Pix, lidar com PCI ou escrever tela de recuperação de carrinho. Tudo isso vem no checkout.

O que quem faz vibe coding usa do HeroPay

O que o HeroPay não tem hoje, dito com clareza: integração nativa com botão "conectar" no Lovable, no v0 ou no Bolt; chave de API restrita por escopo; período de teste (trial) e cobrança por uso nas assinaturas da v1. Se o seu app precisa cobrar por consumo, veja o padrão de créditos em /solucoes/apps-de-ia.

Comece agora

Crie a conta sandbox, cole o llms.txt e o prompt na sua ferramenta de IA e faça a primeira venda de teste hoje. Quando passar no sandbox e na auditoria, troque a chave e vá pro ar.

Criar conta sandbox · Ler a documentação

Continue por aqui: Guia de vibe coding · HeroPay para IA · Lovable · v0 e Bolt · Cursor · Claude · Link de pagamento · Webhooks · Preços · Stripe vs HeroPay · Apps de IA · Glossário