Paytm Integration Skill

• Outcome: Pass
• Latest audit: May 29, 2026 at 8:44 PM UTC
• Version:
  1.0.2

Overview

This is a coherent Paytm payment-integration skill, but its sample code and docs need careful production review because they handle real payment credentials and customer payment data.

Install only if you are intentionally building Paytm payment flows. Use staging first, keep PAYTM_MERCHANT_KEY only in server-side secret-managed configuration, add authentication, rate limits, strict CORS, durable idempotency, and minimal webhook logging before production, and verify payment-link reconciliation against /link/fetchTransaction.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (6)

Intent-Code Divergence

Medium

• Confidence: 84% confidence
• Finding: The document gives conflicting guidance about which endpoint should be used for Payment Link reconciliation. In payment integrations, contradictory instructions can cause developers to validate payment state against the wrong API surface, leading to missed payments, duplicate fulfillment logic, or incorrect trust in browser callback data instead of authoritative server-side reconciliation.

Intent-Code Divergence

Medium

• Confidence: 88% confidence
• Finding: The pitfalls section tells users to rely on `transactions[]` from the fetch response, which conflicts with earlier guidance that Payment Link reconciliation must use `/link/fetchTransaction` and that fetch returns link metadata. In a payment context, this inconsistency can cause merchants to build reconciliation against incomplete or non-authoritative data, resulting in unrecorded successful payments or faulty fulfillment decisions.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The docstring explicitly states that production expectations include Redis-based deduplication, IP whitelisting, 5xx on processing errors, and fast queue-backed handling, but the implementation only performs in-memory deduplication and lacks IP filtering or robust error handling around fulfillment. In a payment webhook context, this mismatch is dangerous because operators may deploy this code believing it has production-grade protections, leading to replay handling gaps, unauthenticated source acceptance beyond signature checks, and unreliable processing under multi-process or restart conditions.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: The README encourages auto-loading this skill for any Paytm-related prompt, which increases the chance that an agent will generate or act on payment code in contexts involving live credentials, callbacks, or production payment operations without an explicit safety checkpoint. In a payments skill, implicit activation is riskier than in ordinary coding domains because generated outputs may touch merchant secrets and real-money transaction flows.

Natural-Language Policy Violations

Medium

• Confidence: 80% confidence
• Finding: The skill hard-codes a restrictive payment-option vocabulary and instructs the agent to refuse any term outside a fixed allowlist, without citing a business, legal, or compliance basis. In a payment-integration context, this can cause the agent to give incomplete or distorted guidance, override user intent, and potentially misconfigure checkout flows or omit supported methods, which creates business and integration risk even if it is not a classic exploit primitive.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The README tells users to export `PAYTM_MID` and `PAYTM_MERCHANT_KEY` directly in the shell but does not warn that the merchant key is a sensitive secret that must never be committed, logged, or exposed client-side. In a payment-gateway integration context, weak secret-handling guidance increases the chance developers will paste credentials into shared scripts, screenshots, shell history, or deployment configs insecurely, which could enable fraudulent API use or transaction tampering.

VirusTotal

63/63 vendors flagged this skill as clean.