add
Add a second payment provider alongside an existing integration, without touching the one already running.
Compare two or more payment providers head to head for a concrete situation — real fees on a real amount, coverage, onboarding time, and what PagoKit can actually build for each.
> /plugin marketplace add Hainrixz/agente-pagokit > /plugin install pagokit@tododeia
How it fires
How this command gets triggered: by you, by Claude, or both.
/compareContext preview
What this command does when you run it.
Compare two or more payment providers head to head for a concrete situation — real fees on a real amount, coverage, onboarding time, and what PagoKit can actually build for each.
description: Compare two or more payment providers head to head for a concrete situation — real fees on a real amount, coverage, onboarding time, and what PagoKit can actually build for each. argument-hint: "<provider-a> <provider-b> [--country MX] [--amount 500] [--currency MXN]"
Comparisons in blog posts are generic. This one is for **their** situation, with arithmetic.
1. Read the arguments. If country, amount or currency are missing, either infer them from `project-analyzer` or ask once — a comparison without a concrete amount is just a feature table. 2. Run the engine for the situation:
node scripts/advise.js --country <ISO2> --amount <n> --currency <CUR> [--billing ...] [--methods ...]
3. Pull the named providers out of `candidates` **and** `rejected`. A provider that was ruled out is often the most useful row in the table — say which filter removed it. 4. Read `skills/payment-advisor/data/providers/<id>.json` for each one, for the detail the index does not carry.
<A> vs <B> — selling from <country>, charging <amount> <currency>
<A> <B>
Cost per charge <fee.explanation> <fee.explanation>
You receive <net> <net>
Buyer coverage ... ...
Subscriptions ... ...
Merchant of record ... ...
Onboarding <model>, ~<days> days ...
PagoKit can <integration_level> <integration_level>
Notification model <webhook | ...> ...
Settlement <payout_delay_days> ...
Where they actually differ:
• <the one or two things that would change the decision>
Ruled out for your situation:
• <name> — <filter>: <reason>Lead with cost, because that is what they came for — but do not stop there. The decision is usually made by something the fee table does not show: an onboarding gate, a missing local rail, a merchant-of-record trade-off, or the fact that one of them will not send you a webhook at all.
actual amount and currency.
onboarding. Show it in the ruled-out list with the reason.
on B" is frequently the deciding factor.
Claude Code plugin that picks and implements the right payment method for your app — from your terminal. 42 providers, 136 payment rails, and deterministic validators that block insecure payment code as it is written.
Repo: Hainrixz/agente-pagokit
Add a second payment provider alongside an existing integration, without touching the one already running.
Show what you can actually use in a given country — providers, local rails, currency exponent, e-invoicing obligation, and whether a local acquirer is required.
Audit an existing PagoKit integration — gitignore, env vars, key prefixes, webhook secret, raw body, replay protection, idempotency, DB schema, minimum events…
Audit a hand-written payment integration and FIX what it finds. Unlike /pagokit:doctor, which is read-only, this one writes.
Migrate from one payment provider to another, keeping the old one running until the new one is proven.
Analyze the current project and generate a production-ready payment integration (frontend + backend + webhook + DB + portal + refund).