最近公司在对接菲律宾的一个二维码支付，QR PH，它是一个由菲律宾国家层面主导的一个无现金支付系统，类似国内的微信支付宝扫码付款。这个支付系统是基于EMVCO 的MPM（Merchant Present Mode)模式做的。任何接入方需要遵循这些规范，当然这个EMVCO 规范是比较通用的，在菲律宾下它扩展了一些信息，EMVCO 本身是支持使用的支付系统进行扩展并且是在规范上预留了可扩展的范围已经说明。

在菲律宾的规范下，任何接入方跟国家下的一个机构（PPMI）对接就可以。只要接入方都遵循规范，大家各自生成的商家二维码都可以被别的接入方识别并且能完成支付，同样的各个接入方也有自己的应用，通常是App，支持扫码识别其它接入方生成的商家码。因为历史原因，与菲律宾PPMI 对接的实现是交给一个外包公司S做的，这家公司已经接了公司印尼的银行核心系统。笔者这边就负责二维码的生辰和识别部分，就卡在中间的位置，首先要了解二维码的规范并把二维码解析后的数据按照S公司提供的API 与他们进行一次交互后，这个系统才会把请求发给PPMI，最后完成一个支付流程。在这个过程中发现有很多不适，虽然不是第一次跟这个S公司的人打交道，但是过程还是很不开心的。

API 定义

因为要跟PPMI 对接，S 公司会根据PPMI 的接口文档梳理一份提供给笔者这边调用的API。正是这份API 文档，让笔者最开始就感受到不适。

S公司第一次提供API 文档的时候是在企业微信群中发了一个文件，一个Excel 文件。当我看到的时候第一句话就问“文档可以上云吗？”，一天后没有反应，实在无法忍受后自己主动上传到Google sheets，开了共享后就把链接在群里发出来。都这个年代了还在即时聊天工具中，通过发文件的方式来达到协作，实在是无法理解，也不敢去理解。这份文档本身是没有定档的，还需要不停地修改，并且会有一些问题的补充和调整的。还有就是用Excel 提供API 文档？我都不敢想象，里面的层级什么的，乱七八糟，要看这份文档需要克服很大心理压力。你可以知道我司是有wiki 的，而且这个问题都不是第一次提出来跟他们说过。

接口字段的命名，各种单词缩写。在写代码时，完全无法根据理解到的业务去传值，每一个字段的赋值都要看一下定义，才能确定自己没有弄错，实在无奈的情况下给各个字段起了别名，这样才能在写码时手能跟上脑子。

才发现，他们把PPMI 接口的字段名称原封不动不动地挪过来，同事称之为“不粘锅”，PPMI 系统交互参数时基于ISO 20022。完全不做过滤，他们理解一遍又要我们再理解一遍，完全不考虑防腐层，导致不停地沟通。

特别生气的点在于，他们在笔者开始接入这个系统时就已经说在补充单元测试了，第几轮的自测了。可是在汇报进度和风险点时，却又说如果笔者这边的系统没有好的话，他们是无法和PPMI 这边做测试的。听到后我不太确定这段时间他们在测试什么。一个系统按照规范接入了一个标准系统（上游）后，却说不能与之联调，要等它的下游系统好了后才能联调，这种鬼话都能说出来。

收钱后真的是可以为所欲为。

技术规范文档阅读

一直以为，如果要接入一套标准、规范完善的系统时，应该把它的文档认真阅读一遍，原来是我太天真了，没想到还可以关键词阅读。

这里我想举一个例子来说明一下我的感受。

二维码的规范中定义了一个字段F，是如下的要求

• ID：28-03
• Format：ANS，这个术语的描述是：“Combination of Alphabet,Numberic and Special Characters”
• Length：1..25,表示1到25位可变长度。

这个F 字段要提交到S 公司定义的API 中，对应的字段C 的约束如下。

• [0-9]{8,28}，是一个正则表达式，8到28位的数字

基于上面的例子，笔者就向其中一位负责API 定义的工程师反馈说，这个字段C的要求可能有问题，看看是不是文档看错了还是哪里没有衔接上。没想到他反客为主，问我“你有见到过二维码中字段F 里的值带有字母的吗？”，因为在研究二维码时曾看了一些别的接入方生成的二维码，这个字段的内容都是纯数字，笔者很直接地回答说“没有”，他竟然说“没有看到的话，那么这个字段就认为是纯数字吧。”，我着急了说“你不能因为没有看到有这样的二维码，何况我们之看了两家的码，来得出结论说字段F 的值不可能包含字母”。

“你是否认同字段F 的值在文档规范下是可以包含字母的？”，“不同意”，笔者掩面。

“文档上格式上写的是ANS，不是说就会有字母出现”。笔者摊手。

“我可以找一个别的字段，在文档上规定的格式是ANS，在二维码上确实出现过字母”，“我看看”，笔者翻白眼。

这种情况出现了无数次，真的要崩溃了。