Integração

Integre pagamentos pelo Cursor: do prompt ao primeiro Pix pago no sandbox

Integre pagamentos pelo Cursor AI: regra pronta em .cursor/rules, llms.txt, prompt em português e teste no sandbox. Pix e boleto a R$ 0.

3 passos · em minutos
  1. 01token do sandbox
  2. 02link de pagamento
  3. 03webhook confirma

Para integrar pagamentos pelo Cursor AI, você coloca a referência do HeroPay dentro do projeto (uma regra em .cursor/rules com o contrato da API, o llms.txt salvo no repositório e a documentação em docs.heropay.tech) e pede ao Agent, em português, o fluxo de cobrança. O Cursor escreve a rota que chama POST /payment_links, a página do pedido e o endpoint de webhook que valida a assinatura e libera o acesso. Você testa com curl no sandbox, troca a chave e vá pro ar. Pix e boleto custam R$ 0 por transação; cartão em até 12x.

Resumo

O essencial em 60 segundos

  • O Cursor integra o HeroPay pela API REST pública. O que faz o Agent acertar é a referência no contexto: uma regra em .cursor/rules/heropay.mdc com endpoint, headers, campos e regras de webhook, mais o llms.txt do site salvo no repositório, que aponta para a documentação.
  • A chave de API mora no .env, fora do git. O código lê a chave só no servidor.
  • A chamada central é POST /payment_links: devolve a URL de um checkout pronto com Pix, boleto e cartão. Valores sempre em centavos (19700 = R$ 197,00), mínimo R$ 5,00.
  • Pagamento se confirma por webhook assinado (X-HeroPay-Signature, HMAC SHA-256 do corpo), nunca pelo redirect da página de obrigado. Confie no evento, não na volta do navegador.
  • Sem referência no contexto, o Cursor tende a inventar endpoint no formato de outro gateway. Com a regra, ele usa os campos reais.
  • Para testar contra a API de verdade, o Agent roda curl no terminal integrado, com a sua aprovação. O MCP server do HeroPay está em desenvolvimento e não é necessário para nada nesta página.
  • Preço: Pix R$ 0, boleto R$ 0, cartão 3,49% por transação aprovada. Sem mensalidade, ativação ou mínimo (preços).

Como integrar pagamentos no Cursor com o HeroPay?

São sete passos. O exemplo usa Next.js (App Router), a stack mais comum em projeto aberto no Cursor, mas o prompt pede para o Agent seguir a stack que encontrar no repositório.

Passo 1: crie a conta sandbox e guarde a chave no .env

Acesse app.heropay.tech, crie a conta e copie o token de API nas configurações. O token é um Bearer JWT. No sandbox a URL base é https://api.beta.heropay.tech; em produção, https://api.heropay.tech.

Na raiz do projeto, crie ou edite o .env (ou .env.local, no Next.js):

HEROPAY_API_KEY=seu-token-do-sandbox
HEROPAY_API_URL=https://api.beta.heropay.tech
HEROPAY_WEBHOOK_SECRET=segredo-de-assinatura-do-webhook

E garanta que ele está fora do git antes de qualquer commit:

grep -qxF '.env*' .gitignore || echo '.env*' >> .gitignore
git check-ignore -v .env   # precisa imprimir a regra; se não imprimir, o arquivo vai para o repositório

Não cole o token no chat do Cursor. Tudo que você escreve na conversa pode acabar em código gerado, em log ou em histórico.

Passo 2: coloque o llms.txt dentro do repositório

O llms.txt do HeroPay (heropay.tech/llms.txt) é um arquivo de texto feito para IAs: resume o HeroPay, lista as páginas do site com descrição e aponta para a documentação da API. Salve uma cópia no projeto para o Cursor ter o mapa sempre à mão:

mkdir -p docs/heropay
curl -sL https://heropay.tech/llms.txt -o docs/heropay/llms.txt

Por que baixar em vez de só colar o link: dentro do repositório, o arquivo pode ser citado com @docs/heropay/llms.txt no chat e referenciado pela regra do passo 3, e fica versionado junto com o código. Atualize com o mesmo curl de vez em quando.

