呼び出しが一度通った画面
連携の相談は、つなぐサービスの名前で入ってくることが多い。決済、地図、SMS、ログイン。名前だけ見ると作業量は似ているのに、返ってくる見積もりは揃わない。
開発する側にとって最初の成功は早い。ドキュメントの例をそのまま入れ、テスト用のキーを発行し、応答が返るのを確認するところまではさほど時間がかからない。画面に決済シートが出て承認のメッセージが見えれば、つながったと言ってよい。
ただしその画面はうまくいった一件だ。サービスを公開すると、うまくいかなかった件が毎日入ってくる。連携の範囲を決めるとはその件を数える作業であり、見積もりが分かれる場所もたいていそこにある。
アカウントと審査が先に日程を押さえる
外部サービスには、開発者だけでは開けないものが少なくない。事業者の名義で申請し、書類を出し、審査を待ってから本番用のキーが出る。お金や本人情報、送信系が絡むものはおおむねこの手続きが付く。
この期間は開発日程の中にない。コードをどれだけ早く書いても承認が下りるまで実アカウントでは確認できないし、承認の条件に自社の画面や規約の文言が入ることもある。一度差し戻されれば、直して出し直す分だけまた後ろにずれる。
だから連携の見積もりでは、申請を誰がやるのかを先に決めたほうがよい。アカウント取得と審査対応まで任せるのか、そこは自社で進めて開発だけ任せるのかで日程表が変わる。
テスト環境では通り、本番では止まるもの
多くの提供元はテスト用の環境を別に用意している。そこではカード番号を何にしても承認が返り、SMSも実際には飛ばない。開発と確認はその中で完結する。
本番に移すと条件が付く。呼び出し元のドメインやサーバーのアドレスを事前に登録させるところがある。結果を受け取るアドレスが外部から到達できる正式なものであることを求めるところがある。精算口座や送信元の情報が登録内容と一致しなければ弾くところもある。
これらは開発の問題ではなく準備物の問題だ。そして準備物が欠けていると、開発が終わっていても公開できない。本番移行に必要な一覧を着手時点で受け取っておくことが、この区間を縮める方法になる。
失敗し、重複し、取り消される流れ
成功経路は一つだ。失敗経路はいくつもあり、連携の作業量はたいていそちら側に寄っている。
代表的なのは応答を待つ途中で時間切れになる場合である。こちらには失敗として残り、相手側では処理が終わっていることがある。利用者は通らなかったと思ってもう一度押すので、同じ要求が二回入る。同じ要求を二回受け取っても一度だけ処理する仕組みと、双方の記録を突き合わせる画面がここで必要になる。
取り消しと返金は別の流れになる。全部の取り消しと一部の取り消しでは扱いが違い、相手側ですでに精算が済んだ後はさらに手順が変わる。結果を知らせる通知が重複して届くことも珍しくないので、同じ通知を何度受け取っても結果がずれないようにしておく。
これらをどこまで作るかが連携範囲の中身になる。つなぐサービス名と一緒に「取り消しはどう扱うか」への答えがあれば、見積もりの精度が大きく上がる。
相手が仕様を変える日
連携はこちらのコードがそのままでも壊れることがある。提供元が旧バージョンの提供を終える、応答にあった値がなくなる、認証方式が変わる。告知は前もって届くが、その告知を受け取るのはアカウントを作った人だ。
つまり連携は一度作って終わる項目ではなく、見続ける項目に近い。少なくとも提供元からの告知が読まれるアドレスに届くようにしておき、つないでいる外部サービスの一覧と各アカウントの名義を一枚にまとめておくと、後がずいぶん楽になる。
つなぐサービスの名前だけでも送ってください
Weple では連携のご相談を受けたとき、何をつなぐかより、どの場合まで面倒を見るかを先に整理します。アカウントと審査を誰が持つのか、本番移行に何が要るのか、取り消しと重複をどこまで扱うのか。分けて書き出すと範囲が見えてきます。どんな単位で金額を付けるかは料金案内に出しています。整理した結果、いまはつながないほうがよいという結論になれば、代わりの手も一緒に探します。
似た状況なら
今の状況を送っていただければ、24時間以内に範囲と料金を返信します。