決済フォームの検証は、うまくいったときの画面を確認して終わりにしがちです。しかし実際に問い合わせが集まるのは、断られたときの表示、二重に送ってしまったときの挙動、通信が切れたあとの復帰といった場面です。この記事では、公開前と変更時に見ておきたい項目を、確認しやすい順に並べます。すべてを毎回実施する必要はありませんが、少なくとも一度は通しておくことを勧めます。
確認の前に決めておく基準
ここでは、判断の基準と、その基準で埋めていく状態の組み合わせを合わせて確認します。
項目をなぞるだけでは、判断が人によってぶれます。着手前に、次の点を文章にしておくと、あとで揉めません。
- 対応するブランドと桁数の範囲
- テストで使う番号の入手元と、その出典の記録方法
- 拒否の理由を利用者にどこまで伝えるか
- 追加認証を必須とする条件
- 決済の完了をどの通知で判定するか
最後の項目はとくに重要です。画面の戻り値だけで完了と見なすと、後から状態の食い違いが生まれます。確定はサーバー側が受け取る通知で判定する、という原則を先に決めておいてください。
項目を列挙するより、状態の組み合わせを表にして埋めるほうが抜けが減ります。
| 軸 | 取り得る状態 |
|---|---|
| カード情報の妥当性 | 形式が正しい、桁数不足、チェックサム不一致、未対応ブランド |
| 追加認証 | なし、成功、失敗、中断 |
| 通信 | 正常、遅延、タイムアウト、無応答 |
| 操作 | 1 回送信、連打、戻る、再読み込み |
| 結果 | 成功、拒否、保留、重複 |
すべての組み合わせを試す必要はありません。各行から代表を 1 つ選び、隣り合う状態の境界を確認する形が現実的です。
拒否されたとき、画面は何を伝えるべきか？
拒否は、利用者がもっとも不安になる場面です。表示だけでなく、その後の導線まで見てください。理由が利用者の言葉で伝わるか。内部の識別子がそのまま画面に出ていないか。別のカードを試す導線があるか。拒否のたびに注文が増えていないか。問い合わせ対応のために、失敗の記録が残っているか。
理由の伝え方には線引きが必要です。利用者が自分で直せる問題は具体的に伝え、直せない問題は一般的な表現にとどめます。この基準を決めておけば、担当者ごとに文言がばらつくことを防げます。
二重課金を防ぐ仕組み
通信の失敗は必ず起きるものとして設計します。原則は、同じ操作を 2 回実行しても結果が 1 回分にしかならないことです。確認したい点を挙げます。
- 送信ボタンが処理中に無効化され、見た目でも状態が分かるか
- 同じ操作であることを示す識別子をサーバーで受け取り、再送を同一処理として扱っているか
- 戻るボタンや再読み込みで、決済が新しく始まらないか
- 注文は作られたが決済は未確定、という中間状態を明示的に扱っているか
- 二重の要求が届いたときに、後から来たほうを安全に捨てられるか
連打は、通信が遅い環境で自然に発生します。意図的に連打するテストを必ず 1 件入れてください。
タイムアウトしたとき、決済の状態はどう確定させるか？
決済事業者からの応答が返らない場合、結果は成功とも失敗とも言えません。この状態を放置すると、利用者には失敗に見えるのに実際には課金されている、という最悪の食い違いが生まれます。必要なのは、結果を照会する手段です。決済の識別子を手元に残し、後から状態を問い合わせて画面を確定させます。
テストでは、応答を意図的に遅らせるか、返さない状況を作って、画面がどう振る舞うかを観察します。読み込み中の表示が出続けないか、利用者が再読み込みしたときに二重の決済が始まらないか。この二点が確認できれば、多くの事故は避けられます。
返金と取消の確認
販売後の操作も、決済機能の一部です。全額の返金が正しく処理され、注文の状態が更新されるか。一部返金の金額と残額の計算が合っているか。返金を二重に実行していないか。返金の記録が後から追えるか。端数のある金額を含めて確認してください。丸めの扱いによる差は、金額が大きくなってから表面化します。
追加認証の画面から戻ったとき
追加認証は、アプリケーションの外側の画面で行われます。したがって、戻ってきたときの状態の復元が難所になります。認証へ進む条件が一貫しているか。認証を終えて戻ったとき、入力していた内容が復元されるか。認証を中断した場合に、中途半端な注文が残らないか。結果を画面から渡された値ではなく、サーバー側で検証しているか。
とくに最後の点は省略されがちです。画面が持ってきた結果をそのまま信用すると、認証を迂回できてしまいます。
開発者向け: 入力の品質と自動化
入力欄そのものの品質も、決済の完了率に直結します。ラベルが各欄に結び付けられ、読み上げで内容が分かるか。ブラウザの自動入力が機能するよう、適切な属性が指定されているか。キーボードだけで最後まで操作できるか。エラーが色だけで示されていないか。ブランドによって変わるコードの桁数に、入力欄が追従するか。
自動テストにする場合は、状態の組み合わせを表として持ち、各セルに 1 つのテストを対応させます。テストに使う番号は、構造としては妥当でも実際には発行されていない値です。決済事業者が公開するテストカードも、自分で作った番号も、本番のカードとして扱ってはなりません。決済の状態を表す語彙は事業者の定義に従い、自前の言い換えをしないでください。テスト同士が同じ取引を共有すると並列実行で壊れるため、各テストが自分の取引を作る形にします。検証ロジックの堅牢さは カード番号の検証 で、環境とデータの扱いは PCI DSS とテストデータ で確認してください。テスト用の番号は テスト用クレジットカード番号生成 でまとめて用意できます。
次のステップ
この一覧を上から順に一度通し、確認できなかった項目に印を付けてください。印が付いた項目が、次に着手すべき場所です。あわせて、失敗したときに原因を切り分けられるだけの記録が残っているかを確かめておきましょう。記録がなければ、どんな不具合も再現から始めることになります。