A referência de cada endpoint (campos, respostas, erros) está em docs.heropay.tech. Quando o Agent precisar de um endpoint que não está na regra, abra a página certa da documentação e cole o trecho no chat ou salve em docs/heropay/, em vez de deixar o modelo adivinhar.

Passo 3: crie a regra do HeroPay em .cursor/rules

Regras são instruções que o Cursor injeta no contexto do Agent. O formato atual é um arquivo .mdc dentro de .cursor/rules/, com frontmatter que define quando a regra entra. Crie .cursor/rules/heropay.mdc e cole o bloco inteiro. É ele que carrega o contrato da API:

---
description: Integração de pagamentos com a API HeroPay (links de pagamento, Pix, boleto, cartão, webhooks). Use sempre que o pedido envolver cobrança, checkout, pagamento, assinatura ou webhook.
globs: ["**/*heropay*", "**/payments/**", "**/checkout/**", "**/webhooks/**"]
alwaysApply: false
---

# HeroPay: regras de integração

Referências: esta regra, @docs/heropay/llms.txt e a documentação em https://docs.heropay.tech.
Nunca invente endpoint, campo ou gatilho que não esteja nesta regra ou na documentação. Se algo não estiver lá, pare e pergunte.

## Ambiente
- URL base vem de HEROPAY_API_URL (sandbox: https://api.beta.heropay.tech; produção: https://api.heropay.tech).
- Token vem de HEROPAY_API_KEY. Segredo do webhook vem de HEROPAY_WEBHOOK_SECRET.
- Essas variáveis só são lidas no servidor (route handler, API route, server action, função serverless).
- Nunca use prefixo NEXT_PUBLIC_, VITE_ ou similar nelas. Nunca escreva o valor em código, teste, fixture, log ou commit.

## Toda requisição
- Authorization: Bearer ${HEROPAY_API_KEY}
- Accept: application/vnd.herospark.com; version=1   (sempre fixe version=1)
- Content-Type: application/json

## Cobrança
- Crie cobrança com POST /payment_links e corpo { "payment_link": { ... } }.
- Campos obrigatórios: absorbs_fees (boolean) e price_cents (inteiro).
- price_cents é inteiro em centavos: R$ 197,00 = 19700. Mínimo 500. Nunca float, nunca reais.
- absorbs_fees false repassa os juros do parcelamento ao comprador; true faz o vendedor absorver (venda sem juros).
- max_installments de 1 a 12; cada parcela precisa ter pelo menos R$ 1,99.
- payment_methods aceita "pix", "bank_slip", "credit_card".
- Mande src = id do pedido interno. Ele volta em cart.src em todos os webhooks da compra.
- src aceita só letras, números e . _ - ~ (máx. 255).
- A URL do checkout é data.offer.url. O id do link é data.id.
- O preço vem do banco/servidor. Nunca aceite price_cents vindo do cliente.
- POST /payment_links não é idempotente: grave o id retornado antes de qualquer nova tentativa.

## Webhook
- Cadastro: POST /webhook com { "webhook": { "trigger", "webhook_url", "request_method": "post" } }. Um cadastro por gatilho, com a URL /api/webhooks/heropay/<gatilho>.
- Gatilhos: spark_payment_confirmed, payment_pix_created, spark_payment_boleto_created,
  payment_credit_cart_refused (grafia com "cart"), refunded, chargeback_request,
  subscription_activate, subscription_update, subscription_cancel.
- Valide o header X-HeroPay-Signature: HMAC SHA-256 do CORPO BRUTO com HEROPAY_WEBHOOK_SECRET, comparação em tempo constante. Confira na documentação o formato da assinatura (hex ou base64). Assinatura inválida: 401.
- Leia o corpo cru antes de fazer parse de JSON (no Next.js: await request.text()).
- Seja idempotente: deduplique por id do pagamento + gatilho; a retentativa automática pode entregar o mesmo evento mais de uma vez.
- Responda 2xx rápido; trabalho pesado vai para fila.
- Liberação de acesso acontece SÓ no webhook spark_payment_confirmed. Nunca pelo redirect da página de obrigado.

## Testes contra a API
- Só com a chave de sandbox. Use curl lendo $HEROPAY_API_KEY do ambiente; nunca escreva o valor no comando.
- Pergunte antes de cadastrar webhook ou de chamar qualquer endpoint que não seja de leitura.

## Proibido
- Criar formulário próprio de cartão (o checkout hospedado cuida disso e do PCI).
- Polling na API para saber se pagou. Confie no evento, não no polling.

Três detalhes dessa regra. alwaysApply: false com description faz o Agent puxar a regra quando o assunto é pagamento, sem gastar contexto no resto do trabalho; globs anexa a regra automaticamente quando você edita arquivos de pagamento. E a linha @docs/heropay/llms.txt inclui o arquivo do passo 2 no contexto sempre que a regra entra.

Projeto antigo com .cursorrules na raiz? Esse formato ainda funciona, mas o Cursor o trata como legado e não o cita mais na documentação de regras (verificado em set/2026). Se preferir mantê-lo, cole o mesmo conteúdo sem o bloco de frontmatter (as linhas entre ---). Para projetos que também rodam no Claude Code ou no Codex, o Cursor lê AGENTS.md na raiz: dá para manter uma versão sem frontmatter lá e servir às três ferramentas.

Passo 4: confirme a chave com um curl no terminal do Cursor

Antes de pedir código, prove que a chave e os headers estão certos. No terminal integrado (ou pedindo ao Agent para rodar, com a sua aprovação):

set -a; source .env; set +a

curl -s -X POST "$HEROPAY_API_URL/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":"Teste Cursor","description":"Link de teste","price_cents":500,"absorbs_fees":false,"max_installments":1,"payment_methods":["pix","credit_card","bank_slip"],"src":"teste-local"}}'

