Introduction
Nepal Payments is an Agent Skill for integrating Nepali payment gateways into any backend, web app or mobile app. Ask a coding agent to “add eSewa and Khalti checkout to this app” and it follows a tested recipe: server-side signing, server-to-server verification, exactly-once fulfilment and reconciliation.
The skill ships working adapters in 6 languages, covered by 414 tests that include each provider’s own signature test vectors. The adapters also work on their own, without any agent.
Providers
Section titled “Providers”eSewaePay v2 web checkout, Intent app-to-appKhaltiKPG-2 web checkout, refundsFonepayWeb redirect, Dynamic QR over WebSocketconnectIPSDirect bank debit, RSA-signed with your .pfxCyberSourceSecure Acceptance cards via Nepali banksNPS OnePGAbout 29 banks, wallets and cards in one APIIME PayWallet checkout for existing merchants
HBL (2C2P PACO), Prabhu Pay, Moru, CellPay and Namaste Pay are documented in Other gateways without a bundled adapter.
Two ways to use it
Section titled “Two ways to use it”With a coding agentInstall the skill in Claude Code, Codex, Cursor, Gemini CLI or Copilot and describe what you need.
Adapters onlyCopy the adapter folder for your language into your server and call initiate() and verify().
What the skill enforces
Section titled “What the skill enforces”- Secrets and signing stay on the server. Clients only send an order id.
- A redirect or callback is never proof of payment. The provider’s status API decides.
- Verification uses the amount and ids from your database, not from the callback.
- State changes go through one tested function,
decideTransition, which handles early return-URL hits, late payments after an attempt was closed, missing or mismatched amounts and duplicate payments. - A reconciliation job settles payments where the customer closed the tab.
The reasoning behind each rule is in Production architecture.