payments-pimp

Active router for ALL payment processing requests — classifies by use case (online payments, subscriptions, in-person, catalog, loyalty) and routes to the correct payments skill. Use when handling payments, subscriptions, terminals, catalogs, or Square/Stripe integrations.

Model	Source
sonnet	pack: payments

Full Reference

If the request involves payments, subscriptions, checkout, invoicing, in-person terminals, product catalogs, inventory, loyalty programs, gift cards, bookings, or any payment provider integration in ANY way — you MUST route through this skill FIRST.

This is not optional. This is not negotiable. You cannot skip this.

Payments Pimp

The orchestration layer for all payments expertise. Not documentation — an active router. Every payment request flows through this routing table before any response.

Mandatory Announcement — FIRST OUTPUT before anything else:

┏━ 💳 payments-pimp ━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ [one-line description of what request/routing] ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

No exceptions. Box frame first, then route.

Quick Context

The payments pack covers the full online + in-person payment spectrum — from Stripe subscriptions and checkout to Square terminal hardware, catalog management, loyalty programs, and OAuth integrations.

Routing Table

Classify the request. Invoke the matching skill. No response before invocation.

Request Pattern	Skill
Stripe payments, subscriptions, webhooks, checkout sessions	`stripe-api`
Square payments, orders, checkout, refunds	`square-payments`
Square catalog, items, inventory, taxes, modifiers	`square-catalog`
Square Terminal, card readers, in-person hardware	`square-terminal`
Square loyalty, gift cards, bookings, customer engagement	`square-engagement`
Square OAuth, webhooks, error codes, API reference	`square-api-reference`
”Which payment provider should I use?”	Decision matrix → route

Decision Matrix

When the user hasn’t specified a provider, classify their use case:

Signal	Route To
Online payments, recurring billing, SaaS subscriptions	`stripe-api`
Square checkout, web/mobile payments, orders API	`square-payments`
Product catalog, item management, inventory tracking	`square-catalog`
Physical card reader, in-person POS, terminal hardware	`square-terminal`
Loyalty points, gift cards, appointment bookings	`square-engagement`
Square OAuth flows, webhook setup, API error debugging	`square-api-reference`
”Which provider?” / “Stripe vs Square?”	Ask one question: in-person hardware needed?

Shortcut rules:

SaaS/subscriptions → Stripe, no discussion
Physical card reader / POS → Square Terminal, no discussion
Loyalty + gift cards → Square Engagement, no discussion
Catalog/inventory → Square Catalog, no discussion
Square OAuth/auth → Square API Reference, no discussion

State Detection

Before routing, check project context:

package.json → detect stripe or squareup already installed
.env.example → check for STRIPE_SECRET_KEY or SQUARE_ACCESS_TOKEN keys

State	Action
`stripe` in deps or `STRIPE_SECRET_KEY` in env	Route to `stripe-api` directly
`squareup` in deps or `SQUARE_ACCESS_TOKEN` in env	Apply Square sub-routing (payments/catalog/terminal/engagement/reference)
Both detected	Ask ONE question: which provider is this request for?
Nothing detected	Apply decision matrix

Chaining Patterns

User Says	Chain
”Add subscriptions to my SaaS”	`stripe-api`
”Set up Stripe Checkout”	`stripe-api`
”Accept in-person card payments”	`square-terminal`
”Manage my Square product catalog”	`square-catalog`
”Add a loyalty rewards program”	`square-engagement`
”Set up Square gift cards”	`square-engagement`
”Process Square online orders”	`square-payments`
”Handle Square OAuth for my marketplace”	`square-api-reference`
”Debug Square webhook signature”	`square-api-reference`
”Track inventory across locations”	`square-catalog`
”Book appointments with Square”	`square-engagement`

Hard Rules

Never respond about payments before invoking the target skill
No summarizing, planning to invoke, or explaining what you’re about to do
If unclear, ask ONE clarifying question, then route
The skill’s content has the verified facts — always defer to it
“Which payment provider should I use?” is decision matrix territory — NEVER jump to implementation