A resposta 201 traz data.offer.url, o checkout pronto. 401 é chave ausente ou sem Bearer; 422 costuma ser valor abaixo de 500 centavos. Guarde essa resposta: é o exemplo real que o Agent vai usar para confirmar os nomes dos campos.

O comando usa $HEROPAY_API_KEY, que o shell expande. O valor não aparece no comando nem precisa entrar no chat.

Passo 5: mande o prompt pronto no Agent

Abra o chat do Cursor no modo Agent, com o projeto aberto, e cole o prompt inteiro. Troque só o que está entre colchetes.

Integre pagamentos neste projeto usando a API HeroPay.
Referências: a regra @heropay, @docs/heropay/llms.txt e a documentação em https://docs.heropay.tech. Não invente endpoint nem campo fora delas; se faltar algo, pare e me pergunte.

Antes de escrever código, leia o projeto e me diga em 5 linhas: framework, onde ficam as rotas de servidor, qual banco/ORM é usado, como funciona a autenticação e onde ficam as variáveis de ambiente. Siga essa stack; não instale framework novo.

CONTEXTO DO PRODUTO
- O que vendo: [ex.: "Plano Pro anual do meu SaaS de agendamento"]
- Preço: [ex.: R$ 197,00]
- Parcelamento no cartão: até [12]x
- Métodos: Pix, cartão e boleto

1. BANCO
- Tabela/modelo "products": product_key (único), name, description, price_cents (inteiro). Cadastre o produto acima numa seed.
- Tabela/modelo "orders": id (uuid), user_id, product_key, amount_cents (inteiro), status (pending | paid | refunded | canceled, padrão pending), checkout_url, heropay_payment_link_id (inteiro), paid_at (nulo), created_at.
- Tabela "webhook_events": chave única (payment_id + trigger) para deduplicar eventos.
- Gere a migration no padrão do projeto.

2. ROTA "criar checkout" (servidor)
- Exige usuário autenticado. Recebe apenas product_key; nunca aceite preço do cliente.
- Busca o preço em products, cria o pedido pending.
- Chama POST ${HEROPAY_API_URL}/payment_links com os headers da regra e o corpo:
  { "payment_link": { "name", "description", "price_cents", "absorbs_fees": false,
    "max_installments": [12], "payment_methods": ["pix","credit_card","bank_slip"],
    "src": "<id do pedido>" } }
