Payment and billing skills for AI agents

Ask an agent to add payments to your app and you will usually get a working checkout call on the first try. Checkout is the easy part. The parts that decide whether the money still reconciles a year later are the three that never show up in a demo: where the secret key ends up, whether your server can tell a real event from a forged one, and what happens when the same event arrives twice.

Read the payment and billing skills side by side and the useful split is not good versus bad — it is which of those three questions the document answers at all, and the answers do not track size, publisher or popularity. The sharpest illustration sits inside a single name. Pick up a skill called stripe-integration and the document you actually get depends on the account behind it — one such pair, published separately, shares nearly every line of text right up to the point where one of them stops and the other keeps going.

Top picks

Subscriptions on Stripe: hand over travisjneuman's payment-integration

The webhook handler in travisjneuman's payment-integration runs three steps in a fixed order: verify the signature, look the event ID up in a stripeEvent table, and only then dispatch to the handler for that event type. It writes the ID back only after the handler returns, and it returns a 500 on a thrown error rather than swallowing it, because — as the document puts it — "Stripe delivers webhooks at least once, meaning duplicates are possible". That ordering is the whole argument, and the document's own pitfalls table is blunt about the cost of skipping it — "Double charges, duplicate provisioning" — which is why the dedup key belongs in a durable row rather than an in-process variable, and why a failure is better retried than lost.

It also explains why card data should never reach your server in terms of which compliance regime you land in, rather than leaving it as a slogan. The closing checklist is what makes it hand-over-able — keys in environment variables, signature verification on, event-ID deduplication, a dunning flow for failed payments, test mode everywhere. The caveat is scope: this is a Stripe and RevenueCat document, so on another processor it will confidently hand your agent the wrong nouns.

The shortest correct path: alinaqi's web-payments

alinaqi's web-payments opens with the environment block rather than the checkout call, and annotates the keys as it lists them — the secret key marked "Server-side only", the publishable key marked "Client-side safe", the webhook secret marked "For webhook verification". That screen settles the key-placement question before the agent writes any code, which is the right order to settle it in. The same webhook handler then appears twice, once in TypeScript and once in Python, both verifying the signature before they touch the event.

Its deduplication example is thinner than the first pick's — a Set living in module scope — though the document flags that itself, with the fix written into the same line: "Use Redis in production". Reach for this one when you want the fastest route from empty repo to a hosted checkout that survives a retry, and for travisjneuman's when the subscription lifecycle, not the first charge, is the hard part.

Deploying to the edge: jezweb's stripe-payments knows the trap

jezweb's stripe-payments is the only one of these documents that tells you the standard verification call will not run where you are deploying it: "constructEvent (synchronous) uses Node.js crypto which doesn't exist in Workers. Use constructEventAsync instead — it uses the Web Crypto API." Nothing else in this whole area names that trap, and it is the kind of failure that presents as a webhook endpoint quietly rejecting every real event. The setup section matches — secrets go in via wrangler secret put rather than a committed file, and the handler is written for Hono rather than assumed to be Express.

The gotchas table is the other reason to keep it: a webhook endpoint whose trailing slash does not match, test payments invisible because the wrong key prefix is in play, and the note that "Stripe retries failed webhooks for up to 3 days". It never gets to deduplicating repeated events, though, so on a busy endpoint pair it with the first pick's event-ID table.

The half that isn't code: whawkinsiv's payments

"Billing is 20% code and 80% configuration and business decisions" is the first claim whawkinsiv's payments makes, and the rest of it earns the claim. There is a subscription-lifecycle table mapping each status to what your app should do about it, a dunning email sequence with days attached, and a going-live checklist that ends by telling you to make a real purchase with your own card and then refund it. None of that is code, and most of it is what an agent working from general knowledge skips.

It is also straight about the trade it recommends, laying out tax handling through the processor against handing the whole problem to a merchant of record and naming what each costs you. The gap is deliberate but worth knowing: it tells you to verify signatures and return 200 quickly, and nothing in it addresses the same event arriving twice.

After launch: affaan-m's customer-billing-ops decides before it refunds

affaan-m's customer-billing-ops is not an integration guide and says so in its first line — "Use this skill for real customer operations, not generic payment API design." What it actually installs is a decision procedure for the moment a customer says they were charged twice: classify the case first (accidental duplicate, deliberate multi-seat purchase, failed checkout, missing self-serve controls), then take the most reversible action available, then write the follow-up and log the product gap that caused it.

