上周日，2022年8月7日，参加了一场久违的半马。中伏天的傍晚，热度不减，全程挥汗如雨，虽不是PB，但也算尽力。晒一下战绩。
支付宝安全发这个通道要对接，今天上午10点，产品经理跟我们开发小组过需求。
与历往通道不太一样的是，这个通道的商户入网不是全部由系统间api调用来完成的，而是需要客户介入，客户在支付宝的签约页面先完成签约，然后系统才能继续调用相关开户api来完成开户。
其中，我们要调用支付宝api来获取这个签约页面url，然后我们的运营人员在oms系统复制这个url给客户，客户接下来在支付宝这个签约页面完成签约入网。
产品经理说这个签约url的有效期是100s，可以想象，短短的100s内完成运营把url发给客户、客户再打开url去操作，是一个非常难的事情。所以，产品经理在需求层面煞费苦心，页面、api调用机制、数据展示，等等。
开发小组的几个人，包括QA，但凡有一些支付或系统研发经验的，都对这个100s表示吃惊，所以，大家对这块需求听得也比较入神。
当然，包括我，也觉得吃惊，依据既往经验，我对此倒是很好奇，一方面我要亲自了解一下支付宝的原始文档，分析一下这么做的初衷。另一方面，我要根据产品经理掌握的线索，来求证一下是不是产品经理误解了呢。
整个需求过完后，我提出了我的想法。
产品经理打开支付宝的官方文档，在页面上ctrl+F搜索“100s”，定位到的结果一下子为我们解惑。
还真是产品经理误解这个100s了！——————它不是签约页面的有效期是100s，而是签约页面上的签约二维码的有效期是100s。也就是说，这个签约页面是没有有效期的，这样一来，我们只需要调用一次api获取到这个签约url就可以了。产品经理煞费苦心的需求设计也可以付诸东流了。
附上支付宝官网对支付宝安全发这种模式的签约入网流程图。