- Salva data.id em heropay_payment_link_id e data.offer.url em checkout_url.
- Devolve ao front só checkout_url e o id do pedido.
- Em erro da API: mensagem amigável ao usuário e o corpo do erro no log do servidor (sem o token).
- Crie um cliente HTTP pequeno em lib/heropay (ou equivalente na stack) que lê HEROPAY_API_URL e HEROPAY_API_KEY e monta os headers. Nada de chave fora dele.

3. FRONT
- Botão "Comprar" na página do produto: chama a rota acima e redireciona para checkout_url.
- Página /pedido/[id]: mostra "Aguardando pagamento" enquanto status = pending e atualiza a cada 5 segundos consultando o NOSSO backend (não a API HeroPay). Quando status = paid, mostra "Pagamento confirmado" e libera o acesso.
- Voltar do checkout não libera nada. Quem libera é o status paid gravado pelo webhook.

4. ROTA "webhook HeroPay" (servidor, pública, só POST) em /api/webhooks/heropay/[trigger]
- Leia o corpo BRUTO antes do parse. Valide X-HeroPay-Signature: HMAC SHA-256 do corpo bruto com HEROPAY_WEBHOOK_SECRET, comparação em tempo constante. Confira na documentação se a assinatura vem em hex ou base64; se não estiver claro, aceite os dois e me avise. Inválido: 401.
- Deduplique em webhook_events; evento repetido responde 200 sem efeito.
- Encontre o pedido por cart.src.
- spark_payment_confirmed: marque paid e grave paid_at, só se o valor pago bater com amount_cents (confira na documentação o campo de valor e se vem em reais ou centavos) e o pedido ainda estiver pending.
- refunded ou chargeback_request: marque refunded e revogue o acesso.
- cart.src desconhecido: registre no log e responda 200. Responda 2xx rápido.

5. TESTES
- Teste automatizado da validação de assinatura (válida, inválida, ausente) e da idempotência (mesmo evento duas vezes, uma liberação só), no framework de teste que o projeto já usa. Nenhum teste chama a API real.

6. ENTREGA
- Rode os testes e o lint do projeto.
- Me mostre a lista de arquivos criados/alterados e confirme que HEROPAY_API_KEY não aparece fora de lib/heropay e do .env.
- Não cadastre webhook sem me perguntar. Não crie nada fora do que foi pedido.

Dica de revisão: peça ao Agent para fazer o plano antes de editar ("mostre o plano, não edite ainda") quando o projeto for grande. Pagamento é o tipo de mudança em que ler o diff arquivo por arquivo vale o minuto extra.

Passo 6: teste no sandbox

  1. Exponha o localhost. O webhook precisa de uma URL pública. No terminal integrado do Cursor, rode um túnel (ngrok, cloudflared ou similar) apontando para a porta do app e copie a URL HTTPS gerada.
  2. Cadastre o webhook, um por gatilho:
TUNEL="https://SEU-TUNEL"
for trigger in spark_payment_confirmed refunded chargeback_request; do
  curl -s -X POST "$HEROPAY_API_URL/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\":\"$TUNEL/api/webhooks/heropay/$trigger\",\"request_method\":\"post\"}}"
done
  1. Copie o segredo de assinatura do webhook, exibido no painel, para HEROPAY_WEBHOOK_SECRET no .env e reinicie o servidor de desenvolvimento.
  2. Compre. Clique em Comprar, confira o pedido pending no banco e faça uma compra de teste no checkout do sandbox.
  3. Veja o evento chegar. No log do servidor, o spark_payment_confirmed passa pela validação e o pedido vira paid; a página /pedido/[id] atualiza sozinha.
  4. Teste o caminho triste. Mande ao endpoint um POST com assinatura errada (tem que dar 401), reenvie o mesmo evento (tem que dar 200 sem liberar de novo) e volte do checkout sem pagar (nada é liberado).
  5. Confira na API. Peça ao Agent para rodar um curl em GET /sales/unitary no sandbox e mostrar a última venda. A compra de teste aparece com os dados da API, o que prova que banco, webhook e API contam a mesma história.

