会場
株式会社ビズリーチ
東京都渋谷区渋谷2-15-1 渋谷クロスタワー 12F
全体の感想など
最近、決済関連の勉強会が頻繁に開催されているような気がするのですが、今回は、WebPay サービス終了にあたって公式移行サービスを発表したことで最近話題になった「PAY.JP」の勉強会です。
勉強会の会場はビズリーチ。オフィスにビーチやらグリーンがあるというのを耳にしたことがあったので、まずはそっちに興味津々。
行ってみると、ありましたー！！
（グリーンの逆側しか撮ってなかったのですが雰囲気は伝わるかと。。）
気になる方は、こちらの記事をどうぞ。
hrnabi.com
それはさておき、今回の勉強会では実際に「PAY.JP」を使ってサービスを開発・運営した開発者の意見が聞けたのはすごくよかったです。選定の経緯としては、昨年中に PAY.JP のほか「Yahoo!ウォレット FastPay」「WebPay」「Cybersource」（仕組みが違いすぎて却下）を比較検討して、開発しやすそうということで採用に至ったとのこと。その時点ではまだ「Stripe」は本番利用できていなかったとは思うのですが、「PayPal」や「LINE Pay」なども検討に入れたのかどうかなども聞いてみたかったところです。
しかしながら結局、PAY.JP は越境EC には対応していないらしいので（要確認）、私のニーズに合うのは Stripe か PayPal のどちらかかなぁと思いました。
簡単、クレカ決済！ PAY.JPを使ったクレカ決済の仕組み・開発運用時の考慮点について
小山健太
- 求められるもの
- 工数掛けたくない
- セキュリティは担保したい
- 堅牢性
- 保守性
- コード自体をシンプルにしよう
- PAY.JP の仕組み
- カード情報をトークン化
- できること
- クレカ情報の保存（暗号化した状態）
- 支払い、与信枠確保、返金
- 定期課金（月・年単位、トライアル期間）
- 支払い時や定期課金時にWebhook送信
- ドキュメントが日本語
- カード情報を持つ企業は以下のいずれかが必要
- グローバルセキュリティ基準の「PCI DSS」を取得
- 書くカードブランド制定のセキュリティ基準プログラムに準拠
- サービス選定基準
- 料金
- 対応カードブランド
- 対応通過
- 不正検知オプションサービス
- 入金サイクル
- サービスの継続性
- 開発効率・運用性
- 運用時は、エラーログやレスポンスを保存しておくべし！
- 開発時の難しかったポイント
- 問題①：API越しのデータとの不整合
- そもそも重複データを持たせないようにする
- データ不整合が発生した場合はエラーを出して検知し、運用でカバー！？
- データ不整合が発生した場合は、API経由でPAY.JP側もロールバックしちゃう？！
- 問題②：外部サービスへのリクエストがタイムアウトしたら？
- リクエストタイムアウトの設定時間を長めに
- エラーログを出して検出
- 問題③：HTTPリクエストの結果を待って次のリクエストを・・と処理が同期的になりがち
- 問題①：API越しのデータとの不整合
- その他
- 電子マネーはサポートしてないが、Apple Pay、PAY.JP アカウントのみ対応
- ログは fluentd で ElasticSearch に保存して、エラーログだけ Slack に通知
- テスト環境と本番環境の二環境しかない、Admin画面がしょぼいのはデメリット
