Experience Cloud / Commerce Cloudでのクレカ決済実装

Contents

1 前提
2 クレカ決済実装にあたって知っておくべきこと
3 実装方法の分類
4 どの実装方法を用いるべきか（Experience Cloudの場合）
5 B2B/B2B2C/SOMのOOTBクレカ決済機能
6 参考：トークン化とオーソライズのフロー（B2B/B2B2C）
7 どの実装方法を用いるべきか（B2B/B2B2C/SOMの場合）
8 OOTB準拠での具体的な実装方法（B2B/B2B2C/SOM）

前提

本記事が念頭に置く製品
- Experience Cloud
- B2B Commerce Cloud on Lightning Experience
- B2B2C Commerce Cloud
- Salesforce Order Management
本記事が念頭に置かない製品
- B2B Commerce Cloud on Visualforce（旧：CloudCraze）
- B2C Commerce Cloud（旧：Demandware）
- Salesforce Billing

クレカ決済実装にあたって知っておくべきこと

クレジットカード情報は最上級の個人情報であるため、一般的なデータと同じように扱うこと（データを暗号化せずに保存したり、データを暗号化せずに通信することなど）は許されない。

クレカ決済は2018年6月1日の「改正割賦販売法」施行により、現在以下の二つのいずれかの要件を満たしている必要がある。

PCI DSS準拠
カード番号の非保持化

実装方法の分類

クレカ決済の実装は、その実装方法や認証方法によって以下のように分類可能である。

On Site Checkout：サイト上でクレカ情報入力＆決済
- 通常認証：クレカ情報をベースとした認証
  - 非トークン決済：トークン化されたクレカ情報を用いない決済
    → 原則NG
  - トークン決済：トークン化されたクレカ情報を用いる決済
    - 通過型：サーバーサイドを通過してトークン化
    - 非通過型：サーバーサイドを一度も通過せずにトークン化
- 3Dセキュア1.0認証：通常決済よりもセキュアな認証
  → 廃止済（2022年10月）
- 3Dセキュア2.0認証：通常決済よりもセキュアな認証
Hosted Checkout：決済業者が提供する決済ページでクレカ情報入力＆決済

どの実装方法を用いるべきか（Experience Cloudの場合）

On Site Checkout（サイト上でカード決済を行う実装）とHosted Checkout（決済事業者が提供するページに一度遷移して、そこでカード決済を行う実装）を比較した場合、特段の事情がなければ、Hosted Checkoutでの実装を行うことが望ましい。

というのも、on Site Checkoutを選択した場合、（とりわけ3Dセキュア2.0認証を用いた実装においては）フロントエンドとバックエンドの双方に渡ってクレカ決済に求められる強固なセキュリティ基準を満たした開発を行う必要があり、大抵の場合、これは大規模かつ長期間に渡ることとなるからである。

また、保守性・拡張性という観点で見た場合においても、on Site Checkoutでは3Dセキュア2.0に続く認証方法への対応やクレジットカード以外の決済方法への対応を全て自社開発する必要があるのに対して、Hosted Checkoutではそれらを完全なゼロコストで賄うことが可能である。

従って、少なくともコスト・リスク・保守性・拡張性の点において、Hosted CheckoutはOn Site Checkoutに対して優位性を持つ。

Salesforceの製品に関して言えば、Experience Cloudではクレカ決済のためのOOTB機能が提供されていないため、①AppExchangeを用いるか②（自前で実装する場合は）Hosted Checkoutが推奨ソリューションとなる。

◾️AppExchange

グローバルデファクトスタンダードなAppExchangeとして、以下が挙げられる。

ただし、上記は両方とも①価格が高い②国内決済代行業者に対応していないという問題を持つため、国内PSP（＝国内決済代行業社）にこだわる場合は以下のAppExchangeが検討候補に挙がる。

◾️カスタム開発

自前実装の具体的な実装方法については、Hiroki Tanaka氏による「Salesforce の Experience Cloud で Stripe による決済」の記事が参考になる。

B2B/B2B2C/SOMのOOTBクレカ決済機能

B2B Commerce Cloud・B2B2C Commerce Cloudでは、クレジットカード決済のためのLWCとPayment Adapter FrameworkがOOTBで提供されている。

この標準機能はごくシンプルな作りとなっており、サイト内のモジュール（＝クレカ決済用LWC）に入力されたカード情報をサーバーサイド（＝Apex Class）に送信し、そこからPayment GatewayのTokenize用APIをcallするような仕組みになっている。

そのため、PCI DSSにこそ準拠しているものの、以下のような課題を抱えてしまっている。

カード番号完全非保持に対応していない
3Dセキュア2.0に対応していない

上記Salesforce OOTBに準拠してクレジットカード決済を実装する場合、（標準のクレカ決済用LWCのクライアントサイドコントローラーはカスタマイズできないため）当記事での分類に従えば「On Site Checkout・通常認証・トークン決済・通過型」による実装となる。

参考：トークン化とオーソライズのフロー（B2B/B2B2C）

参考リンク：Payment Architecture

どの実装方法を用いるべきか（B2B/B2B2C/SOMの場合）

OOTBクレカ決済機能の問題点を踏まえた上で、実際にどの実装方法を選択すればよいのか。

結論、以下のような仕方で決定するのがよいと思う。

順番に補足していく。

まず、3Dセキュア2.0での認証が要件上必須の場合、OOTBは対応しておらず、またゼロベースでのカスタム開発も現実的ではないため、①AppExchange②Hosted Checkoutのいずれかでの実装が望ましい。

3Dセキュア2.0認証でなくともよいが、カード番号完全非保持である必要がある場合（つまり、いわゆる非通過型決済を維持したい場合）、OOTB機能はクレカ情報をSalesforceサーバーサイドに送信するため（＝必然的に通過型決済となるため）利用できない。この場合、クライアントコントローラ側で（＝ブラウザのJavaScriptで）PaymentGateway業者のトークン化エンドポイントをコールする仕組みにすることでカード番号非通過を担保してあげる必要があり、つまるところクレカ決済用のLightning Web Componentを自作するような実装となる。

最後に、SalesforceのOOTBに準拠して開発を進める場合は、AdapterのTokenizeメソッド内でPaymentGateway業者側のTokenize用エンドポイントをコールする実装となる。

この部分に関してSummer23までは（ChargentのAppExchangeを利用しない限り）Apapter Classの自社開発が必須だったが、Summer’23にSalesforce Paymentが登場したことで海外PSP（Stripeなど）についてはNo Codeでの対応が可能となった。