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.
Criar conta sandbox Ler a documentação
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.mdccom endpoint, headers, campos e regras de webhook, mais ollms.txtdo 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
curlno 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-webhookE 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órioNã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.txtPor 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
- 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.
- 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- Copie o segredo de assinatura do webhook, exibido no painel, para
HEROPAY_WEBHOOK_SECRETno.enve reinicie o servidor de desenvolvimento. - Compre. Clique em Comprar, confira o pedido
pendingno banco e faça uma compra de teste no checkout do sandbox. - Veja o evento chegar. No log do servidor, o
spark_payment_confirmedpassa pela validação e o pedido virapaid; a página/pedido/[id]atualiza sozinha. - 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).
- Confira na API. Peça ao Agent para rodar um
curlemGET /sales/unitaryno 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ça | Onde roda | O que faz |
|---|---|---|
Migration de products, orders e webhook_events | Banco | Guarda preço no servidor, status do pedido e eventos já processados |
lib/heropay.ts | Servidor | Único lugar que lê o token e monta Authorization + Accept |
app/api/checkout/route.ts | Servidor | Chama POST /payment_links e devolve data.offer.url |
app/pedido/[id]/page.tsx | Front | Mostra "aguardando" e vira "confirmado" quando o banco muda |
app/api/webhooks/heropay/[trigger]/route.ts | Servidor | Valida X-HeroPay-Signature, deduplica e marca o pedido como pago |
| Testes de assinatura e idempotência | CI | Garante 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ório | Referência colada no chat | Link de pagamento sem código | |
|---|---|---|---|
| Serve para | Integrar no codebase que vai para produção | Uma integração pontual ou um projeto descartável | Validar se alguém paga antes de escrever código |
| O que a IA sabe | Contrato fixo no repositório, versionado | Referência só enquanto a conversa durar | Nada; você cola a URL do link |
| Risco de alucinar endpoint | Baixo: a regra entra sozinha em arquivos de pagamento | Médio: some quando o chat fica longo ou você abre outro | Nenhum |
| Time inteiro se beneficia | Sim: .cursor/rules e docs/heropay vão para o git | Não: cada pessoa repete o processo | Não se aplica |
| Configuração | 2 arquivos | Zero | Zero |
| Liberação automática de acesso | Sim, pelo webhook | Sim, pelo webhook | Nã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:
- No painel, crie um link de pagamento com nome, preço e métodos. Ou peça ao Agent para rodar o
curldo passo 4 com o seu preço esrclanding. - Peça ao Cursor: "Adicione um botão Comprar na página de preços que abre [URL do link]".
- 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 aPOST /payment_linkscriam 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.