名刺アプリ「Eight」でエンジニアをしている菅間（@sugamaan）です。今回はEightで展開している中小企業向け名刺管理サービス「Eight Team」にてStripeの3Dセキュア認証（以後3DSとする）に対応した話をしようと思います。
背景
Eight Teamでは決済システムにStripeを導入しています。 Stripeでは銀行振込機能を活用したり、トライアル機能を過去に実装しています。ご興味があれば是非ご覧ください。
Stripeは2025年3月末までに3DSの導入完了を義務付けているため、Eight Teamにて対応しました。
3Dセキュア認証とは
3DSは、クレジットカード決済時に追加の認証をすることによって、不正利用から保護する仕組みです。強力な顧客認証 (SCA) などの規制要件によって要求された場合、またはカード発行会社から再試行可能な支払い拒否コードによってリクエストされた場合に、Stripeが自動的に3DS認証を開始します。
この仕組みには大きく2つのメリットがあります。まず、不正利用を効果的に防止できること。そして、「ライアビリティシフト」という保護機能です。これは、3DSで認証された決済において、クレジットカードユーザーから不審請求があった場合の返金責任が、販売者からカード会社へ移行する仕組みです。ただし、デメリットとしては、認証画面の追加によってコンバージョン率が低下する可能性があります。
システムへの導入
システム上では新規契約時と支払い方法変更時の2箇所で対応をしました。 最初にシーケンス図を使って簡単に概要を説明し、最後に実装のポイントを解説します。
新規契約時
新規契約時の大まかなシーケンス図は次の通りです。
3DSを実現するためにPayment Intents APIのフローに則ります。Stripe APIを呼び出し、client_secretを取得してクレジットカード決済フォームを表示します。この時、Eight TeamとStripeに対して契約を開始するための下準備を完了させます。
決済が成功した場合の流れは次の通りです。
決済が成功した場合、Webhookの通知を受け取り契約の有効化を行います。StripeのWebhookエンドポイントにAPI Gatewayを指定し、API GatewayからLambdaを実行します。Lambda上で処理を行った後SQSにエンキューし、Workerで契約の有効化を行います。
支払い方法変更時
支払い方法変更時の大まかなシーケンス図は次の通りです。
Payment Intents API と同様に、Setup Intents API を、クレジットカード決済フォームを表示する前に呼び出し、client_secretを取得します。
実装のポイント
Payment Intents / Setup Intents への対応において大きな変更点は、決済フォームを表示する前にAPIを呼び出して、client_secretをStripe.jsに渡して決済フォームを表示する点です。
今までは決済フォームを入力後にサービス有効化処理やStripe APIの対応などを一括で行なっていました。しかし、APIの呼び出しのタイミングが変わることによってサービスの有効化処理と決済のタイミングを分けて処理する必要があり、Race Conditionや状態を意識した実装が必要でした。
また仕組み上不要なデータが発生してしまうので、特定のサブスクリプションイベントのサブスクリプションステータスを元に解約処理の実装をしました。
おわりに
以上、Eight TeamにおけるStripeの3Dセキュア認証対応についての紹介でした。
Eightは新しい名刺文化を作るべく挑戦を続けていきます。 こうした挑戦を一緒に進めてくれる仲間を募集中です。少しでも興味があれば、ぜひカジュアルにお話ししましょう！
