UPI Payment Integration
What this skill does
Use this skill to help users build, review, or troubleshoot UPI integrations that are safe for production.
Covered flows:
- - UPI collect requests
- UPI intent payments
- UPI QR payments (static/dynamic)
- UPI autopay / e-mandate recurring payments
Disclaimer
This skill provides implementation and operational guidance only. It does not execute payments, move funds, or replace legal/compliance review. Payment regulations, provider APIs, limits, and policies may change; always verify against the latest official PSP, RBI, and NPCI documentation before production use.
Use at your own risk. The skill author/publisher/developer is not liable for direct or indirect loss, fraud, chargebacks, penalties, downtime, or other damages arising from use or misuse of this guidance.
Always validate in sandbox/staging before production and never share secrets or private keys in chat.
Setup
On first use, read setup.md and confirm:
- - provider and environment (sandbox vs production)
- credentials availability in secret manager
- webhook endpoint and verification strategy
- database/reconciliation ownership
Source freshness
- - Last verified date: 2026-03-19
- Before production changes, re-check provider docs and current RBI/NPCI circulars.
Source validation checklist
- - [ ] Confirm chosen PSP's latest webhook event semantics and retry policy.
- [ ] Confirm latest UPI transaction limits and mandate policy for your use case.
- [ ] Confirm current signature verification/auth requirements from provider docs.
- [ ] Confirm current settlement and reconciliation report fields from provider dashboard.
- [ ] Confirm any newly introduced compliance/legal requirements with your legal/compliance team.
Core operating principles
- 1. Treat payment lifecycle as asynchronous
- API response is not final truth.
- Webhook + reconciliation determine final status.
- 2. Make every write idempotent
- De-duplicate by event ID / provider payment ID / merchant request ID.
- Reprocessing the same webhook must be safe.
- 3. Persist before processing
- Store raw webhook payload and headers first.
- Process in a retriable job/queue.
- 4. Reconcile continuously
- Poll or fetch status for
PENDING, timed-out, or disputed records.
- Close state gaps between app DB, PSP dashboard, and settlement reports.
- 5. Keep compliance explicit
- Follow RBI authentication and risk controls.
- Keep consent and cancellation paths clear for recurring mandates.
Mandatory implementation checklist
Use this checklist in every implementation/review:
- - [ ] Payment state machine exists (
CREATED, PENDING, SUCCESS, FAILED, EXPIRED, REFUNDED as applicable). - [ ] Unique merchant-side request ID/correlation ID is generated and stored.
- [ ] Webhook signature verification is implemented.
- [ ] Raw webhook body is stored before business logic.
- [ ] Duplicate webhook delivery is handled safely.
- [ ] Out-of-order events are handled safely.
- [ ] Retry policy exists for provider/network failures.
- [ ] Reconciliation job exists for stale
PENDING records. - [ ] Refund and reversal flows are explicit.
- [ ] Alerting exists for failure spikes and webhook downtime.
- [ ] Mandate create/pause/cancel paths are implemented and visible to users.
Standard workflow (for the agent)
When user asks for UPI help, do this:
- 1. Identify integration mode
- Collect vs intent vs QR vs mandate.
- 2. Map current architecture
- Client request path
- Backend order/payment records
- Provider API call
- Webhook receiver
- Reconciliation worker
- 3. Enforce reliability controls
- Idempotency keys
- Signature validation
- Event dedupe
- Retries and dead-letter handling
- 4. Validate business correctness
- No shipment/service unlock before durable success
- Correct handling of late success after apparent failure
- Correct handling of duplicate attempts
- 5. Validate compliance and customer UX
- Authentication and risk controls
- Consent and cancellation clarity for mandates
- Clear customer-visible status and support trace IDs
Webhook handling rules
- - Always verify signature using provider secret.
- Use raw request body for signature validation; do not mutate/parse first.
- Acknowledge quickly (2xx) after durable receipt.
- Process asynchronously.
- Never assume strict event ordering.
- Build handlers as idempotent upserts, not one-time inserts.
Error handling and reconciliation rules
- - On timeout, mark local payment as
PENDING_RECON (or equivalent), not immediate failure. - Reconcile by provider payment ID and merchant request ID.
- If provider says success after client saw failure, trust reconciled final state and repair downstream records.
- Log every status transition with source (
api, webhook, recon).
Recurring mandate (Autopay) rules
- - Treat mandate creation as a first-class object with lifecycle states.
- Store mandate ID, start/end dates, frequency, max amount, and status.
- Support pause/cancel from product UI and backend admin.
- Send pre-debit reminders where required by provider/framework.
- On recurring debit failures, retry only within allowed policy; avoid silent repeated debits.
Compliance and policy guardrails
- - Follow RBI authentication expectations (minimum two factors, with dynamic factor requirements where applicable).
- Keep evidence logs for user consent and mandate actions.
- Protect personal/payment data with least-privilege access and retention policy.
- Keep customer grievance paths clear (transaction reference IDs, support response playbook).
Output format
When responding to a user request, return:
- 1. Architecture or fix plan
- Concrete code/database changes
- Failure-mode checks
- Test plan (happy path + retries + duplicates + out-of-order events + reconciliation)
References
Related skills
- -
upi-go-live-checklist for phase tracking and launch gates - INLINECODE13 for customer messaging and support operations
UPI支付集成
该技能的功能
使用此技能帮助用户构建、审查或排查可用于生产环境的UPI集成问题。
涵盖的流程:
- - UPI收款请求
- UPI意图支付
- UPI二维码支付(静态/动态)
- UPI自动支付/电子授权定期支付
免责声明
本技能仅提供实施和操作指导。它不执行支付、转移资金或替代法律/合规审查。支付法规、提供商API、限额和政策可能发生变化;在生产环境使用前,请务必对照最新的官方PSP、RBI和NPCI文档进行验证。
使用风险自负。技能作者/发布者/开发者不对因使用或滥用本指导而产生的直接或间接损失、欺诈、退单、罚款、停机或其他损害承担责任。
在生产环境使用前,务必在沙盒/预发布环境中进行验证,切勿在聊天中分享密钥或私钥。
设置
首次使用时,请阅读setup.md并确认:
- - 提供商和环境(沙盒 vs 生产环境)
- 密钥管理器中凭据的可用性
- Webhook端点及验证策略
- 数据库/对账所有权
信息来源时效性
- - 最后验证日期:2026-03-19
- 在生产环境变更前,请重新检查提供商文档及当前的RBI/NPCI通知。
来源验证清单
- - [ ] 确认所选PSP最新的Webhook事件语义和重试策略。
- [ ] 确认适用于您用例的最新UPI交易限额和授权政策。
- [ ] 确认提供商文档中当前的签名验证/认证要求。
- [ ] 确认提供商仪表盘中当前的对账和结算报告字段。
- [ ] 与您的法律/合规团队确认任何新引入的合规/法律要求。
核心操作原则
- 1. 将支付生命周期视为异步
- API响应并非最终事实。
- Webhook + 对账决定最终状态。
- 2. 确保每次写入操作具有幂等性
- 通过事件ID/提供商支付ID/商户请求ID进行去重。
- 重新处理相同的Webhook必须是安全的。
- 3. 先持久化再处理
- 首先存储原始Webhook负载和头部信息。
- 在可重试的任务/队列中处理。
- 4. 持续进行对账
- 对PENDING、超时或有争议的记录进行轮询或获取状态。
- 填补应用数据库、PSP仪表盘和结算报告之间的状态差异。
- 5. 保持合规性明确
- 遵循RBI的认证和风险控制要求。
- 为定期授权保留清晰的同意和取消路径。
强制性实施清单
在每次实施/审查中使用此清单:
- - [ ] 存在支付状态机(适用时包括CREATED、PENDING、SUCCESS、FAILED、EXPIRED、REFUNDED)。
- [ ] 生成并存储唯一的商户端请求ID/关联ID。
- [ ] 已实现Webhook签名验证。
- [ ] 在执行业务逻辑前存储原始Webhook体。
- [ ] 安全处理重复的Webhook投递。
- [ ] 安全处理乱序事件。
- [ ] 针对提供商/网络故障存在重试策略。
- [ ] 针对过期的PENDING记录存在对账任务。
- [ ] 退款和冲正流程明确。
- [ ] 针对故障激增和Webhook停机存在告警机制。
- [ ] 已实现授权创建/暂停/取消路径,并对用户可见。
标准工作流程(供代理使用)
当用户请求UPI帮助时,执行以下操作:
- 1. 识别集成模式
- 收款 vs 意图 vs 二维码 vs 授权。
- 2. 映射当前架构
- 客户端请求路径
- 后端订单/支付记录
- 提供商API调用
- Webhook接收器
- 对账工作器
- 3. 实施可靠性控制
- 幂等键
- 签名验证
- 事件去重
- 重试和死信处理
- 4. 验证业务正确性
- 在持久成功之前不发货/解锁服务
- 正确处理明显失败后的延迟成功
- 正确处理重复尝试
- 5. 验证合规性和客户体验
- 认证和风险控制
- 授权的同意和取消清晰度
- 清晰的客户可见状态和支持追踪ID
Webhook处理规则
- - 始终使用提供商密钥验证签名。
- 使用原始请求体进行签名验证;不要先进行修改/解析。
- 在持久接收后快速确认(2xx)。
- 异步处理。
- 切勿假设严格的事件顺序。
- 将处理器构建为幂等更新插入,而非一次性插入。
错误处理和对账规则
- - 超时时,将本地支付标记为PENDING_RECON(或等效状态),而非立即失败。
- 通过提供商支付ID和商户请求ID进行对账。
- 如果提供商在客户端看到失败后返回成功,信任对账后的最终状态并修复下游记录。
- 记录每次状态转换及其来源(api、webhook、recon)。
定期授权(自动支付)规则
- - 将授权创建视为具有生命周期状态的一等对象。
- 存储授权ID、开始/结束日期、频率、最大金额和状态。
- 支持从产品UI和后端管理进行暂停/取消。
- 在提供商/框架要求时发送扣款前提醒。
- 定期扣款失败时,仅在允许的政策范围内重试;避免静默重复扣款。
合规和政策护栏
- - 遵循RBI的认证期望(至少两个因素,在适用情况下包含动态因素要求)。
- 保留用户同意和授权操作的证据日志。
- 通过最小权限访问和保留策略保护个人/支付数据。
- 保持清晰的客户申诉路径(交易参考ID、支持响应手册)。
输出格式
在响应用户请求时,返回:
- 1. 架构或修复计划
- 具体的代码/数据库变更
- 故障模式检查
- 测试计划(正常路径 + 重试 + 重复 + 乱序事件 + 对账)
参考资料
相关技能
- - upi-go-live-checklist 用于阶段追踪和发布门控
- upi-payment-ux-ops 用于客户消息传递和支持运营