ECフルスクラッチの決済システムについて

TENTIAL x tricot D2Cエンジニアが語るECのフルスクラッチ事情の登壇資料です

https://tricot.connpass.com/event/221261/

TENTIALで開発しているフルスクラッチECの
技術構成、決済環境、定期決済をフルスクラッチでつくる際の設計方法や実装ポイントをまとめています。

Transcript

1. ECフルスクラッチの決済システムについて ＠_wakkn
2. 自己紹介 湧川仁貴 経歴 - 中3からプログラミング触り始める- C言語猫本から開始 - 23歳 - 沖縄高専出身。在学中からWeb開発受託をしてNodejs触り始める - Mixi/Fullerインターンを経て、新卒でユーザーローカルに入社 - その後TENTIAL ECリニューアルをするために入社 - TENTIAL - ウェルネス事業テックリード Node.js/ express.js / vue / react / MongoDB
3. TENTIALの事業
4. TENTIAL<ウェルネスブランド> ウェルネスブランドTENTIALの運営 インソール、マスク、スリープウェア BAKUNE 入浴剤TAKIA、朝専用MOVONなどを提供
5. ▼技術スペック ・Nuxt.js (Vue.js + express.js + MongoDB) ・AWS(Fargate, S3, codepipeline) ・github actions ・heroku（review apps） ・imgix（画像圧縮CDN） ・Benchmark Email（メルマガ配信） ・LOGILESS（物流管理システム） ・GMO Payment（決済） ・Hevo Data（DB ETL） ・BigQuery（データ分析） ・Autify（ソフトウェアテスト） TENTIAL EC フルスクラッチ
6. ▼技術スペック ・Nuxt.js (Vue.js + express.js + MongoDB) ・AWS(Fargate, S3, codepipeline) ・github actions ・heroku（review apps） ・imgix（画像圧縮CDN） ・Benchmark Email（メルマガ配信） ・LOGILESS（物流管理システム） ・GMO Payment（決済） ・Hevo Data（DB ETL） ・BigQuery（データ分析） ・Autify（ソフトウェアテスト） TENTIAL EC フルスクラッチ
7. 決済システムについて GMO Payment Gatewayを全面的に使用 - クレジットカード決済と決済フローについて - AmazonPay - 後払い GMO Payment Gatewayとは - GMO Paymentが用意した決済をAPI経由でリクエスト できる決済代行サービス
8. GMO Paymentのメリット/デメリット 豊富な決済手段 - クレジットカード、AmazonPay、後払い、コンビニ、 ApplePay、PayPay UIがこだわれる 運営元が東証一部上場 サポート体制がしっかりしている 色んなASP(EC-Force)に対応しているので、決済の引き継ぎが比較的 容易 メリット デメリット 安くない決済手数料 ベンダーロックイン APIを使用するので、自前で実装する部分が増える → メンテコスト増大 ドキュメントがわかりづらいかも？ EC-Forceを使用していた事でそこから の引き継ぎと、豊富な決済手段から GMOを扱うことを決定した。
9. 購入ボタン押下した後の実装フロー 1. Transaction session貼る 2. parameterの確認・バリデーション 3. 商品の在庫チェック、不正価格検知 4. ログインステータス確認 5. 配送梱包データ確認 6. Order仮作成 7. クーポン情報確認 8. （定期商品であれば定期モデル作成） 9. GMO決済APIリクエスト（execTransaction） 10. Transaction確定処理 or Failure処理 11. メール送信
10. MongoDB/Node.jsで決済処理 MongoDBで複数コレクションを更新する上で気をつけないといけないこと
11. MongoDB/Node.jsで決済処理 MongoDBで複数コレクションを更新する上で気をつけないといけないこと NoSQLはトランザクションがない！！！ （RDBではトランザクション完備）
12. MongoDB/Node.jsで決済処理 MongoDBで複数コレクションを更新する上で気をつけないといけないこと NoSQLはトランザクションがない！！！ （RDBではトランザクション完備） 不都合なデータが生まれる（整合性の欠如） Order CouponHistory User 更新 CouponHistory部分のみエラーが起きた。
13. MongoDB/Node.jsで決済処理 MongoDBで複数コレクションを更新する上で気をつけないといけないこと NoSQLはトランザクションがない！！！ （RDBではトランザクション完備） 不都合なデータが生まれる（整合性の欠如） Order CouponHistory User 更新 CouponHistory部分のみエラーが起きた。 Order CouponHistory User Order,Userのみ更新。 CouponHistoryのみ古いデータ。
14. MongoDB/Node.jsで決済処理 トランザクションとは - トランザクションとは、一連の流れを確実に保証するための期間 - ACID
15. MongoDB/Node.jsで決済処理 トランザクションとは - トランザクションとは、一連の流れを確実に保証するための期間 - ACID 独立性(Isolation) 整合性(Consistency) 不可分性(Atomicity) 永続性(Durability)
16. MongoDB/Node.jsで決済処理 トランザクションとは - トランザクションとは、一連の流れを確実に保証するための期間 - ACID 独立性(Isolation) 整合性(Consistency) 不可分性(Atomicity) 永続性(Durability)
17. MongoDB/Node.jsで決済処理 • Sessionを貼る • Transaction作成 • 成功すればcommit • 失敗すればabort
18. MongoDB/Node.jsで決済処理 • Sessionを貼る • Transaction作成 • 成功すればcommit • 失敗すればabort
19. GMO Payment API APIを用いて決済をリクエストする entryTransaction (注文登録: 注文の登録を行う) execTransaction (ユーザーの与信枠を確保する) alterTransaction (与信枠を確定し売上にする)
20. GMO Payment API APIを用いて決済をリクエストする entryTransaction (注文登録: 注文の登録を行う) execTransaction (ユーザーの与信枠を確保する) alterTransaction (与信枠を確定し売上にする) 仮売上 実売上
21. 売上確定までの流れ GMO Payment Gatewayだけでなく、他の決済代行会社はほとんどこの形式
22. 売上確定までの流れ GMO Payment Gatewayだけでなく、他の決済代行会社はほとんどこの形式
23. 決済フローを実現する上での懸念 仮売上ができてユーザー視点では変えたものの、実売上が出来てない 仮売上状態が30日過ぎると、決済が無効になる ユーザーは決済出来たと思っているのに、注文が 無効になってしまう、、
24. 決済フローを実現する上での懸念 仮売上ができてユーザー視点では変えたものの、実売上が出来てない 仮売上状態が30日過ぎると、決済が無効になる ユーザーは決済出来たと思っているのに、注文が 無効になってしまう、、 実売上を絶対に成功させなければいけない！！！
25. 対策: GMO Payment売上確定バッチ 注文毎にステータス確認APIを用いて、正データをリアルタイムに確認
26. 対策: GMO Paymentオペレーター機能 オペレーター側でステータスの変更、仮売上の決済を実売 上にできる オペレーター売上確定 GMO管理画面と連携 注文一覧 > 注文詳細ページから、GMO管理画面の該 当する注文ID詳細ページに即座に遷移。
27. AmazonPay • CVRが格段に上がった。比率なら 50％以上 はAmazonPayで決済をしている状況 • ver1とver2がある • ver1はブラウザの3rd party cookie削除で、 住所・決済カード選択 widgetがうまく表示され ない • 急速にver2への移行が進んでいる ◦ ver2移行で、事業者に沿った UIの構築 ができる
28. AmazonPay • CVRが格段に上がった。比率なら 50％以上 はAmazonPayで決済をしている状況 • ver1とver2がある • ver1はブラウザの3rd party cookie削除で、 住所・決済カード選択 widgetがうまく表示され ない • 急速にver2への移行が進んでいる ◦ ver2移行で、事業者に沿った UIの構築 ができる ver1の方はお早めにver2への移行を！
29. 後払い決済 • 日本でいうと後払い決済や代引きの率が高 いので決して無視できない決済手段 • 請求書を送るかの同梱と別送がある • 決済フローは若干ことなり、扱う APIも異なる
30. 後払い決済 １．取引登録 注文情報を後払いシステムに登録します。 ２．与信審査 ご登録いただいた情報にて与信審査をいたします。与信審査 の結果がOKとなった取引は商品出荷可能です。 ３．出荷報告 商品発送後に運送会社と配送伝票番号を入力し、出荷し たことをGMOに伝えます。 ４．請求書発行 出荷報告後の翌営業日に GMO側からお客様に請 求書の発行が行われます。
31. 定期決済 0. 仕様 1. どのようなフローで作ったか 2. 定期を実装する上での実装ポイント 3. 大変だったこと 4. 設計・運用でやってよかった点
32. 定期決済 - 仕様 - 自動決済 - オペレーター決済 - カート確認 - 定期オプション変更 - 購入確認画面 - 定期情報表示 - 定期購入時に割引オファーを設定 - URLごとに割引オファー設定 - 定期プラン追加/編集 - 定期失敗ユーザー通知 - マイページ/管理画面変更 - カード変更 - スキップ・スキップ解除 - ストップ機能 - お届け先変更 - お届け個数変更 - 配送頻度変更 自動決済 マイページ定期変更 管理画面 ユーザーカート
33. どのようにして作ったか １．コア機能（自動決済）のプロトタイプ https://www.gmo-pg.com/service/subscriptions/ GMO継続課金：
34. どのようにして作ったか • GMO Payment Gatewayには継続課金といった機能はない １．コア機能（自動決済）のプロトタイプ https://www.gmo-pg.com/service/subscriptions/ GMO継続課金：
35. どのようにして作ったか • GMO Payment Gatewayには継続課金といった機能はない • 一方で、クレジットカートを登録することで、事業者側任意のタ イミングで決済をすることが可能 １．コア機能（自動決済）のプロトタイプ https://www.gmo-pg.com/service/subscriptions/ GMO継続課金：
36. どのようにして作ったか • GMO Payment Gatewayには継続課金といった機能はない • 一方で、クレジットカートを登録することで、事業者側任意のタ イミングで決済をすることが可能 • 本来execTransactionではクレジットカードのトークンをフロント 側で取得し、それを使用してリクエストを行うが、クレカ登録を すれば常に決済が可能 １．コア機能（自動決済）のプロトタイプ entryTransaction execTransaction Subscription 初回決済で作成した Subscription からUser情報を取得する https://www.gmo-pg.com/service/subscriptions/ GMO継続課金：
37. どのようにして作ったか • 仮の仕様書やテーブル設計図つくる ◦ フロント/バックエンド仕様（外部内部） • CTOやバックエンドや設計に詳しいエンジニアとあ ら探し • これってどうなの？みたいなのを議論（これってだ めですよね？？みたいな押し問答を 1日してた日も あった） ２．ひたすら議論する
38. どのようにして作ったか • 以下4つにわけてそれぞれ開発 ◦ 管理画面（CRUD、エラーが出た場合の対 応） ◦ ユーザー管理画面（一覧確認、 Stop、Skip、 Interval変更） ◦ ユーザーカート側（初回決済） ◦ 自動決済 • ジュニアのメンバーも積極的に議論に参加し、みん なの定期決済Contextを高める →のちのQAをやりやすいようにする ３．実装
39. どのようにして作ったか • 2週スプリントに2回QA→4回QA (1回QA2h~2.5h) • リリース時には5回QA/1week • テスト仕様書をなぞる + モンキーパッチも ４．ひたすらQA
40. どのようにして作ったか ５．スケジュールも予め立てるが都度チューニングして全部署と共通認識を持つ
41. 定期を実装する上での実装ポイント • サービスによってまちまちだが、 TENTIALではPlanと SubscribtionをOne to Oneにした。 • 例えばPlanを変更する（1ヶ月→2ヶ月）場合は、 Subscriptionに紐づくPlanを変更するだけで済むよう にした • 一方でSubscriptionにpersonal_planを追加し、特定 のユーザーのみオファーだけ変更したいといった要望 に対応 １．Sku（Product）とPlanとSubscribtionとOrderの関係 Plan Order Subscription Customer (User) One to Many One to One One to One
42. 定期を実装する上での実装ポイント 次の決済が走るタイミングがいつかによってとるべきサイクルが変わってくる a. はじめて決済した日が、次回の決済日基準日 i. どのユーザーも一律同じスパンでサービス提供ができる b. 決済した日関係なく、固定日に発送する i. 決済した日関係なく、固定日に発送する ii. ユーザーによって、初日に買う人と月末に買う人で 2回目のサービス提 供日までの時間が変わってくる ２．決済タイミング
43. 設計・運用でのbetter point(これやってよかった) - 今後の定期システムに変更があった時のことも 考えて、色んな角度からこれってどうなの？をひ たすら壁打ちした - 決済サービスであるがゆえ、一度の失敗が大き い - マイクロMTG+ペアプロで仕様のさらなる理解 と、実装との乖離を解消 １．ひたすら壁打ちする - 既存のコードがJSなため、テスト環境があまり 整っていなかった。 - 自動テスト以外の品質担保方法として、 QA時間 を多くとり、最低限の品質を担保した - エンジニア自身のQA力向上 ２．QA会
44. 設計・運用でのbetter point(これやってよかった) - 自動決済がされない - 指定時間を超えてもバッチが実行されない。 GMO決済リクエストが落ちるなどの予期せぬこと で自動決済が落ちることはある。 → 条件満たせばオペレーターが任意で決済を実行できるよ うにする（オペレーター決済） - 自動決済が勝手に実行される - 自動決済が落ちるのは構わない - N回目のサービスが提供されていないのに、 N+1回目の決済がされないようにした（ここでいう サービス提供は、TENTIALの場合、商品の発送） - 金額、データがあっていない - 初回オファーや3回目まで1000円引きなどの特定割引があれば、その分金額があわないみた いなことは起こりがち - SaaSとのデータ整合があっていないのも頻繁に起こる - QAで徹底的にでないようにする - ３．最悪の展開を避けるためのエラー対策を最初から実装 →モニタリング
45. ご静聴ありがとうございました！