UPI Go-Live Checklist
Purpose
This skill takes a team from no setup to first successful test payment and then to go-live readiness.
It is execution-oriented: checklists, artifacts, and release gates.
Disclaimer
This skill provides launch-planning and operational guidance only. It does not execute payments, move funds, or replace legal/compliance review. Payment regulations, provider APIs, and operational requirements may change; verify against the latest official PSP, RBI, and NPCI documentation before go-live.
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 complete sandbox validation, policy review, and internal approvals before production launch.
Scope boundaries
- - This skill does not move money by itself.
- It assumes you have (or will obtain) a PSP/aggregator account and required approvals.
- It coordinates onboarding and launch readiness; use
upi-payment-integration for deep code patterns and upi-payment-ux-ops for messaging/support copy.
Setup
On first use, read setup.md and create a local project memory file from memory-template.md.
Source freshness
- - Last verified date: 2026-03-19
- Treat this as a launch framework; always re-validate policy/provider details before go-live.
Source validation checklist
- - [ ] Confirm current RBI digital payment authentication direction applicability.
- [ ] Confirm latest recurring mandate/e-mandate rules for your payment categories.
- [ ] Confirm selected provider's current onboarding, settlement, and support SLAs.
- [ ] Confirm incident/escalation contacts are current and tested.
- [ ] Confirm all gate criteria in your org's compliance policy are mapped in
go-live-gates.md.
Standard execution workflow
Follow these phases in order:
Phase 0 - Program setup
Required inputs:
- - target launch date
- owner names (engineering, product, ops, finance)
- chosen market and currency assumptions
- provider short-list
Outputs:
- - project tracker with owners and due dates
- risk log initialized
Phase 1 - Provider and account readiness
Checklist:
- - [ ] Select provider path (direct bank/PSP/aggregator).
- [ ] Confirm sandbox access is enabled.
- [ ] Confirm production onboarding/KYC requirements.
- [ ] Confirm settlement model and reconciliation report availability.
- [ ] Confirm support and escalation contacts from provider side.
Output:
- - signed-off provider decision note
Phase 2 - Security and configuration baseline
Checklist:
- - [ ] Define required env vars and secret ownership.
- [ ] Store credentials in secure secret manager (not chat, not source control).
- [ ] Define webhook endpoint URL(s) for sandbox and prod.
- [ ] Define IP allowlist / auth / signature verification policy.
- [ ] Define data retention policy for payment logs and PII.
Output:
- - configuration manifest (
env-name -> secret -> owner -> rotation policy)
Phase 3 - Build minimum viable payment flow
Checklist:
- - [ ] Create order/payment record model with idempotency anchor.
- [ ] Implement payment initiation endpoint.
- [ ] Implement webhook receiver with signature validation.
- [ ] Implement payment state transitions and transition guardrails.
- [ ] Implement reconciliation job for stale pending transactions.
Output:
- - end-to-end sandbox payment flow working in test environment
Phase 4 - Test matrix and evidence
Run and capture evidence for:
- - [ ] successful payment
- [ ] failed payment
- [ ] timeout leading to reconciliation
- [ ] duplicate webhook delivery
- [ ] out-of-order webhook sequence
- [ ] refund (if enabled in scope)
- [ ] mandate create/cancel (if recurring is in scope)
Output:
- - test evidence log (screenshots, traces, IDs, expected vs actual)
Phase 5 - Operational readiness
Checklist:
- - [ ] Monitoring dashboards live (success rate, pending aging, webhook failures).
- [ ] Alerts configured (failure spike, pending backlog, reconciliation failures).
- [ ] L1/L2 support runbook approved.
- [ ] Incident communication templates approved.
- [ ] On-call ownership and escalation ladder confirmed.
Output:
- - runbook + on-call contact sheet
Phase 6 - Go-live gate review
Gate must pass all:
- - [ ] critical test cases pass
- [ ] no unresolved P0/P1 payment defects
- [ ] rollback procedure tested
- [ ] financial reconciliation dry run accepted by finance
- [ ] compliance sign-off recorded
Output:
- - go/no-go decision record
Agent behavior rules
When user asks for launch help:
- 1. Determine current phase (0 to 6).
- Return only missing tasks for that phase.
- Mark blockers explicitly as
BLOCKER. - Do not suggest go-live if any gate is incomplete.
- Keep outputs actionable with owner and due date fields.
Output template
Use this format:
CODEBLOCK0
Companion files
Related skills
- -
upi-payment-integration for implementation and technical reliability controls - INLINECODE6 for customer communication and support readiness
UPI 上线检查清单
目的
本技能引导团队从零配置状态,完成首次成功测试支付,最终达到上线就绪状态。
本技能以执行为导向:包含检查清单、交付物和发布门禁。
免责声明
本技能仅提供启动规划和运营指导。它不执行支付、不转移资金,也不替代法律/合规审查。支付法规、服务商API和运营要求可能发生变化;上线前请务必对照最新的官方PSP、RBI和NPCI文档进行验证。
使用本技能风险自负。技能作者/发布者/开发者不对因使用或误用本指南而导致的直接或间接损失、欺诈、拒付、罚款、停机或其他损害承担责任。
在生产环境上线前,请务必完成沙箱验证、策略审查和内部审批。
范围边界
- - 本技能本身不转移资金。
- 本技能假设您已拥有(或将要获得)PSP/聚合支付账户及所需的审批。
- 本技能协调入驻和上线准备工作;深度代码模式请参考 upi-payment-integration,消息/支持文案请参考 upi-payment-ux-ops。
设置
首次使用时,请阅读 setup.md,并根据 memory-template.md 创建本地项目记忆文件。
信息来源时效性
- - 最后验证日期:2026-03-19
- 请将其视为启动框架;上线前务必重新验证策略/服务商详情。
来源验证检查清单
- - [ ] 确认当前RBI数字支付认证方向的适用性。
- [ ] 确认适用于您支付类别的最新定期授权/电子授权规则。
- [ ] 确认所选服务商当前的入驻、结算和支持SLA。
- [ ] 确认事件/升级联系人是当前有效的且经过测试。
- [ ] 确认您组织合规策略中的所有门禁标准已映射到 go-live-gates.md 中。
标准执行工作流
请按顺序执行以下阶段:
阶段 0 - 项目设置
所需输入:
- - 目标上线日期
- 负责人姓名(工程、产品、运营、财务)
- 选定的市场和货币假设
- 服务商候选名单
输出:
- - 包含负责人和截止日期的项目跟踪表
- 初始化的风险日志
阶段 1 - 服务商和账户就绪
检查清单:
- - [ ] 选择服务商路径(直接银行/PSP/聚合支付)。
- [ ] 确认沙箱访问权限已启用。
- [ ] 确认生产环境入驻/KYC要求。
- [ ] 确认结算模型和对账报告可用性。
- [ ] 确认服务商方面的支持和升级联系人。
输出:
阶段 2 - 安全和配置基线
检查清单:
- - [ ] 定义所需的环境变量和密钥所有权。
- [ ] 将凭据存储在安全的密钥管理器中(不要存储在聊天记录或源代码管理中)。
- [ ] 为沙箱和生产环境定义Webhook端点URL。
- [ ] 定义IP白名单/认证/签名验证策略。
- [ ] 定义支付日志和PII的数据保留策略。
输出:
- - 配置清单(环境名称 -> 密钥 -> 负责人 -> 轮换策略)
阶段 3 - 构建最小可行支付流程
检查清单:
- - [ ] 创建包含幂等锚点的订单/支付记录模型。
- [ ] 实现支付发起端点。
- [ ] 实现带有签名验证的Webhook接收器。
- [ ] 实现支付状态转换及转换护栏。
- [ ] 实现对过期待处理交易的对账任务。
输出:
阶段 4 - 测试矩阵和证据
运行并捕获以下证据:
- - [ ] 成功支付
- [ ] 失败支付
- [ ] 超时导致对账
- [ ] 重复的Webhook投递
- [ ] 乱序的Webhook序列
- [ ] 退款(如果在范围内)
- [ ] 授权创建/取消(如果包含定期支付)
输出:
- - 测试证据日志(截图、追踪信息、ID、预期结果与实际结果对比)
阶段 5 - 运营就绪
检查清单:
- - [ ] 监控仪表板已上线(成功率、待处理老化、Webhook失败)。
- [ ] 告警已配置(失败激增、待处理积压、对账失败)。
- [ ] L1/L2支持运行手册已批准。
- [ ] 事件沟通模板已批准。
- [ ] 值班所有权和升级路径已确认。
输出:
阶段 6 - 上线门禁审查
门禁必须全部通过:
- - [ ] 关键测试用例通过
- [ ] 无未解决的P0/P1支付缺陷
- [ ] 回滚程序已测试
- [ ] 财务对账演练已获财务部门认可
- [ ] 合规签字已记录
输出:
智能体行为规则
当用户请求启动帮助时:
- 1. 确定当前阶段(0到6)。
- 仅返回该阶段缺失的任务。
- 明确将阻塞项标记为 BLOCKER。
- 如果任何门禁未完成,不要建议上线。
- 保持输出可操作,包含负责人和截止日期字段。
输出模板
请使用以下格式:
text
当前阶段:
已完成:
缺失:
- - [BLOCKER] <任务> | 负责人:<姓名/角色> | 截止日期:<日期>
- <任务> | 负责人:<姓名/角色> | 截止日期:<日期>
下一个里程碑:
配套文件
相关技能
- - upi-payment-integration:用于实现和技术可靠性控制
- upi-payment-ux-ops:用于客户沟通和支持就绪