india-payments-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PAYMENTS_MODE | No | Runtime mode: mock, sandbox (default), or live. Mock needs no credentials; sandbox/live require the relevant gateway credentials via environment variables. | sandbox |
| MCP_HTTP_TOKEN | No | Bearer token (24+ characters) required when running the HTTP transport. Not required for the default stdio transport. | |
| PAYMENTS_AUDIT_LOG | No | Path to append audit log entries as JSON Lines for create, refund and subscription actions. | |
| PAYMENTS_ALLOW_LIVE_MUTATIONS | No | Set to true to allow live-mode refunds and subscription cancellations. Live mutations also require confirm: true on the call. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| payments_list_providersA | List every supported gateway with a one-line summary, whether credentials are configured, and the feature support matrix. |
| payments_get_capabilitiesA | Full capability map for one gateway: features (supported / partial / not_implemented / unsupported), payment methods, required env vars, hard constraints, official SDKs and platform plugins (Shopify, WooCommerce). |
| payments_check_configA | Doctor: shows the mode and which environment variables are present or missing per gateway. Never returns secret values. |
| payments_recommend_gatewayB | Rank gateways for a use case using the capability map (e.g. subscriptions, international payments, Shopify, lowest integration effort). |
| payments_create_paymentA | Create an order / payment session. Returns |
| payments_verify_paymentA | Verify the payload the browser/app received after checkout (Razorpay handler response, PayU/CCAvenue/Paytm POST-back, etc.). Fulfil ONLY when paid=true. valid=true just means the callback is genuine; a genuine failure is still valid. For gateways that do not sign callbacks it confirms through the status API. |
| payments_get_statusA | Fetch the authoritative payment status from the gateway (source of truth for reconciliation). |
| payments_refundA | Refund all or part of a captured payment. refund_ref is the idempotency key: re-sending it after a success returns the same refund. If a call fails with OUTCOME_UNKNOWN, check payments_get_refund_status / payments_get_status BEFORE retrying. In live mode this moves real money: ask the human first, then pass confirm=true. |
| payments_get_refund_statusC | Fetch refund status from the gateway. |
| payments_verify_webhookA | Verify a webhook signature and normalise it into a common event (payment.succeeded, refund.processed, ...). Pass the RAW body string exactly as received. |
| payments_simulate_webhookA | Produce a correctly signed webhook (headers + raw body) for local testing. In sandbox mode it uses the provider's real signing scheme and your webhook secret; replay it with curl against your LOCAL endpoint. Disabled in live mode. Never reuse sandbox webhook secrets in production. |
| payments_create_customerC | Create a customer record on gateways that have one (Razorpay, Stripe). |
| payments_create_subscriptionB | Create a recurring subscription (UPI Autopay / card e-mandate). Returns a checkout action the customer must complete to authorise the mandate. |
| payments_cancel_subscriptionA | Cancel a subscription now or at cycle end. Live mode requires confirm=true after human approval. |
| payments_list_settlementsA | List settlements (payouts from the gateway to your bank) for reconciliation. |
| payments_generate_integrationA | Generate a working, production-shaped integration for a project: server routes (create order, verify callback, webhook), client checkout code, env template and a test checklist. Returns files with paths and contents for the agent to write. |
| payments_mock_complete_paymentA | MOCK MODE ONLY. Simulate the customer finishing checkout. Returns a signed callback payload (feed it to payments_verify_payment) and the updated payment. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| integrate_payments | Step-by-step plan for adding a gateway to the current project. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| support-matrix | Feature support across all gateways (Markdown) |
| razorpay capabilities | Capability map for one gateway (JSON) |
| payu capabilities | Capability map for one gateway (JSON) |
| cashfree capabilities | Capability map for one gateway (JSON) |
| ccavenue capabilities | Capability map for one gateway (JSON) |
| paytm capabilities | Capability map for one gateway (JSON) |
| phonepe capabilities | Capability map for one gateway (JSON) |
| stripe capabilities | Capability map for one gateway (JSON) |
| skydo capabilities | Capability map for one gateway (JSON) |
TDQS
Scored across 17 tools
Most tools target a distinct resource+action (create_payment, refund, verify_webhook, simulate_webhook, mock_complete_payment are clearly separated by mode/purpose). There is mild overlap among the four introspective tools — list_providers vs get_capabilities vs check_config vs recommend_gateway all describe gateway metadata/env vars, and get_status vs verify_payment require reading the descriptions carefully to distinguish authoritative fetch from callback validation.
Every tool uses the same payments_ prefix followed by a consistent snake_case verb_noun pattern (payments_get_status, payments_create_subscription). No mixing of conventions or vague one-word verbs.
17 tools is slightly above the ideal 3-15 band but justifiable given multi-gateway support plus subscription, webhook, settlement and scaffolding flows. Each tool maps to a real integration step rather than padding.
Core lifecycle is well covered: create/verify/status, refund + refund status, webhooks (verify/simulate), subscriptions create/cancel, customers, settlements and integration generation. Gaps remain for read/list operations — no list_payments/orders, get_subscription, list_subscriptions, or capture of authorised payments — which would be needed for full reconciliation and subscription management.