はじめに
「決済機能の実装」と聞くと、ちょっと身構えてしまいませんか？
私は下記の理由でできれば触りたくないと思っています。
- お金関係でミスしたら怖い
- セキュリティが複雑そう
- テストが大変そう
とはいえ、「触りたくない」と言って許されるわけではないので、私は以前、Stripeを利用して決済機能の開発に携わったことがあります。
でも実は、多くの決済サービスには 本物のお金を使わずに、安全にあらゆる決済を再現できる仕組みが用意されています。
それが、今回紹介する 「テストカード（Test Card）」 です。
この記事では、PAY.JPなどの例を用いながら、テストカードの仕組みや使い方を簡単に紹介できたらと思いますので、「決済って難しそう」と思っている方はぜひ読んでいただけると幸いです。
近年、決済手段はQRコードや後払いなど多様化していますが、クレジットカード決済は依然として主力であり、その実装とテストの知見は不可欠です。
テストカードがなぜ必要なのか？
テストカードとは、開発・テスト環境専用の仮想クレジットカード番号です。
実際の金融機関とはつながっていないため、お金が動くことは一切ありません。
そのため、安全に、本番と同じような決済動作を再現することができます。
テストカードのメリット
- お金を使わずに安心テスト
- 実際の決済は発生しないので、誤って課金される可能性はゼロ
- セキュリティリスクなし
- 本物のカード情報を扱わないので、情報漏えいのリスクもありません
- いろんな状況を再現できる
- 「決済成功」「残高不足」「有効期限切れ」「不正利用疑い」など、番号を変えるだけでさまざまな結果をテストできます
- テストが高速化
- 実際にクレジットカード会社への通信等はないので、すぐに結果を確認できます
テストカードの仕組み
国内の決済サービス PAY.JP を例に、テストカードの使い方を見てみます。
カード番号で挙動を変えられる
PAY.JPでは、カード番号そのものがテスト結果を指示するようになっています。
たとえば以下のように、番号を変えるだけで「成功」「エラー」などの挙動を再現できます。
| テストカード番号 | 結果 | 検証できるポイント |
|---|---|---|
4242 4242 4242 4242 |
決済成功（通常） | 正常な決済後の在庫更新や通知処理 |
4000 0000 0000 0002 |
残高不足（エラー） | ユーザーにエラーメッセージが出るか |
4000 0000 0000 0003 |
有効期限切れ（エラー） | 入力チェックやUIの挙動 |
つまり、テストカードの番号を変えるだけで、「成功・失敗・エラー」などのパターンを自在に試せるというわけです。
開発時に確認しておきたい項目
テストカードを使えば、以下のようなケースを安心して検証できます。
- 正常系
- 決済成功後、注文確定・在庫引き落とし・通知メールなどが正しく動作するか
- サブスクリプションモデルであれば、購入時にステータスが更新されるか
- ユーザー起因の異常系
- 認証失敗、残高不足、使えないカードブランド、有効期限切れなどのエラーが発生したときに正しいメッセージや再入力フローが機能しているか
- システム起因の異常系
- 通信エラーや決済サービス側の障害時に不整合が起きない、エラーメッセージがわかりやすいかなど
意外とエラーの種類が多かったりするので、横着してエラーメッセージをまとめたくなりますが、結局問い合わせでの工数が増えたりするので、テストカードで網羅できる分だけ分けて表示した方が良いです。
まとめ
決済機能の開発は、確かに慎重さが求められます。
でも、テストカードという安全な仕組みがあるおかげで、開発段階で不安を感じる必要は全くありません。
冷静に考えれば「こういう仕組みがあって当然だ」と思うかもしれませんが、いざ開発を担当すると、実装に集中するあまり、テストの仕組みに気づくのが遅くなることもあります。（私自身がそうでした！）
このテストカードの存在を事前に知ることで、これから決済関連の機能を担当する皆さんの心理的安全性が少しでも高まれば幸いです。