Embed Size (px)
Citation preview
PAY.JP で簡単、クレカ決済！クレカ決済の仕組み・開発運用時の考慮点について
1
2017/02/14HRMOS プロダクト開発部 小山 健太 (kenta koyama)
2
自己紹介• サーバサイドエンジニアで、今は Scala で開発しています• 前職
• データ分析・管理関係のミドルウェアの構築（所謂 BI ・ ETL 等）、およびそれを使用したアプリケーション開発• 現職
• BizReach にて戦略人事クラウド HRMOS （ハーモス）の開発• 採用管理ツール• 組織管理機能（人事データベース）• 勤怠管理の決済機能
3
宣伝 (1 ページだけお付き合いくださいませ… )
• HRMOS 採用管理・勤怠管理、リリースしました！！• 評価管理等のその他サービスも順次リリース予定です。
参考：戦略人事クラウド HRMOS （ https://hrmos.co/ ）
4
Intro: 決済機能に対するイメージ• ステークホルダーからこういった要求があるのでは？？• PM 「決済機能の開発お願いします。」• 私「承知しました！」
5
Intro: 決済機能に対するイメージ• ステークホルダーからこういった要求があるのでは？？• PM「ただ本質的な機能じゃないし、工数をかけたくないですね。リリース時点ではマスト機能なんで確実に納期に間に合わせてください。」
「あと機微な情報扱うので、セキュリティは担保してください。」「金額ミスだとか、処理が動かないとかは、有りえないですね。」「あ、私さんがチームから抜けた後も、複雑なコードがレガシーにならないように気をつけてください。」• 私「しょ…承知しました。。」
6
Intro: 結局何が求められているのか？• アジャイルなプロダクト開発における決済機能への要求• 「少ない工数で、セキュアかつ堅牢なシステムを、保守性が高く作りたい」
⇒コード自体をシンプルに作れば良いのでは？？＜方針＞1. 決済代行サービスを使用し、なるべくシンプルな仕組みにする。2. 運用時の割り切りにより、不必要な仕組みを作らない。
7
Agenda• （ Common ）クレカ決済代行業者とは？？• （ Biz ）ビジネス要件としての考慮点
• クレカ決済全般に関わる話• サービス選定
• （ Dev ）決済の技術的な仕組み• PAY.JP の仕組み• 関連決済業者の影響
• （ Ops ）運用時の考慮点• （ Dev ）開発の難しいポイント
8
アンケート• どういった目的で来たか？（複数回答可）
1. 技術的仕組みへの興味2. 決済代行サービス自体への興味3. ビジネス上の方針への興味4. 将来使用する可能性があるので、事前勉強
9
Agenda• （ Common ）クレカ決済代行業者とは？？• （ Biz ）ビジネス要件としての考慮点
• クレカ決済全般に関わる話• サービス選定
• （ Dev ）決済の技術的な仕組み• PAY.JP の仕組み• 関連決済業者の影響
• （ Ops ）運用時の考慮点• （ Dev ）開発の難しいポイント
https://www.ikkatsu.jp/payment/merit/画像引用元： 10
そもそもなぜ ”代行” 業者が必要？？• 代行業者とは？？• 企業とクレカ会社の間に立ち、決済手段を提供する業者
• 代行業者がなければどうなる？？• 企業が各クレカ会社と個別契約。
• 契約管理が大変…• 技術仕様がマチマチ• 入金サイクルがバラバラ…
• セキュリティを自社で担保する必要が…• 売上管理ツールを自社開発する必要も…
11
代行業者のタイプ• 代行業者は大量にある。提供する機能の幅により、タイプ分けできる。
※「運用の幅」にのみ絞ったタイプ分けで、他にもオプション機能など細かな差異は当然あります。
⇒ 今回は、「プロダクトへの組み込み用途」のもののみに絞って解説
対象 機能の幅プロダクトへの組み込み用途
決済機能のみを提供。 API 等を経由して、決済を行う。（サービス例： PAY.JP 、 FastPay 、 WebPay ）
自社運用 カスタマイズ可能な UI 等を提供。サービス導入時にコンサルティングがついたりするものもある。
フルアウトソーシング
カスタマーサポート等の運用も含め、フルアウトソーシング。
https://pay.jp/docs/started 12
サービス内容（カード情報入力）• カード情報を入力し、 Token化（カード情報本体は PAY.JP に保存 されている）• デモ： https://pay.jp/docs/started
https://pay.jp/docs/api/?shell#支払いを作成 13
サービス内容（トークンを利用した shot 課金）
https://pay.jp/docs/api/?shell#顧客を作成 14
サービス内容（トークンからクレカ情報に変換。それを利用し、後日支払）
15
サービスイメージ（ Admin 画面）• デモ：入金管理等できます
16
サービス内容（まとめ）• PAY.JP では、ざっとこんな感じのことができます• カード情報の保存• 支払、与信枠確保、返金• 定期課金（月・年単位。トライアル期間の設定も可能）• 支払時や定期課金時に Webhook送信• クレカ 6Brand だけでなく、 Apple Pay, PAY ID （ PAYJP アカウント）決済 も対応• Admin画面による入金管理※詳細はドキュメントご参照ください。日本語でかなり丁寧に説明されてます。 （ https://pay.jp/docs/started ）
17
Agenda• （ Common ）クレカ決済代行業者とは？？• （ Biz ）ビジネス要件としての考慮点
• クレカ決済全般に関わる話• サービス選定基準
• （ Dev ）決済の技術的な仕組み• PAY.JP の仕組み• 関連決済業者の影響
• （ Ops ）運用時の考慮点• （ Dev ）開発の難しいポイント
18
クレカ決済全般における考慮点• スケジュール面：
• 審査に時間が 1ヶ月半以上かかる Brand もあるので、申請は早めに• 運用面
• 課金失敗時、誤った課金額の課金時、特殊ケースにおける返金時のフローは事前に Customer Support の方と詰めておきましょう(臨時運用時の入金手段はクレカ以外も必要ですよね。銀行振込にする？運用フローは DB論理設計にも関わるため、事前に詰めておきましょう）
• 経理面：• 入金後の情報照合どうする？？
• 法務面：• どの画面で規約を出す必要がある？？• 自社内で保持して良い情報について、開発は認識する必要あり。
http://www.jcdsc.org/pci_dss.php日本カード情報セキュリティ協議会 19
自社で保持してよい情報について• カード情報を持つ企業は以下のいずれかを満たす必要がある• グローバルセキュリティ基準である PCI DSS を取得• 各カードブランド制定のセキュリティ基準プログラムに準拠
• セキュリティの関係上、原則カード関連情報は持たない• 「カード関連情報」とは、カード番号・ CVC （セキュリティコード）・有効期限・名義名などを指す• カード情報の漏洩 三大リスクポイント1. ストレージなどに「保存」2. プログラムなどで「処理」3. ネットワーク上を「伝送」
http://www.nos.co.jp/solution/category/pcidss/1-3obey.html日本オフィス・システム株式会社 20
自社で保持してよい情報について• Web サービス事業者（下記図の”加盟店”）はクレカ情報非保持が基本
21
Agenda• （ Common ）クレカ決済代行業者とは？？• （ Biz ）ビジネス要件としての考慮点
• クレカ決済全般に関わる話• サービス選定基準
• （ Dev ）決済の技術的な仕組み• PAY.JP の仕組み• 関連決済業者の影響
• （ Ops ）運用時の考慮点• （ Dev ）開発の難しいポイント
22
サービス選定基準について•メイン• 料金（手数料率、初期費用、月額費用）• 対応カードブランド（＆対応決済手段）• 対応通貨（対応する外貨）• オプションサービス（不正検知等）• 入金サイクル• カスタマーサポート• 信頼性＆安定性• サービスの継続可能性（別の章で解説）• 開発効率・運用効率（別の章で解説）
23
Agenda• （ Common ）クレカ決済代行業者とは？？• （ Biz ）ビジネス要件としての考慮点
• クレカ決済全般に関わる話• サービス選定基準
• （ Dev ）決済の技術的な仕組み• PAY.JP の仕組み• 関連決済業者の影響
• （ Ops ）運用時の考慮点• （ Dev ）開発の難しいポイント
24
PAY.JP 自体の仕組み• 全体的な流れは以下のようになっています• フロント側の処理
• Form に入力されたクレカ情報および CVC （セキュリティコード）を検証• カード情報を PAY.JP へ送信。ワンタイム Token を取得。• ワンタイム Token をサーバ側へ送信
• サーバ側の処理• フロントからワンタイム Token を受取る。• Token を使用して PAY.JP へと決済 or カード情報保存 POST リクエストを送信。（ PAY.JP が発行した SecretKey を使用した Basic認証リクエスト）
⇒カード情報の保存や支払処理が実行される
25
PAY.JP の仕組み：前提• PAY.JP が発行した公開鍵・秘密鍵が配置されています
※注：ここで言う”公開鍵”・”秘密鍵”は、公開鍵暗号方式とは関係なく、 単に”不特定多数が見れる鍵”、”サーバが秘密に保持している鍵” という意味で使用しています。
26
Form へのクレカ情報入力時• Form バリデーション（クレカ番号も一定のルールがあるため、そのバリデーション）
①顧客がカード情報をブラウザ上で入力し、 「トークンを作成する」ボタンをクリック
27
Form 入力されたクレジットカードを送信• JavaScript入りの HTML取得し、そのまま POST リクエストでカード番号を PAY.JP へ送信させる
①apitunnel.html を取得。 JavaScript が埋め込まれており、②の処理が走る。
②クレジットカード情報を PAY.JP に送信。 HTTPS かつ、①で取得した JavaScript内で生成された認証文字列を使った Basic認証リクエスト。
28
状況確認• 今時点でこういう状態
Token クレカ情報
29
Token をサーバサイドに送信• 仕組みの詳細
①（前準備）クレカ番号・ CVC などの Form 要素を JavaScript で消す。②Token をサーバサイドに送信
Token
30
状況確認• 今時点でこういう状態
Token
クレカ情報
31
Token を使用した操作確定• PAY.JP へ操作リクエストを送信
①HTTPS かつ、秘密鍵を使用した Basic認証でToken 情報を POST 。リクエスト成功した時点で初めて、カード登録や決済処理が確定。
クレカ情報
Token
32
こんな話してましたよね• カード情報の漏洩 三大リスクポイント1. ストレージなどに「保存」2. プログラムなどで「処理」3. ネットワーク上を「伝送」
⇒ 一番最初にフロント側で PAY.JP へカード情報を「伝送」しただけ
33
関連決済業者の影響• 上流サービスの停止が、下流サービスに影響します• 決済処理のみ停止のときもあれば、全処理が停止するときもあります
決済ゲートウェイ
…
上流サービスメンテナンス時はエラーとなります。上流サービスメンテナンス時はエラーとなります。
34
Agenda• （ Common ）クレカ決済代行業者とは？？• （ Biz ）ビジネス要件としての考慮点
• クレカ決済全般に関わる話• サービス選定基準
• （ Dev ）決済の技術的な仕組み• PAY.JP の仕組み• 関連決済業者の影響
• （ Ops ）運用時の考慮点• （ Dev ）開発の難しいポイント
35
運用時の考慮点 1/ 2•メンテナンス• 上流サービスのメンテナンスもあるため、割りと唐突な訪れ方をする
• Admin画面関連• データ可視性（データが多い場合は、自社で Admin を作ったほうがいいかも）• 権限管理（ PAY.JP だと、テスト・本番環境の閲覧・更新権限が分けられない）
•環境面• PAY.JP だとテスト・本番の 2環境しかないため、
Local環境についてはどうしようか？となった
36
運用時の考慮点 2/ 2• API コール数
• PAY.JP だと無制限ではあるが、さすがに節度を持ちたいところ。⇒短時間に多量に呼び出すような処理は、呼出間隔を Config の値である程度調節できるように。• ログ出し
• エラーログを出して失敗を検知したり、レスポンスをそのまま出力 or 保存したりしないと原因調査ができないので注意。（特にクレカ登録はコンバージョン、課金はいわずもがな重要なので、失敗を絶対に検知したい）• サービスが終了した場合
• ⇒ 次ページへ
https://linecorp.com/ja/pr/news/ja/2016/1560 37
サービスが終了することもあります• 全てのものに等しく訪れる終わり……
http://blog.pay.jp/entry/2016/10/31/235144 38
他サービスへの移行は可能•移行をサポートしてくれるところは多いようです
39
移行の際の注意点• API が似たようなものであり、データの保存形式も似ていれば基本的にはデータも移行可能• もちろん、互換性がない一部データは失われるようです
•移行作業自体は、廃止されるサービスへ新規にデータが追加されないようにしてから、行う必要があります• アプリケーションは以下の処理を行える必要があります
• 廃止されるサービスのデータを参照する処理• 新規契約したサービスのデータを参照・更新する処理
•但し審査等は、新サービスのほうで再実行する必要あり
40
Agenda• （ Common ）クレカ決済代行業者とは？？• （ Biz ）ビジネス要件としての考慮点
• クレカ決済全般に関わる話• サービス選定基準
• （ Dev ）決済の技術的な仕組み• PAY.JP の仕組み• 関連決済業者の影響
• （ Ops ）運用時の考慮点• （ Dev ）開発の難しいポイント
41
開発の難しいポイント• シンプルなサービスであっても「 HTTP経由での外部サービス利用」自体に起因する問題点は消えない1. トランザクションの一貫性が取れないため、処理失敗のタイミングによってはデータ不整合が発生2. 処理に失敗したように見えて、実は成功しているケースがある
3. HTTP経由なので、どうしても処理が同期的になり、遅くなりがち
※Best Practice じゃないかもしれませんが個人的に感じた問題と対策を記載します
42
問題①：データ不整合の発生• API からのレスポンスを、 DB に保存する処理は不整合の可能性あり
※ PAY.JP 自体も DB と捉えると、 PAY.JP ・自社 DB の 2箇所に重複データを保存 しているともいえる
【 API へ POST リクエスト】 PAY.JP へカード登録
【 DB へカード情報登録】PAY.JP のカード ID を保存
PAY.JP にのみデータが保存されDB にはデータが無いことになる。
43
対策：データ不整合の発生• 不整合が発生しないようにする対策案
1. HTTP経由でロールバック• 例えば「顧客作成」 API が成功している場合は、「顧客削除」 API を叩く
2. DB の状態を細かく同期• 通常は「顧客作成 API を叩く」⇒「 API の結果を DB に顧客データとして保存」だが、「 DB の顧客データのステータスを”登録中”にする」⇒ 「顧客作成 API を叩く」⇒「 API の結果を DB に顧客データとして更新。ステータスを”登録済み”にする」というフローにすれば、異常が起こったこと自体はわかる
3. 不整合発生時に検知さえできれば、運用でカバー！と割り切る• こういった不整合が起きる可能性が低いのであれば、そういった割り切りは有効か。
44
対策：データ不整合の発生•検知• データ不整合が発生した可能性がある場合は必ず検知したいのでエラーログを出す
• その他処理• 原則 DB のデータを正として、処理を行う。
DB は PAY.JP への参照（ PAY.JP顧客 ID 等）を持つため、これを使用して処理を行うようにする。
45
問題②：処理が成功したか不明なケース• リクエストタイムアウト等、「リクエストを送信したが、レスポンスが返って来ていないケース」では処理が成功している可能性があり得る
Application PAY.JP
処理確定
①②
③
④
46
対策：処理が成功したか不明なケース• リクエストタイムアウトの設定時間は比較的長めに• リクエストタイムアウトになった場合は、エラーログを出す等して検出できるように
⇒検出後、処理に成功していた場合はデータ不整合が発生しているため、対応する。• サーバ停止させる際には、タイミングに注意
47
問題③： HTTP を使用するため処理が同期的になりがち• HTTP リクエストの結果を待って、、、⇒ その結果を使って、また HTTP リクエストを送って、、、となり遅くなりがち。（特に、用途にマッチする API が無いと、何回か API を叩かなければいけないはめになる）
48
対策： HTTP を使用するため処理が同期的になりがち•頑張ってください。
![EC決済ソリューション （メール告知） e-shopsカートSでのご利 …cart.e-shops.jp/guide2/help/ec_m.pdf · [EC決済ソリューション メール告知決済]](https://img.pdfslide.tips/doc/110x75/5f395d19f9647c4e5b04cbde/ecfffff-ifffci-e-shopsffs.jpg)
