上周日，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就可以了，產品經理煞費苦心的需求設計也可以付諸東流了，
附上支付寶官網對支付寶安全發這種模式的簽約入網流程圖，
當看到一些不好的代碼時，會發現我還算優秀；當看到優秀的代碼時，也才意識到持續學習的重要！--buguge
本文來自博客園，轉載請注明原文鏈接：https://www.cnblogs.com/buguge/p/16573772.html
<style>hr.signhr{width:80%;margin:0 auto;border: 0;height: 4px;background-image: linear-gradient(to right, rgba(0, 0, 0, 0), rgba(0, 0, 0, 0.75), rgba(0, 0, 0, 0))}</style>
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/501529.html
標籤：其他
上一篇：網路抓包工具