SMARTPAY

QRPH 系统维护期间商户收款怎么办?影响范围判断与应对方案

上个月一个周二凌晨,我们后台的QRPH收款曲线突然从平时的锯齿状变成了一条直线。客服群里开始有客户反馈"扫码之后页面转圈,钱没扣但也没收到确认"。我第一反应是自己系统又出bug了,翻了半天日志才在钱包方的状态通知里看到"系统维护"的字样。那一刻我才意识到,QRPH作为菲律宾央行牵头的统一二维码标准,背后挂着多家银行和电子钱包的清算节点,只要有一个环节在做维护,商户这边感知到的就是"收不到钱"。这篇文章把我们这几次踩坑之后整理出的判断逻辑和应对方案写出来,给同样在本地经营、自己扛技术决策的同行一个参考。

QRPH维护到底是在维护什么

QRPH不是某一家公司的系统,而是一套由多方共同遵守的二维码支付标准,参与方包括发码行、收单机构、电子钱包和清算网络。所谓"维护",可能是某家银行在升级自己的清算接口,也可能是整个二维码标准层做版本切换,还可能只是某个钱包在做自己的内部升级。商户感受到的现象是一样的——扫码、唤醒、回调通知,某个环节卡住了——但背后的责任方、恢复节奏完全不同。搞清楚这一点,是后面所有应对动作的前提,否则很容易把"钱包方的维护"当成"我们网关出问题",或者反过来。

我们踩过的三种典型表现

第一种是扫码能生成,但客户扫完之后App端一直转圈,既不成功也不失败,这种多半是清算路径中断,订单其实没有真正进入处理队列。第二种是扣款已经发生,但商户端的支付回调迟迟不到,这是最让人紧张的情况,因为客户会觉得"钱扣了东西没买到",投诉集中爆发。第三种是整个二维码直接刷不出来或者提示通道暂不可用,这种反而最好处理,因为现象明确,可以第一时间在前端做提示,引导客户换别的收款方式。三种表现里,第二种——回调延迟导致的信息差——是最容易引发客户信任危机的,也是我们现在重点监控的对象。

先分清楚:是维护,是故障,还是我们自己的锅

这三者处理方式完全不一样,混淆了会白白浪费排查时间。计划内维护通常会有提前通知,可能来自钱包方的商户公告、合作网关的站内信,或者行业群里的转发,特点是有明确的时间窗口。故障是没有预告的异常,往往影响范围更随机,可能只是某个地区、某个钱包版本的用户受影响。而我们自己的锅,最常见的是签名算法改动后没同步测试环境,或者服务器时间没对齐导致签名过期——这类问题的共同特征是"别的商户没反应,只有我们出问题"。遇到异常第一件事,我会先查自己最近7天有没有发布新版本,再去看通道状态接口返回的内容,最后才去问客服,这个顺序能省掉大半排查时间。

持牌支付机构在这类事件上的责任边界是清楚的:持有BSP OPS或EMI牌照的机构,需要对资金路径和清算异常承担披露义务,这也是为什么维护公告、故障通报这件事,正规持牌网关会做得比非持牌代理更及时、更有据可查。

商户的三级响应:按通知渠道和影响范围分诊

我们现在内部定了一套简单的分级规则。第一级是"收到提前通知、窗口在凌晨低流量时段"——这种我们只需要在维护窗口前后各留半小时观察期,前端不用特别提示,客户基本感知不到。第二级是"收到通知但窗口覆盖了白天的业务高峰,或者波及多家钱包"——这种需要提前在结账页加一条临时提示,引导客户优先用其他已开通的收款方式,同时客服话术提前准备好。第三级是"完全没有预告、现象已经发生"——这种要第一时间切断新订单入口里对该通道的默认展示,启用备用通道,并同步记录受影响订单号,等通道恢复后逐条核对,而不是等客户来找。分级的核心目的是避免每次异常都用最重的应对方式,也避免轻视真正影响大的那一次。

技术层面:通道状态查询和故障转移怎么写

比起等人工播报,更稳的做法是让系统自己定期查通道状态,一旦检测到维护或异常,自动把新订单路由到备用通道,同时把正在处理中的订单标记为"待核对"而不是直接判失败。下面是我们现在生产环境里简化后的查询逻辑:

curl -X GET "https://api.smartpay-gateway.ph/v1/channel/status?channel=QRPH" \
  -H "Authorization: Bearer ${API_TOKEN}" \
  -H "Content-Type: application/json"

# 典型返回
# {
#   "channel": "QRPH",
#   "status": "maintenance",
#   "scope": "partial",
#   "affected_participants": ["bank_x", "wallet_y"],
#   "estimated_recovery": "2026-10-04T05:30:00+08:00",
#   "notice_id": "MNT-20261004-001"
# }

拿到这个状态之后,我们在下单逻辑里加了一层判断,如果状态是维护且范围是全局,就自动切到备用通道并记录日志,方便后续对账:

async function createOrder(order) {
  const status = await checkChannelStatus('QRPH');

  if (status.status === 'maintenance' && status.scope === 'full') {
    logFailover(order.id, 'QRPH', status.notice_id);
    return createOrder({ ...order, channel: 'GCASH_NATIVE' });
  }

  if (status.status === 'maintenance' && status.scope === 'partial') {
    // 局部维护,先标记订单来源通道,等结果而不是直接判失败
    order.pendingReview = true;
  }

  return gateway.pay(order);
}

