決済のQA観点

はじめに

売買などの支払い機能を有するWebサービスの場合、新しい決済方法（なんとかペイとか）を導入する時や、決済に関するコードをリファクタリングする時や、決済代行会社を変更する時などに、決済周りについて網羅的に検証をする機会が定期的にあると思います。そういうテストエンジニアの方向けに、決済の検証をする際のQA観点をまとめてみました。

はじめにお断りしますが、この記事のテスト観点では十分ではないと思います。ただ、なんらかの気付きがあれば良いと思い書きました。

正常に決済が完了することは当然なので、QAとして確認しないといけないのは、極論を言えばネガティブなケースの「期待通りに決済が失敗するか」と「期待通りに決済がキャンセルされるか」だと思います。

「期待通りに決済が失敗するか」

決済が失敗する条件は多数ありますし、どういう決済方法なのかに依存する部分は大きいと思います。思いつくところで言えば

クレジットカードの番号が間違っている
クレジットカードのCVVが間違っている
クレジットカードの名義人が間違っている
クレジットカードの有効期限が切れている
クレジットカードの利用上限を超えている
デビットカードの原資が足りない
途中で通信が遮断された
コード決済のコードのタイムアウト
利用制限されている
ブラックリストに入っているユーザーからの決済

など、挙げればキリが無いかもしれません。また、決済の前の段階で止められることが多いとは思います（クライアント側で制御してそもそもAPIリクエストを送れない等）が、QA観点としては含めて良いと思います。

「期待通りに決済がキャンセルされるか」

決済がキャンセルされると言っても、期待される結果はVoidなのかRefundなのか確認する必要があります。

大雑把に言えば、
Voidとは決済が確定する前に決済を取消して無かったことにすることです。Refundとは決済が確定した後に返金することです。

わかりやすい例としては、通信事業者のキャリア決済です。例えば2月の携帯電話料金が5000円だとして、キャリア決済で3500円のお買い物をしたとします。2月の携帯電話料金は翌月の1日に請求されるとします。その場合、決済の確定前にキャンセルが行われれば、決済は無かったことになるので2月の携帯電話料金は5000円です。もし、決済の確定後にキャンセルが行われれば2月の携帯電話料金は8500円になり、3月1日に8500円支払うことになり、3月の携帯電話料金から3500円引かれます。すなわち3月にキャリア決済を行わなかったとしたら4月1日の請求額が1500円になります。（実際は決済の確定時期は各通信キャリアによってことなるので上記のような状況になることはないかもしれません）

決済をキャンセルした場合にVoidもRefundもどちらもあり得る場合はどちらも検証することが必要になります。

また、

部分的にキャンセルが発生する状況の確認が必要になる場合もあり得るかもしれません。
在庫のある商品を複数個購入する場合、1個の決済なのか複数個の決済なのか仕様を確認する必要があります。
また、1個の決済の場合に注文した数の在庫が無かった時に全部不成立なのか部分的に成立する仕様なのか確認する必要があります。

例えば1個200円の商品を5個購入しようとしたら、他の人が購入した等により3個しか在庫が無かったとします。複数個の決済であれば3個の決済が行われることになると思いますが、お客様は5個買えないなら1個も要らないかもしれません。1個の決済であれば、全部不成立で1個も買えないかもしれませんし、3個は購入できるかもしれません。その場合は部分的にキャンセルされたことになります。

また、継続決済の場合も特別な考慮が必要かもしれません。継続決済（課金）とは、月額制のサービスや定期購入などの定額プランの引き落としなどに利用される、一定間隔で継続的に利用者から料金を徴収する支払い方法のことです。月の途中でキャンセルが行われた場合に、その月の料金は全額支払われることになるのか、日割りで計算した金額が請求されるかを確認する必要があるかもしれません。次の月に請求が止まることも確認しないといけないかもしれません。途中で決済方法が変更された（別のクレジットカードに変更等）場合に新しい方に切り替わるか等も確認しないと行けないかもしれません。