決済連携 着手点検表 · 国内PG・簡単決済

テスト着手と本番移行の条件を分けます。決済会社のテストキーと環境で開発できる範囲を確認し、該当する加盟店識別子とアクセス権を準備します。実決済は契約と審査、本番キー、その手段の有効化を確認した後に開始します。審査中の手段は、今テストできる範囲と本番で有効になる予定を分けて開発日程に反映します。精算口座と適格請求書の発行条件、精算周期が契約書と管理画面で同じ値かも着手前に揃えます。決済画面を開くドメインと結果を受け取るサーバーのアドレスは決済会社に事前登録が必要なので、開発環境と本番環境のアドレスを併せて提出します。本番キーを誰が保管しどこに置くかも着手前に決め、構成管理に入らないようにします。課金キーやエスクローのように別途審査が付く機能は、申請の時点を着手週に置きます。連携文書とSDKのバージョンもこのとき固定します。決済会社が複数のバージョンを併せて公開していることがあり、どの文書を正本とするか決めなければアプリとサーバーが別々の仕様を見て開発されます。

注文状態を先に描きます。決済要求、承認、承認失敗、取消、部分取消、返金、精算完了まで状態を名前で書き出し、各遷移を誰が起こすかを示します。部分取消を何回まで許すか、配送が分かれる注文の取消単位を何にするかもここで決めます。要求ごとに付ける固有キーをどう作るか、同じキーが再び届いたときに何を返すかをルールとして書きます。応答を受け取れなかった取引の扱いもコードの前に決めます。決済会社の照会仕様で状態を問い直す時点と回数、それでも確認できない取引をどの状態に置き誰に知らせるかが決まっている必要があります。決済金額を決める側も定めます。クーポンとポイントが混ざる注文は最終金額をサーバーで計算し直して承認要求と突き合わせ、食い違えば承認を送り出しません。

成功する決済で基本フローを確認してから、失敗と例外経路を再現します。承認拒否、限度超過、認証の中断、決済画面からの離脱、通知の欠落と重複受信を一覧に入れ、提供されるサンドボックスで再現できる範囲を確認します。それぞれの場合に注文がどの状態で残るか、顧客の画面に何が見えるか、再試行したときに承認が二度下りないかを見ます。部分取消と全額返金は同じ取引で順序を入れ替えて掛けてみます。金額が食い違う要求と、すでに取り消された取引をもう一度取り消す要求も入れて応答を確かめます。決済手段が複数あれば、手段ごとにこの一覧をもう一度回します。取消可能期間と返金手続きが手段ごとに違うためです。アプリとウェブを同時に出すサービスは、両方の環境で同じ一覧を回します。決済画面がアプリ内で開くときと外部ブラウザへ出るときで戻る経路が違い、離脱の処理が別に掛かります。

リリース日の前に、人が使う画面がある必要があります。注文番号で取引を探し、要求と承認、通知の受信、取消までを時系列で読む照会画面をサポートに先に開きます。承認失敗とエラーの推移を決済会社別に見る指標と、基準を外れたときに担当者へ知らせる経路も併せて有効にします。返金の実行権限は承認手順を定めた後に分けます。決済会社の障害をどこに申告し誰から返信が来るかを連絡先とともに書いておき、初回の実取引が入る日には承認と取消を一件ずつ実際に回して精算ファイルにそのまま計上されるかを確かめます。このとき押さえるのは突合ルールではなく突合に使う項目です。取引識別子と承認番号、手数料が付く時点がファイルにどの名前で届くかを書き留めておけば、精算担当がルールを作るときに問い直さずに済みます。症状ごとに最初に開く画面と引き渡す担当を書いた一枚を、サポートの席に貼っておきます。