Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add 05-deepak-patidar/claude-skills --skill payments-and-moneygit clone --depth 1 https://github.com/05-deepak-patidar/claude-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/05-deepak-patidar/claude-skills/payments-and-money)<a href="https://agentmods.dev/skills/05-deepak-patidar/claude-skills/payments-and-money"><img src="https://agentmods.dev/badge/skills/05-deepak-patidar/claude-skills/payments-and-money/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/05-deepak-patidar/claude-skills/payments-and-money"><img src="https://agentmods.dev/badge/skills/05-deepak-patidar/claude-skills/payments-and-money.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00096 | $0.01287 |
| Opus 5 | $0.00048 | $0.00643 |
| Sonnet 5 | $0.00019 | $0.00257 |
| Haiku 4.5 | $0.00010 | $0.00129 |
Grade A, and why
payments-and-money scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 50 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Payments and Money
Money code has a property no other code has: its bugs convert directly into rupees, disputes, and audits — and they're discovered by customers and accountants, not by monitoring. The discipline is total paranoia dressed as engineering: assume every network call fails after succeeding, every webhook arrives twice or never, and every balance you compute will one day be checked against someone else's records.
The invariants (violating any of these is an incident)
- Exact decimals only —
NUMERIC/integer-minor-units end to end: DB, API (string or integer, never JSON float), UI. One float sneaking into the pipeline poisons everything downstream (database-design). - The server computes every amount. Client-submitted prices, totals, or discounts are display hints to be re-derived and verified, never inputs to be charged. The classic exploit is editing the amount in the request.
- Append-only truth. Every money movement is a new immutable record; corrections are compensating entries (refund, credit note, adjustment with reason), never UPDATEs to history. If the question "what did we believe on March 31?" can't be answered, the model is wrong.
- Balances are derived, not stored — or if cached for speed, recomputable from the movement log and audited for drift on a schedule. A stored balance with no recomputation path is a rumor.
- One transaction per money operation: invoice + line items + stock + ledger entries + payment record commit atomically or not at all — and no external API calls inside that DB transaction (system-design).
Idempotency — the heart of payment correctness
The network failing after the charge succeeded is not an edge case; at volume it's a Tuesday.
- Every money-moving operation (charge, refund, payout, credit) carries a client-generated idempotency key, stored with a unique constraint: the retry returns the original result instead of moving money twice (api-contract-design).
- Same rule internally: the "record payment" service function must be safe against double-click, double-webhook, and job-retry — enforce with the constraint, not with a check-then-insert race (database-design concurrency rules).
- Every payment gets a state machine with legal transitions written down:
created → pending → succeeded | failed → (refund_pending → refunded). Illegal transitions rejected loudly. "It's in a weird state" means the state machine has undocumented states — fix the model.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 50 lines · 96 tokens per session scan A decd87dfea49
payments-and-money is a skill published in the GitHub repository 05-deepak-patidar/claude-skills (4 stars, last pushed 2mo ago), licensed MIT. It adds 96 tokens to every session and 1,287 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
alipay-webhooks
Receive and verify Alipay (Antom / Alipay+) webhook notifications. Use when setting up Alipay webhook handlers, debugging RSA256 Signature header verification, or handling payment events like notifyPayment, notifyCapture, notifyRefund, notifyAuthorization, and notifyDispute.
exact-online-webhooks
Receive and verify Exact Online webhooks. Use when setting up Exact Online webhook handlers, debugging HashCode signature verification, subscribing to topics via the WebhookSubscriptions REST endpoint, or handling entity change events like Accounts, Items, StockPositions, FinancialTransactions, GoodsDeliveries, and…
adyen-webhooks
Receive and verify Adyen webhooks (standard notifications). Use when setting up Adyen webhook handlers, debugging HMAC signature verification, or handling payment events like AUTHORISATION, CAPTURE, REFUND, CANCELLATION, and CHARGEBACK.
ascend-webhooks
Receive and verify Ascend webhooks. Use when setting up Ascend webhook handlers, debugging Ascend signature verification (X-Ascend-Signature, HMAC-SHA256), or handling insurance payment events like invoice.paid, payout.paid, and refund.paid.
bridge-api-webhooks
Receive and verify Bridge API webhooks (bridgeapi.io — the open-banking aggregator by Bridge/Bankin', NOT bridge.xyz). Use when setting up Bridge API webhook handlers, debugging BridgeApi-Signature HMAC-SHA256 verification, or handling events like item.created, item.refreshed, item.account.updated…
bridge-xyz-webhooks
Receive and verify Bridge (bridge.xyz) webhooks. Use when setting up Bridge webhook handlers, debugging RSA signature verification of the X-Webhook-Signature header, or handling stablecoin/fiat events like customer.updated, kyclink.updated, transfer.updated, and virtualaccount.activity.