Passo 7: troque a chave e vá pro ar

No ambiente de produção do seu deploy (Vercel, Render, Fly, servidor próprio), cadastre HEROPAY_API_KEY com o token de produção, HEROPAY_API_URL=https://api.heropay.tech e o HEROPAY_WEBHOOK_SECRET de produção. Cadastre os webhooks de novo, agora na API de produção e com a URL pública do app. Sem fila de homologação: o código que passou no sandbox é o que roda em produção.

No .env local, mantenha a chave de sandbox. A de produção fica só no ambiente de deploy.

O que o Cursor vai gerar?

Com o prompt acima num projeto Next.js, o Agent monta estas peças. Vale saber o que cada uma faz para revisar o diff antes do commit.

PeçaOnde rodaO que faz
Migration de products, orders e webhook_eventsBancoGuarda preço no servidor, status do pedido e eventos já processados
lib/heropay.tsServidorÚnico lugar que lê o token e monta Authorization + Accept
app/api/checkout/route.tsServidorChama POST /payment_links e devolve data.offer.url
app/pedido/[id]/page.tsxFrontMostra "aguardando" e vira "confirmado" quando o banco muda
app/api/webhooks/heropay/[trigger]/route.tsServidorValida X-HeroPay-Signature, deduplica e marca o pedido como pago
Testes de assinatura e idempotênciaCIGarante que um "pago" forjado ou repetido não libera acesso

O webhook é a peça que mais importa revisar. Ele deve ficar parecido com isto:

// app/api/webhooks/heropay/[trigger]/route.ts
import crypto from "node:crypto";

function signatureOk(raw: string, received: string, secret: string) {
  const hmac = () => crypto.createHmac("sha256", secret).update(raw);
  // confira o formato (hex ou base64) na documentação de webhooks e mantenha só o certo
  const expected = [hmac().digest("hex"), hmac().digest("base64")];
  const r = Buffer.from(received);
  return expected.some((e) => {
    const b = Buffer.from(e);
    return r.length === b.length && crypto.timingSafeEqual(r, b);
  });
}

export async function POST(
  request: Request,
  { params }: { params: Promise<{ trigger: string }> },
) {
  const raw = await request.text(); // corpo bruto, antes do JSON.parse
  const received = request.headers.get("x-heropay-signature") ?? "";
  if (!signatureOk(raw, received, process.env.HEROPAY_WEBHOOK_SECRET!)) {
    return new Response("invalid signature", { status: 401 });
  }

  const { trigger } = await params;
  const event = JSON.parse(raw);
  const orderId = event.cart?.src; // o src que você mandou no POST /payment_links
  // 1) deduplicar (payment id + trigger) em webhook_events
  // 2) spark_payment_confirmed: pending -> paid, se o valor bater
  // 3) refunded / chargeback_request: revogar acesso
  return new Response("ok", { status: 200 });
}

O truque está no src. O valor que você manda na criação do link é salvo no carrinho e volta em cart.src em todos os webhooks daquela compra. Mandando o id do pedido, o webhook sabe exatamente qual linha atualizar, sem casar por e-mail ou valor.

Regra no repositório ou referência colada no chat: quando usar cada um?

Os dois caminhos ensinam a IA a trabalhar com o HeroPay; a diferença é quanto tempo o ensinamento dura.

Regra + llms.txt no repositórioReferência colada no chatLink de pagamento sem código
Serve paraIntegrar no codebase que vai para produçãoUma integração pontual ou um projeto descartávelValidar se alguém paga antes de escrever código
O que a IA sabeContrato fixo no repositório, versionadoReferência só enquanto a conversa durarNada; você cola a URL do link
Risco de alucinar endpointBaixo: a regra entra sozinha em arquivos de pagamentoMédio: some quando o chat fica longo ou você abre outroNenhum
Time inteiro se beneficiaSim: .cursor/rules e docs/heropay vão para o gitNão: cada pessoa repete o processoNão se aplica
Configuração2 arquivosZeroZero
Liberação automática de acessoSim, pelo webhookSim, pelo webhookNão; manual

