agente-pagokit

Why it exists.

Every guide frames payment integration as a choice problem: thirty gateways, pick one.
Choosing takes an afternoon. What takes weeks — and what silently fails in production — is
everything after:

• A webhook that verifies a signature but never checks a timestamp, so a captured event is replayable forever.
• A webhook verified against the API key instead of the signing secret. It fails every event, and the developer goes off to debug the hashing algorithm.
• amount * 100 on a Japanese customer. JPY has no minor unit, so that is a 100× overcharge.
• A refund endpoint on a Pix integration, where refunding a charge is not an operation that exists.
• A payment_intent.succeeded handler that grants access, on a URL anyone can post to.

None of these throw. Most pass code review. PagoKit exists to make them hard to write.

It analyses your project, asks three questions, and generates a vertical-complete integration:
frontend, checkout endpoint, authenticated webhook, database migration, customer portal, refund
path, error mapper, production checklist and an audit trail.

Everything runs locally. No account, no API key, no telemetry. The only network calls are the
ones your generated code makes to your own provider.

Three deterministic engines.

An LLM asked to write payment code produces something plausible. Plausible is exactly the
failure mode that matters here. So the parts that must be correct aren't left to the model —
they're ordinary programs, with tests.

What it knows.

42 providers · 136 payment methods · 74 countries (71 with a local provider) · 106 currencies with their ISO 4217 exponent · 6 webhook verification families in use.

What PagoKit writes for you

What PagoKit knows and recommends, but doesn't write

Another 38 providers with verified catalog data: the advisor compares them, computes their fees and explains their constraints — and tells you plainly that the code is yours to write. They move up to build once their signature scheme is verified and transcribed.

• Wave 1 — Asaas · Bold.co · Conekta · Kushki · Paddle (Paddle Billing) · Polar
• Wave 2 — Culqi · Flow.cl · Pagar.me · Transbank Webpay Plus · dLocal Go
• Wave 3 — Fintoc · Mobbex · Placetopay (Evertec) · Recurrente · ePayco
• Wave 4 — Adyen · GoCardless · Mollie · Redsys (TPV Virtual) · Revolut Merchant (Revolut Business)
• Wave 5 — Airwallex · Antom (Ant International — Alipay+ / Alipay / WeChat Pay acquiring) · Midtrans (GoTo Financial) · PayMongo · Razorpay · Xendit
• Wave 6 — Flutterwave · Paymob · Paystack · Safaricom M-Pesa (Daraja API) · Tap Payments · Yoco
• Wave 7 — Authorize.Net (Visa Acceptance) · Hyperswitch (Juspay) · Lago · RevenueCat · Square

Payment methods, because outside card-mature markets the right question is which rail
you need, not which gateway:

Full country × provider matrix: docs/COVERAGE.md.

What it will and won't build for you.

A wide catalog is only useful if it's honest about its own edges. Every provider carries an
integration level, and the advisor states it every time:

Backing that up is one rule the build enforces:

If a provider's webhook scheme isn't verified against its own documentation
(evidence.confidence != "high"), the generator must not emit a signature verifier.
It emits re-fetch, event-id dedup, and a loud TODO instead.

A verifier built on an unverified scheme is worse than none: it looks correct and accepts
forged events.

How it works.

Installation.

git clone https://github.com/Hainrixz/agente-pagokit ~/agente-pagokit
cd ~/your-project
claude --plugin-dir ~/agente-pagokit

Then run /pagokit:start.

Requires Node.js ≥ 18 and Claude Code 2.x.

Deterministic security.

Security rules aren't advice in a markdown file the model may or may not follow. They're Node
processes wired to Claude Code's hooks. A write that breaks one is denied.

When the tool is wrong and you're right:

// pagokit-ignore: webhook-has-signature -- custom verifier in lib/auth/payments.ts

Every bypass is logged to .pagokit/audit.log, so it's a decision on the record rather than a
silent hole.

Full rule set with enforcement tiers: SECURITY_RULES.md.

Commands.

What gets generated.

For a Next.js App Router + Prisma project:

app/api/checkout/route.ts        Server-side price lookup · UUID idempotency · correct minor units
app/api/webhook/<provider>/      Raw body · signature · replay window · event-id dedup · fast ack
app/api/portal/route.ts          Customer self-service (subscriptions)
app/api/refund/route.ts          Authorisation-checked — or the payout path on irreversible rails
components/CheckoutButton.tsx    Hosted, embedded or widget, per the provider
lib/payments/<provider>.ts       SDK init · API version pinned
lib/payments/errors.ts           Cross-provider error taxonomy · ES/EN
prisma/schema.prisma             payments · subscriptions · customers · idempotency_keys
                                 · webhook_events_processed
payment-page-scripts.json        PCI DSS 4.0.1 §6.4.3 authorised-script inventory
.env.example                     Test-mode values only
PAGOKIT_INTEGRATION.md           Audit trail · events routed · what's still TODO
PAGOKIT_PRODUCTION_CHECKLIST.md  Steps to go live
PAGOKIT_TAX_TODO.md              Only where the market mandates e-invoicing

Other stacks adapt the structure; the guarantees don't change.

Local rails it knows about.

Outside card-mature markets, the rail matters more than the gateway. The advisor recommends the
rail before the provider:

Roadmap.

Waves are ordered by evidence quality × rails unlocked ÷ template cost, not by market size. A
provider whose signature scheme can't be verified isn't a wave item — it's a research ticket.

Development.

npm install
npm run verify            # everything: schemas, integrity invariants, all test suites
npm run generate:all      # regenerate every derived file
./scripts/dev-link.sh /path/to/test-project

Nothing generated is edited by hand. See CONTRIBUTING.md.

Why the file count doesn't explode

Providers differ in a small number of ways, and those ways repeat. Writing one template per
provider makes the file count providers × stacks × billing modes. Writing one fragment per
capability family makes it additive — and adding provider 41 costs a JSON entry plus a
small override, not two dozen documents.

Security.

Found a vulnerability? Please don't open a public issue. Email [email protected] or use
GitHub Security Advisories.
Response within 48 hours. Full policy: SECURITY.md.

Author.

Enrique Rocha · tododeia.com · @soyenriquerocha · [email protected]

AI consulting · agents · automations · sprints in Miami.

If it saved you days, send me a screenshot. If it broke something, open an issue.

MIT · 2026 Enrique Rocha · tododeia.