EC/CRMに特化したプラットフォーム「prismatix」
私はprismatixというEC/CRMに特化したプラットフォームを作っていまして、そちらの注文/決済サービスを担当しております。 classmethod株式会社がBtoBの自社サービスとして提供している、EC/CRMに特化したプラットフォームです。
お客様との良質な関係の場を構築するところをエンゲージメントコマースと呼んでいまして、お客様と共に考える、伴奏型コンサルティングといった、コンサルティングサービスも提供しています。
prismatixは、注文・決済サービス、商品サービス、会員・認証サービス、といった形でマイクロサービスとして提供しています。
全体で700以上のAPIが用意されていて、prismatixを利用されているお客様は、それを使って独自のECサイトの構築が可能です。
各企業の業務に適した設計や最適化ができるように作っておりまして、会員・認証サービスとある通り、CRM基盤としても活用いただいてます。
また、Stripe、VeriTrans、AmazonPay、NP後払いといった色々な外部決済サービスに対応しておりまして、 prismatixはそれらを統合した決済インターフェイスとしても提供しています。
ここまで私が携わっているprismatixの紹介をしましたが、ここからが本題です。
私からは、ECサイト向け決済機能の開発において、クレジットカード情報の扱い、外部サービスとの通信がタイムアウトする際の考慮ポイント、外部決済サービスのテストリリースフローの3点を紹介します。
サーバーサイドにクレジットカード情報を持たせない
ECサイトの利用者がクレジットカード情報を入力すると、ECサイトの画面から外部決済サービスに直接カード情報を送信します。
外部決済サービスから利用者のクレジットカード情報を基に返したトークンで、サーバーサイドから外部決済サービスに向けて、 カードを事前に登録するといった流れです。事前に登録したカード情報を使って実際に注文確定して、外部サービスに与信を取ることを想定しています。
ここでポイントになるのが、カード番号などの利用者情報は、利用者が使う画面と外部サービス間の通信のみでやり取りを行います。
クレジットカード情報はサーバーサイドに置いたり、サーバーサイドでリクエストが届くことによって情報漏洩などのセキュリティリスクが高くなるので、サーバーサイドに持たない・通さないことが重要なポイントです。
あと利用する外部決済サービスを採用する際は、PCIDSS(クレジットカードのセキュリティ基準)に遵守したサービスであること、かつカード情報の非通過・非保持を実現できる機能を持つこともポイントです。
外部決済サービスとの通信がタイムアウトする際に考慮すべきこと
外部サービスを使っていると、レスポンスに結構時間がかかるケースがあります。外部サービス側の障害などもありますが、 特に決済に関わる部分ではカードの与信や売上金の返金の場合は時間が数秒で、場合によっては、数十秒かかるケースも少なくないです。
ECサイトが使っているAPIクライアント側で設定した許容時間を超えて、通信がタイムアウトするケースも発生する可能性があります。
たとえば、利用者が注文登録をECサイトにリクエストして、ECサイトは外部決済サービスに対して与信の取引登録を行うリクエストをしますが、外部決済サービス側の処理に時間がかかった場合、ECサイト側がタイムアウトと判定します。
ECサイトはこの時点でエラーとみなして、利用者には、「注文登録できませんでした」とレスポンスを返しますが、 外部決済サービス側の処理は実は継続していて、取引が成立したというケースが想定されます。
ただ、取引が成立したというレスポンスはECサイト側には届かなくて、 ECサイト側はそれに気づかず、注文成立しないままといった状態が想定されます。
注文成立していないのに、外部サービス側の与信は成立しているという不整合な状態となってしまいます。利用者から見ると買い物ができてないのになぜかカードの与信枠は減っているので、利用者にも良くない見え方をしてしまいます。
こういったタイムアウトによる失敗に備えた対応として、突合・補填を追加しました。
突合は、ECサイトと外部決済サービス間の状態を比較して、 どちらも成功または失敗という状態になっているかという確認をします。
もし突合によって不整合と判断された場合は、状態を合わせる補填という対応を行います。この例では、ECサイト側では注文不成立で、外部決済サービス側が成立していた場合は取引をキャンセルします。
突合と補填の対応を備えておくことで、万が一タイムアウトの事象が発生した場合も、利用者に対する不要な請求をしないシステムにしました。
このようにECサイトと外部サービス間の整合性を担保することをおすすめします。
外部決済サービスを扱う上でのテストリリースフロー
ECサイトの決済機能を新しく追加したテストをして、テストが通ったらECサイトのアプリケーションをビルドしてリリースまでするといったことで、新しい機能を提供するまでのCICDフローの例をここでは表しています。
このテストを実施した時、外部決済サービス側や開発環境に何らか不具合があるとテストが異常終了するケースがあります。
そうすると、テストに依存してビルド・リリースのフローを組んでしまうと、ビルドから先に進まずにリリースができないという事象が発生します。新しい機能を早く提供したいのに、外部サービスが復旧するまで待つという状態が最悪想定されます。
問題ではない、と明確にした上でOKであれば、リリースを進める形でリリースフローの改善を考えました。
ここで私が考えたのがリリースフローの改善で、外部決済サービスに依存するテストはビルドとは別のプロセスで実施する形で考えました。
外部決済サービスに依存する処理は、モック等で代用してテストを実施します。
万が一、外部サービスに依存するテストが失敗した場合でも、外部決済サービスが一時的な不調、あるいは決済サービスに依存しないテストが通っていてプロダクトの問題ではないことを明確にしたうえでリリースまで進めることができます。
そのため、CI/CDフローを考慮しつつ外部決済サービスに依存したテストをしたい場合は、ビルドやリリースに依存しない作りにした方が良いと思います。
プロダクトを直す必要がないと明確に判断できて、リリースOKとする仕組みを用意することがポイントです。
以上、簡単に3つのポイントについて説明をさせていただきました。
カード情報はサーバーに持たない、通さない。 外部サービスは何かしら異常が起きるという前提のもと設計やテストをすることが非常に重要なポイントです。