Resumo prático: projeto que vai para produção, com mais de uma pessoa ou que vai viver mais de uma semana, use a regra. Protótipo de fim de semana, cite @docs/heropay/llms.txt e cole o bloco "Cobrança" da regra na mensagem. Ainda sem código nenhum, comece pelo link.

Quais são as armadilhas mais comuns ao integrar pagamento pelo Cursor?

O Cursor inventar endpoint sem a referência no contexto

É a armadilha número um e é específica de IA de código. Sem a referência, o modelo completa com o que viu mais vezes no treino: POST /v1/charges, amount em vez de price_cents, Idempotency-Key que a API v1 não tem, evento payment.succeeded. O código compila, parece certo e quebra na primeira chamada com 404 ou 422.

Como evitar: a regra do passo 3 e a frase "se não estiver lá, pare e pergunte". Depois que o Agent gerar o código, peça: "Liste todo endpoint e campo HeroPay usado no projeto e mostre a linha da regra ou a página da documentação que documenta cada um". O que não tiver fonte correspondente foi inventado.

Chave no .env que vai parar no git

O .env fora do .gitignore é o jeito mais comum de vazar token em repositório público, e um commit antigo continua no histórico mesmo depois que você apaga o arquivo. Rode o git check-ignore -v .env do passo 1 antes do primeiro commit. Se o token já foi para o repositório, apagar o arquivo não resolve: regenere o token no painel na hora e atualize o .env.

Variante da mesma armadilha: token escrito direto num script de teste ou num exemplo de curl versionado. Use sempre $HEROPAY_API_KEY.

Chave exposta no front

No Next.js, qualquer variável com prefixo NEXT_PUBLIC_ vai para o bundle que o navegador baixa; no Vite, o prefixo é VITE_. Com o token, alguém cria links, lê suas vendas e consulta seu saldo. Peça ao Cursor: "Procure HEROPAY_API_KEY fora de lib/heropay e do .env". A resposta certa é nenhuma.

Valor em reais onde a API espera centavos

price_cents é inteiro em centavos: R$ 197,00 é 19700. Mandar 197 cria um link de R$ 1,97, abaixo do mínimo de R$ 5,00, e a API responde 422. Mandar 197.00 como float também dá problema. A regra do passo 3 já cobre isso, mas vale conferir no diff.

Confirmar pelo redirect e não pelo webhook

Voltar para a página de obrigado não prova pagamento: o Pix pode ser pago minutos depois no celular, o usuário pode fechar a aba, e qualquer um digita a URL de sucesso. A única fonte de verdade é o spark_payment_confirmed chegando assinado. Confie no evento, não no redirect.

Webhook que faz parse antes de validar

O HMAC é calculado sobre o corpo bruto. Se o código faz request.json() e depois JSON.stringify para validar, espaços e ordem de chaves mudam e a assinatura nunca bate, o que leva a desligar a validação "só para testar". Leia com request.text(), valide, e só então faça o parse.

Webhook sem idempotência

A retentativa automática pode entregar o mesmo evento mais de uma vez. Sem a tabela de eventos processados, o cliente recebe dois e-mails de boas-vindas ou dois créditos. Deduplique por id do pagamento + gatilho.

Dá para cobrar sem escrever código?

Dá. Se você só quer validar se alguém paga:

  1. No painel, crie um link de pagamento com nome, preço e métodos. Ou peça ao Agent para rodar o curl do passo 4 com o seu preço e src landing.
  2. Peça ao Cursor: "Adicione um botão Comprar na página de preços que abre [URL do link]".
  3. Acompanhe as vendas no painel.

Para cobrar gente de verdade, o link precisa ser criado com a chave de produção. O limite desse caminho: o app não sabe quem pagou. Você libera acesso manualmente ou, quando as vendas começarem, evolui para o fluxo com webhook desta página.

Por que Pix a R$ 0 importa para quem constrói SaaS no Cursor?