"Do not refund blindly; first classify the issue" is the line that makes it worth installing, because the reflex of an agent holding a refund tool is exactly the opposite. Its guardrail also covers what such an agent will otherwise paste into a chat window: "Never expose secret keys, full card details, or unnecessary customer PII in the response". It carries one company's own labels in a couple of places, so read the workflow and ignore the local nouns.

A skill called stripe can be any of these

Skill names are not namespaced, so a name tells you the topic and nothing else — the publisher and the body are the identity. Mindrally's stripe is a set of TypeScript and Next.js integration guidelines: a Payment Element form, a subscription helper, a signature-verifying webhook route. civitai's stripe is a completely different animal — a bundled query script for support investigations, with subcommands to look up a customer, cancel a subscription and issue refunds. Install the second when you wanted the first and your agent now holds an irreversible tool it did not need.

That document, to its credit, knows what it is: refunds and cancellations are labelled "destructive and irreversible", the bulk refund path has a dry-run flag that previews what would be refunded, and the safety note says to "Always confirm with the human operator before executing". The same-name problem repeats one level up. HermeticOrmus's stripe-integration and wshobson's stripe-integration open with the same description, the same seven section headings and the same test-flow function — nearly every line of the shorter one appears verbatim in the longer one. Neither declares a source or an origin in its front matter, so which came first is not a question either document lets you answer.

What they do not share is where they stop. HermeticOrmus's continues into a signature-verifying webhook endpoint, a helper written to guarantee that a given event is processed exactly once, refund and dispute handling, and a pitfalls list — though its own examples paste the signing secret and the API key into the code as inline placeholder strings, which is the first thing worth looking for in any of these documents. wshobson's replaces all of that with a single pointer — "Detailed pattern documentation lives in references/details.md. Read that file when the navigation tier above is insufficient." That is a legitimate progressive-disclosure design, not an omission, but it changes what you are getting: the substance lives in a file you have to go and fetch, and none of it is on the page you just read.

Three questions to ask a payments skill before you install it

Start with the front matter, which costs one screen and sometimes answers the question the body cannot. A source: or origin: key is the publisher's own note about where the material came from, and what it holds varies: elsewhere in this area the same slot carries the documentation URL a document was written against, or the name of an upstream project, while affaan-m's customer-billing-ops uses it for origin: ECC — a house label that tells you the thing was written inside one organisation and nothing more. Treat whatever is there as a claim rather than a proof, and treat an empty slot as telling you nothing in either direction. Where it is filled in, though, it is the cheapest answer available to the question of what a document actually is.

Then open the body and look for three things. Where does the secret key live — an environment variable, a platform secret store, or an inline string in the first example? Is the incoming event authenticated before it is trusted? And is the operation safe if it runs twice?

Answering the second one takes a little care, because the right mechanism depends on the processor. HermeticOrmus's paypal-integration contains no signature check at all, because a signature check is not the mechanism its IPN handler uses: it posts the incoming notification back with _notify-validate and accepts it only when the reply reads VERIFIED, alongside the instruction to "Never trust IPN without verification" and a duplicate-transaction guard before any fulfilment. Searching that document for the word "signature" tells you nothing about whether it authenticates anything. ccxt's onchain-pay-open-api inverts the direction again — the authenticity work there is signing your own outbound request — and it earns its place by refusing to guess: if the destination address and network are not configured, it instructs the agent to ask you for both before proceeding.

Absences are worth checking too, and they are checkable in a way opinions are not. secondsky's payment-gateway-integration is short, but its checklists are explicit on all three points, down to "Never log full card numbers". dodopayments's subscription-integration has unusually thorough lifecycle coverage — trials, plan changes, credit entitlements, grace periods — and its worked handler goes straight from parsing the request body to the event switch, with the words signature, verify and secret appearing nowhere in the text; the document points you to its own hosted webhook docs instead. Neither of those is a verdict on the product behind the account slug. They are facts about what a document does and does not put in front of your agent, which is the part you can actually check before you install it.

What you have now

The three questions from the top are answerable per document, and now they have answers. For the secret key and the fastest correct build, alinaqi's web-payments; for event authenticity plus survival under retry, travisjneuman's payment-integration and its event-ID table; for an edge deployment where the usual verification call silently fails, jezweb's stripe-payments. Add whawkinsiv's payments for the configuration and go-live work the code-first documents skim past, and affaan-m's customer-billing-ops for the first time a customer says they were charged twice.

What you have avoided is subtler than a bug. It is installing a document whose name promised an integration guide and which turned out to be an irreversible refund tool, or reading a page whose substance sits in a reference file you never went and fetched — and shipping a webhook endpoint that trusts whatever posts to it, then treats the same event as new every time the processor sends it again.