这套逻辑的关键不是"自动切换"本身,而是QRPH 商户 API 接入怎么做?接口、验签与生产切换流程里反复强调的那一点:切换通道之后的验签方式、回调格式都不一样,如果平时没有把多通道的签名逻辑统一封装好,真遇到维护的时候临时切换反而容易出新的bug。

不同维护场景,商户应该怎么应对

场景典型信号建议应对是否需要联系客服
计划内短时维护(窗口在凌晨)提前收到公告,窗口明确窗口前后留观察期,无需前端提示不需要,记录即可
计划内维护覆盖业务高峰提前通知但时间跨白天结账页临时提示+引导切换收款方式建议提前报备,方便事后对账
突发无预告下线无通知,订单卡住或回调缺失立即切备用通道,标记受影响订单需要,优先确认资金是否在途
单一钱包或区域性异常部分客户正常、部分异常不下架通道,仅对异常客户提示换方式视投诉量决定

维护结束后,别急着说"恢复了"

通道状态变回正常不等于资金链路已经全部跑完。我们吃过一次亏:维护一结束就把订单全部判定为成功,结果有几笔其实是维护期间卡在清算队列里、延后才真正到账的,对账的时候多算了一遍收入。现在的做法是维护结束后,把维护窗口内的所有订单单独拉出来做一次人工复核,重点看三件事:有没有客户端显示失败但实际扣款成功的"幽灵订单";有没有回调补发导致的重复记账;以及备用通道在维护期间处理的订单,有没有正确并入统一对账流程。这一步做好了,基本可以避免维护事件变成财务纠纷的源头。遇到长期查不到结果的订单,QRPH 收款没到账排查清单:8 步定位与商户申诉里的排查顺序可以直接套用。

把这次维护变成下一次的预案

每次维护事件处理完,我们都会补一条到内部的应急手册里:这次是哪个参与机构的维护、提前通知的渠道是什么、我们的响应是否及时、哪一步浪费了时间。坚持几次之后,手册里已经能覆盖大部分常见场景,新同事遇到类似情况可以直接照着做,不需要每次都临时决策。如果维护期间产生了争议订单,走正式的QRPH 争议处理怎么做?退款、拒付与商户申诉流程会比自己和客户私下协商更有留痕,对双方都更安全。想了解QRPH背后到底有哪些机构在参与、维护责任可能落在谁身上,可以参考QRPH participants 参与机构完整名单:银行、钱包与商户接入路径;想搞清楚维护期间"钱卡在哪一步"的清算逻辑,实时支付清算是什么?清算与结算的区别、QRPH/InstaPay 角色分工解析讲得比较系统。

我们选择长期合作持牌网关,很大一部分原因也是维护期间的信息透明度——BSP OPS/EMI持牌机构在通道异常时有对商户的披露义务,这意味着维护公告、状态接口、事后对账支持这些东西不是"锦上添花",而是合规要求的一部分,这一点在挑选合作方的时候值得重点确认。

常见问题

QRPH维护一般会提前多久通知商户?

这个要看具体是哪个参与机构发起的维护,没有统一标准。计划内的维护通常会提前有公告,但提前量因机构而异,我们的经验是不要假设"一定会提前收到",而是把通道状态查询做成日常监控的一部分,公告收到了算加分,没收到也不至于完全蒙在鼓里。

维护期间客户说钱扣了但订单没确认,钱去哪了?

多数情况下资金其实是卡在清算队列里,而不是真的丢失,等维护恢复、队列重新跑通之后大概率会补上回调。我们的做法是先把这类订单标记为"待核对"而不是直接判失败,等通道恢复后用订单号主动查询,而不是急着给客户退款或者重新扣款,避免后续对账出现两套记录。

维护期间能不能临时切到别的收款通道?

可以,也建议这么做,但前提是备用通道的接入、验签逻辑平时就要维护好,不能等到维护当天现写代码。如果只接了QRPH一条通道,维护期间基本没有退路,这也是我们后来坚持至少保留两条可用通道的原因。

怎么分清是QRPH维护还是我们自己系统的问题?

先看范围:如果只有我们一家商户出问题,大概率是自己的签名、证书或者服务器时间出了偏差；如果同行群里也有人在反馈类似现象,基本可以确认是通道侧的事情。另外养成查通道状态接口的习惯,比凭感觉判断靠谱得多。

维护结束后多久能确认所有订单都正常了?

没有固定时间,取决于维护期间积压的订单量和清算队列的处理速度。我们的原则是不设截止时间,而是设一个复核清单,把维护窗口内的订单全部跑完对账逻辑之后才算"确认完毕",而不是看到状态恢复正常就直接收尾。

维护期间要不要主动跟客户解释原因?

建议解释,但不需要讲太多技术细节。一句"当前收款方式正在升级维护,建议使用备用方式完成支付"比什么都不说要好很多,能明显减少客服端的重复咨询和投诉情绪。

商户自己要不要做监控,还是等通知就够了?

我们现在的结论是必须自己做监控,通知这件事本质上是对方单方面的善意告知,不是合同条款里写死的实时义务。把通道状态查询接到定时任务里,比被动等公告要主动得多,也是这篇文章想强调的核心习惯。

QRPH维护这件事,躲不开也防不住,能做的只是把判断流程和应对预案提前准备好,出问题的时候不慌,恢复之后能把账对清楚。如果你在搭建通道状态监控、故障转移逻辑,或者维护期间的订单核对流程上需要具体建议,可以直接找我们聊:@LouisSMARTPAY,或者邮件 [email protected]。

相关推荐