Complete JS Checkout (one-time payment) flow for Paytm Payment Gateway: Generate Checksum -> Initiate Transaction (txnToken) -> Render JS Checkout -> Handle Callback -> Transaction Status verification. Covers the merchant CheckoutJS script, init/invoke pattern, callback verification (`/v3/order/status`), and the most common bugs (`CheckoutJS.onLoad` trap, missing `transactionStatus`/`notifyMerchant` handlers, debug dumps on the user-facing screen). Load this skill for ALL one-time web payments (checkout pages, "Pay" buttons, in-app payments). Do NOT load for subscriptions, links, or QR.
Paytm UPI Autopay / Native Subscription flow for recurring charges (monthly / weekly / yearly / daily mandates, SIPs). Covers `POST /subscription/create` with `requestType: NATIVE_SUBSCRIPTION`, the flat-body field placement (no `subscriptionDetails` wrapper), required `head.clientId` / `channelId` / `signature`, the `traceId` query param, retry / grace rules, default value choices, and the most common errors (4001 grace > frequency, custId sanitization, etc.). Also covers the full post-consent recurring lifecycle (`subscription/checkStatus`, `renew`, `preNotify`, `cancel`, `v3/order/status`), the `/theia/` vs non-`/theia/` host split, and subscription webhook events (`SUBSCRIPTION_DEBIT` / `SUBSCRIPTION_CANCEL`) — see `references/recurring-lifecycle.md`. Load this skill for ANY recurring charge - "subscription", "monthly", "autopay", "mandate", "renew every…", "membership", "plan", "SIP". Do NOT load for one-time payments.
Paytm Large Payment Collection (Bank Transfer) — accept high-ticket payments via NEFT / RTGS / IMPS (UPI also supported in the Checkout flow) using a unique 18-char Virtual Account Number (VAN) per customer / order. Paytm auto-reconciles the inbound bank transfer to the right VAN, fires a webhook with full remitter details, and settles T+1. Two integration shapes: the **Checkout flow** (default — order-based VAN issued via /initiateTransaction, surfaced inside the Paytm JS Checkout modal) and the **Non-Checkout flow** (server-only permanent VANs via the vanproxy API for ongoing collections — BFSI, schools, distributors, subscriptions). Covers Create VAN, Query VAN, Update VAN (disable / TPV), VAN List, Order List, Transaction Status, Refund, Refund Status, and payment / refund webhooks. Load this skill for "bank transfer collection", "virtual account", "VAN", "NEFT/RTGS/IMPS collection", "large payment", "bulk collection", "fee collection", "invoice bank transfer".
Symptom -> cause -> fix tree for Paytm integration failures: checksum mismatches (227), invalid / duplicate orderId (330/334), bad request (400), JS Checkout modal not opening, callback verification failures, transaction-status confusion, refund pending, and corp-proxy TLS interception (`UNABLE_TO_GET_ISSUER_CERT_LOCALLY`). Includes the expanded RESPCODE reference and a top-level decision tree. Load this skill when the user reports an error code, an unexpected behavior, or asks "why is X failing?" in a Paytm context.
Migration playbook for moving from BillDesk (PG by BillDesk / IndiaIdeas.com) to Paytm Payment Gateway. BillDesk merchants typically run one of two flows: the legacy pipe-delimited PaymentRequest flow (HMAC-SHA256 checksum on `|`-joined message string) OR the newer Online Payment v1.2 API (JWS-signed + JWE-encrypted JSON over `/payments/ve1_2/orders/create`). Covers both flows, mapping to Paytm's JSON + checksum REST model, recurring (BillDesk eMandate) -> NATIVE_SUBSCRIPTION, refund + status flow, and dual-write rollout. Load when the user mentions migrating from BillDesk or has BillDesk integration in the codebase (BILLDESK_MERCHANT_ID, BILLDESK_CLIENT_ID, BILLDESK_SECRET_KEY, pgi.billdesk.com, /pgidsk/PGI*, /payments/ve1_2/, BdSign JWS, BdJwe payload).
Migration playbook for moving from Cashfree Payments (Payment Gateway, Subscriptions, Payouts, Easy Split) to Paytm Payment Gateway. Covers the Cashfree session/order model -> Paytm's `txnToken` + JS Checkout, X-Client-Id / X-Client-Secret header auth -> Paytm body checksum, webhook signature scheme, recurring payments, refunds, and dual-write rollout. Load when the user mentions migrating, switching, or moving from Cashfree to Paytm, or has a Cashfree integration in the codebase (e.g. `cashfree-pg`, `Cashfree.PG.Orders.CreateOrder`, `cashfreepayments.com`, `CASHFREE_APP_ID`, `CASHFREE_SECRET_KEY`, `x-client-id` headers, `payment_session_id`, `/pg/orders`).
Migration playbook for moving from CCAvenue (Avenues India) to Paytm Payment Gateway. CCAvenue uses an AES-256 encrypted form-POST flow with three credentials (merchant_id, access_code, working_key) — substantially different from Paytm's JSON+checksum REST flow. Covers the AES-encrypted-form -> REST JSON shift, request/response encryption translation, Subscription Information (SI) -> NATIVE_SUBSCRIPTION, billing/shipping field reduction, refund cancellation via the non-seamless API, and dual-write rollout. Load when the user mentions migrating from CCAvenue or has CCAvenue integration in the codebase (CCAVENUE_MERCHANT_ID, CCAVENUE_ACCESS_CODE, CCAVENUE_WORKING_KEY, AES-256, secure.ccavenue.com, /transaction/transaction.do).
Migration playbook for moving from Juspay (HyperSDK / Hyper Checkout / ExpressCheckout API) to Paytm Payment Gateway. Juspay is an orchestrator that routes through multiple underlying PGs; moving to Paytm means accepting Paytm as the single PG, losing the multi-PG routing / smart-retry layer. Covers the orchestrator -> direct-PG mental shift, HyperSDK -> Paytm All-in-One SDK, ExpressCheckout REST -> Paytm /theia/api/v1/initiateTransaction, webhook scheme, refunds, and dual-write rollout. Load when the user mentions migrating from Juspay, or has Juspay integration code (HyperSDK, hyperServices, juspay.in, /orders endpoint, JUSPAY_API_KEY, juspay-node, in.juspay.hypersdk).