串接是從第一次打通之後才開始算範圍

打通一次的那個畫面

串接需求大多是以服務名稱的形式進來的。金流、地圖、簡訊、登入。名字看起來工作量差不多，報價回來卻各不相同。

對開發的人來說，第一次成功很快。把文件裡的範例原樣貼進去，申請一把測試金鑰，看到回應回來，這一段花不了多久。畫面上跳出結帳頁、出現一則成功訊息，說接好了並不誇張。

只是那個畫面是順利的那一次。產品上線之後，不順利的那些每天都會來。定串接範圍，就是把這些情況數清楚，報價拉開差距的地方基本也在這裡。

開戶與審核先占掉行程

不少外部服務不是工程師一個人能開的。要用公司主體去申請，交文件，等審核過了才有正式環境的金鑰。凡是牽涉金流、實名資料、對外發送的服務，基本都帶這道流程。

這段時間不在開發排程裡。程式寫得再快，審核沒下來就沒辦法用真實帳號驗證，而審核條件裡有時還包含你自己的頁面或者條款文字。被退回一次，改完再送，又往後挪一截。

所以談串接報價，第一件要定的是誰去申請。把開戶與審核往來一併交出去，和自己去跑、只把開發交出去，排出來的時程表是兩回事。

沙箱過得去、正式環境過不去的那些

多數服務商會另給一套測試環境。在那裡卡號隨便填都會通過，簡訊也不會真的送出去，開發和自測都在這個環境裡完成。

切到正式環境就開始附加條件。有的要求把呼叫端的網域或伺服器位址事先登錄。有的要求接收結果的位址必須是外部能連到、憑證齊全的正式位址。有的會核對結算帳戶或者發送方資料，和登錄內容對不上就直接擋掉。

這些都不是程式問題，是備料問題。而備料沒齊，程式寫完了也上不了線。在啟動階段就把上線所需的清單要過來，是壓縮這一段最直接的辦法。

失敗、重複與取消的流程

成功路徑只有一條。失敗路徑有好幾條，串接的工作量大多堆在這幾條上。

最典型的是等回應等到逾時。你這邊記成失敗，對方那邊其實已經處理完了。使用者以為沒成，再按一次，同一筆請求就進去了兩次。到這裡就需要一套機制，讓同一筆請求收兩次也只處理一次，再加一個把兩邊紀錄對起來的介面。

取消與退款是另一條線。整筆取消和部分取消不一樣，對方已經結算過之後流程又會變。通知結果的回呼重複送達也很常見，所以同一則通知收幾次，結果都不能對不上。

這些流程要做到哪一步，才是串接範圍的真正內容。詢價時把要接的服務名稱，連同「取消怎麼處理」的答案一起給過來，報價會準得多。

對方改規格的那一天

你的程式一行沒動，串接也可能壞掉。服務商會停掉舊版本，會把回應裡原本有的欄位拿掉，會換掉驗證方式。通知是會提前發的，但它發給的是當初開戶的那個人。

所以串接不像一次做完就結束的項目，更像需要一直看著的項目。至少把服務商的通知信導到一個真的有人看的信箱，再把接進來的外部服務和每個帳號掛在誰名下，整理成一頁。這一頁以後會幫上大忙。

把要接的服務名稱寄過來就行

Weple 接到串接需求，會先把它變成一個關於情況的問題，而不是關於服務的問題。帳號與審核誰來扛，上線之前對方要什麼，取消與重複要處理到哪一步。分開寫出來，範圍就露出來了。按什麼單位計價，價格說明裡寫著。要是理下來發現某個服務現在還不值得接，我們會陪你把繞過去的路一起找出來。