Porque boa parte dos projetos que nascem no Cursor são micro-SaaS com ticket baixo, e em ticket baixo a taxa fixa por transação come a margem antes do percentual. Em 500 vendas de R$ 49 no Pix por mês, o HeroPay cobra R$ 0. No cartão, a mesma venda de R$ 49 custa 3,49%, ou R$ 1,71 por transação. Empurrar o Pix com um desconto à vista deixa de ser custo para você e vira argumento de venda. Tabela completa e comparação com outros gateways em preços.

Honestidade: Mercado Pago, AbacatePay, Asaas e Efí já publicam servidores MCP que funcionam no Cursor (verificado em set/2026, fontes no ANEXO 2); o do HeroPay está em desenvolvimento. A diferença está no que vem atrás da integração: Pix e boleto a R$ 0, checkout com parcelamento, 2 cartões, order bump e upsell, e webhooks assinados com HMAC. Compare em Asaas vs HeroPay e AbacatePay vs HeroPay.

O que o HeroPay ainda não tem no Cursor

  • Não existe extensão, botão "conectar" nem MCP server publicado do HeroPay no Cursor; a integração é por regra, llms.txt, documentação e API. O MCP está em desenvolvimento.
  • O token de API é único por conta; não há chave restrita por escopo nem OAuth. Por isso a chave de produção não deve circular no terminal de desenvolvimento.
  • A API v1 não tem header Idempotency-Key: duas chamadas iguais a POST /payment_links criam dois links. O prompt manda gravar o id antes de repetir.
  • Não há SDK oficial publicado; o Cursor escreve um cliente HTTP de poucas linhas, como no prompt. A documentação traz exemplos em 18 linguagens.

Perguntas frequentes

Como configurar MCP no Cursor?

Crie o arquivo .cursor/mcp.json na raiz do projeto (vale só para ele) ou ~/.cursor/mcp.json (vale para todos). Dentro, um objeto mcpServers com o nome do servidor e como iniciá-lo: command e args para servidor local, ou url e headers para servidor remoto. Segredos entram por envFile ou pela sintaxe ${env:NOME}. Para integrar o HeroPay você não precisa de MCP: o servidor do HeroPay está em desenvolvimento, e a integração funciona hoje com a regra em .cursor/rules e a API REST.

O HeroPay tem MCP server para o Cursor?

Ainda não publicado: o MCP server do HeroPay está em desenvolvimento. A integração não depende dele. A regra em .cursor/rules leva o contrato da API para o Agent, o llms.txt e a documentação completam a referência, e o Agent roda no terminal integrado os curl de teste que você aprovar: criar um link no sandbox, cadastrar o webhook, consultar vendas. Quando o MCP for publicado, o anúncio sai na página de IA e na documentação.

O que o llms.txt do HeroPay faz no Cursor?

O heropay.tech/llms.txt é um arquivo de texto feito para IAs: resume o HeroPay, lista as páginas do site com descrição e aponta para a documentação da API em docs.heropay.tech. Salvo em docs/heropay/llms.txt e citado pela regra, ele dá ao Agent o mapa de onde buscar cada informação. O contrato que mais importa (endpoint, headers, centavos, webhook assinado) fica escrito na própria regra, para o modelo não depender de adivinhação.

O .cursorrules ainda funciona?

Funciona, mas é o formato legado. O formato atual são arquivos .mdc em .cursor/rules/, com frontmatter que define quando a regra entra: sempre, por decisão do Agent a partir da descrição, por padrão de arquivo (globs) ou só quando você a cita com @. A documentação de regras do Cursor não cita mais o .cursorrules (verificado em set/2026). Se você tem um, a migração é copiar o conteúdo para .cursor/rules/heropay.mdc e acrescentar o frontmatter. Para compartilhar instruções com Claude Code e Codex, o Cursor também lê AGENTS.md na raiz.

Por que o Cursor inventa endpoint de pagamento?

