pagokit

Audits an existing PagoKit integration in the current project against the generated per-provider checklist, so it covers every provider in the catalog rather than a hardcoded few. Checks .gitignore covers .env, that env vars are present and use test-key prefixes, that the webhook secret looks valid, that the webhook handler verifies signatures, that the minimum events for the integrated provider are routed, and that PAGOKIT_INTEGRATION.md exists. Used by /pagokit:doctor. Read-only — never writes files.

Composes a complete payment integration by resolving capability fragments against the chosen provider's catalog entry, then emits a structured file plan for integration-specialist to execute. Selects fragments by verification family, notification model and checkout pattern rather than by provider name, so a provider new to the catalog composes correctly without new templates. Refuses to emit a signature verifier when the provider's scheme is not verified, emitting re-fetch and an explicit TODO instead.

Recommends the single best payment provider for the user's project after a short interactive wizard, then hands off to the implementer. Runs a deterministic local ranking engine instead of scoring by hand, so the same situation always yields the same answer and every rejection has an exact reason. Computes real fees on a concrete transaction, always states whether PagoKit can actually BUILD the integration or only advise on it, discloses when the data was last verified, and refuses sanctioned markets outright. Bilingual ES/EN/PT, language inferred from the user's first prompt.

Plans and executes a migration from one payment provider to another without downtime. Establishes what cannot move (stored card tokens usually cannot), maps the two providers' event vocabularies, flags architectural differences such as a change of notification model or a move to a merchant of record, and sequences a coexistence period rather than an atomic switch. Powers /pagokit:migrate.

Detects a project's technology stack, framework, deploy target, ORM, primary language, and active payment use cases by reading package.json/pyproject.toml/composer.json/Gemfile, schema files, route files, and deploy configs. Use this skill at the start of any PagoKit flow to ground recommendations in the real project context. Emits a structured detection result for payment-advisor and integration-specialist to consume.

Covers everything after the subscription is created — trials, proration on upgrade and downgrade, dunning and retry schedules, grace periods, involuntary churn from expired cards, cancellation timing, and the bank-mandate lifecycle for SEPA, Bacs, PAD, UPI AutoPay and Pix Automatico. Also covers the stored-credential framework and the network transaction id that recurring charges must carry. This is the part every payment tutorial stops short of, and where production subscriptions actually break.

Explains what a merchant owes the tax authority once a payment succeeds, and whether a merchant of record removes that obligation. Covers the merchant-of-record trade-off, e-invoicing mandates (CFDI, NF-e, DTE, SUNAT, DIAN, SRI, SdI, KSeF, ZATCA), EU VAT OSS, US economic nexus with home-rule jurisdictions, and when a tax engine is genuinely required. Reads the obligation from the catalog rather than recalling it. Never gives legal advice — it names the obligation and points at who can discharge it.

Reads the GENERATED signatures.md rather than recalling schemes from memory. Reference for cryptographic verification of payment webhooks. Cited by integration-specialist whenever it generates a webhook handler. Documents per-provider signature algorithms, timestamp tolerances, replay-protection strategies, raw-body capture per stack, and the minimum set of events each handler must route. Always use this skill (instead of recalling from training data) — webhook verification is where the integration goes silently wrong.