Porque, sem a referência no contexto, o modelo completa com o padrão que viu mais vezes, geralmente o de gateways internacionais: amount em vez de price_cents, /v1/charges, eventos com nomes de outra API. O código parece certo e falha na primeira chamada. A correção é uma regra no repositório com o contrato real e a ordem de parar e perguntar quando faltar algo. Depois, peça ao Agent para listar cada endpoint usado com a linha da regra ou a página da documentação que o documenta. O que ficar sem fonte foi inventado.

Onde guardo a chave de API do HeroPay num projeto do Cursor?

No .env (ou .env.local) na raiz, com o arquivo listado no .gitignore. Confirme com git check-ignore -v .env antes do primeiro commit. O código lê a chave só no servidor, num único módulo como lib/heropay. Nunca use prefixo NEXT_PUBLIC_ ou VITE_, que expõe a variável no navegador, e nunca cole a chave no chat. Nos testes com curl, use $HEROPAY_API_KEY em vez do valor. Vazou? Regenere o token no painel na hora.

Como testar o webhook do HeroPay rodando localmente no Cursor?

Exponha a porta do app com um túnel (ngrok, cloudflared ou similar) no terminal integrado e cadastre a URL pública gerada com POST /webhook no sandbox, um cadastro por gatilho. Copie o segredo de assinatura exibido no painel para HEROPAY_WEBHOOK_SECRET, faça uma compra de teste e acompanhe o evento no log do servidor. Teste também uma assinatura errada, que precisa dar 401, e o mesmo evento duas vezes, que não pode liberar acesso em dobro.

Quanto custa integrar pagamentos pelo Cursor com o HeroPay?

O HeroPay não cobra pelo llms.txt, pela documentação nem pelo sandbox. Você paga por transação aprovada: Pix R$ 0, boleto R$ 0 e cartão 3,49%, em até 12x. Sem mensalidade, taxa de ativação ou volume mínimo. Numa venda de R$ 97 no cartão, a tarifa fica em cerca de R$ 3,39; no Pix, R$ 0. O Cursor tem planos próprios, com regras de uso definidas pela empresa; integrar o HeroPay não muda o que você paga a ele. Veja a conta por método em preços.

Dá para criar assinatura recorrente pelo Cursor?

Dá. Peça ao Agent para mandar period (monthly, quarterly, semiannual ou annual) no POST /payment_links; com frequency_type: "limited" e frequency_limit, a assinatura encerra sozinha após o número de ciclos. A recorrência aceita cartão, boleto e Pix, e a assinatura via Pix usa o Pix Automático: o comprador autoriza uma vez e as cobranças seguintes caem sozinhas. Acrescente ao prompt o tratamento dos gatilhos subscription_activate, subscription_update e subscription_cancel para o app acompanhar o ciclo de vida. Detalhes em assinaturas.

O Cursor consegue criar cobranças de verdade na minha conta?

Consegue, se a chave de produção estiver no ambiente em que o Agent roda comandos. Por isso a recomendação é deixar só a chave de sandbox no .env local e a de produção só no deploy. Criar um link não cobra ninguém: se o valor saiu errado, você exclui o link e cria outro. Mesmo assim, aprove cada comando manualmente e confira o price_cents antes. O token também autoriza saque e estorno pela API, então nenhum comando contra a API de produção deve rodar no editor sem você ler antes.

O mesmo passo a passo serve para Claude Code, Codex ou Windsurf?

Serve, com ajustes de arquivo. O llms.txt no repositório, o conteúdo da regra e o prompt são os mesmos. Muda onde a regra mora: no Claude Code, em CLAUDE.md; no Codex, em AGENTS.md, que o Cursor também lê. Veja a integração com o Claude Code. Para Lovable, onde não há repositório local, veja o guia de Lovable.

Comece agora

Crie a conta sandbox, salve o llms.txt no projeto, cole a regra e o prompt, e faça a primeira venda de teste em minutos. Sem fila de homologação: quando passar no sandbox, troque a chave e vá pro ar.

Conecte e cobre em minutos

Sandbox grátis, docs abertas e llms.txt para a sua ferramenta de IA.

Pix e boleto R$ 0 · cartão 3,49% em até 12x · saque sem tarifa