Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
最近やった
決済システムの実装の話
タケユー・ウェブ 竹内雄一 @takeyuweb
タケユー・ウェブ
竹内雄一
• さいたま市大宮周辺
• フリーランス8年目
• 基本ひとりで設計/実装/運用
• 高専クラスタ
• 昔rack-ketaiってgemを作った
ぐらい出典:ウィキメディア・コモンズ (Wikimedia Commo...
事例
• 様々な支払い方法
• 様々な決済タイミング
• 様々な商材
• アフィリエイト対応
事例 様々な支払い方法
• 利用者が決済方法を選択できるようにして欲しい。
• 銀行振込
• クレジットカード
• 前回のクレジットカード(クイック決済)
• Edy
• 楽天ID決済
• PayPal Express Checkout
• 特...
事例 様々な決済タイミング
• 基本は毎回決済手続き
• 都度決済
• 会員プラン契約の支払いについては、次回以降は自動継続出来
るようにして欲しい。
• 自動定期決済
• また、初回はクレジットカード認証(オーソリ)だけで、無料
期間後自動課...
事例 様々な商材
• プラン契約
• 課金後一定期間有効
• 上位プランへのアップグレードは差額支払い+延長
• 下位プランへのダウングレードは即時
• サービス内通貨(コイン)パック
• 購入後会員所有のパック規定のコインを加算
• 一定期間...
事例 アフィリエイト対応
• アフィリエイトリンクから獲得した会員の決済などのタイミン
グで成果を発生
• 自前のアフィリエイトシステム
• 外部のアフィリエイトASP
• チャージバック(決済取消)
• チャージバックが発生したら、自前のアフ...
結構大変
• 様々な支払い方法
• 支払い方法ごとにフローが異なる
• 様々な決済タイミング
• 手動
• 商材ごとに別のUIから発生
• 自動
• 定期処理
• 様々な商材
• 商材ごとに決済後の処理が異なる
• アフィリエイト対応
• 支払...
決済フレームワーク作っとくか
• 抽象化し、再利用可能なコードの共通化
• 簡単なルールで決済方法、商材の追加に対応
• 支払い方法は商材がどれかを知らなくて良いし、商材は決済方
法を知らなくても良い
• 呼び出し場所問わず、決済フローの開始・...
決済フレームワークを考える
(決済フロー)
• 共通の決済フロー括りだし
• 請求伝票発行
• 支払い完了
• ペンディング
• 差し戻し
• 支払い方法変更
• キャンセル
• 期限切れ失効 etc…
決済フレームワークを考える
(支払い方法)
• 共通インタフェースの括りだし
• 属性
• 名称
• 説明
• HTML(外部決済サービスへの接続など) etc…
• 利用可能チェック
• 決済フローの各イベント前後で必要な処理
• コールバッ...
決済フレームワークを考える
(商材)
• 共通インタフェースの括りだし
• 属性
• 商品名(見出し)
• 価格 など
• 購入可能チェック
• 決済フローの各イベント前後で必要な処理
• コールバック
• before_open(billin...
決済フレームワークを実装する
• ドメインサービス的なもの? ※DDDよくわかってない
• 支払い方法オブジェクトと、商材インスタンスオブジェクトを
受け取って伝票を発行
• 行いたいフロー上のイベントを伝票を渡すとよしなに
• 利用者による操...
支払い方法を実装する
• 「支払い方法」抽象クラスを作成
• 継承によって各支払い方法ごとに
必要なコールバックやビューを追
加
• 例)クレジットカード決済
• 決済代行会社へのリンク
• 決済代行会社からのコールバックのハ
ンドリング
• ...
商材を実装する
• 「商材」モジュールを作成する
• 各商材クラスにmix-inして必要な処理
を実装
• 例)契約の更新処理、差額を反映した
金額の計算、コインの加算処理 etc…
• ダックタイピング
• バリデーションしたいなら
item...
アフィリエイトへの対応
• モジュールに分離
• アフィリエイトに対応させる支払い方法、商材にmix-inして必要に応じ
て実装
• 成果発生条件
• 成果率
• 決済取消時に成果を取り消す etc…
• 外部アフィリエイトASP
• 支払い結...
定期自動決済の実装
• そこまでタイミングの要求が厳しくなかった(契約期限切れ後
猶予期間設定あり)
• CRON(whenever)
• 決済フレームワークを使って、「クイック決済」の伝票を発行、自動
決済ジョブを発行。
• 自動決済ジョブ(...
定期自動決済とOpsWorks
• OpsWorks
• 負荷や時間に応じてインスタンスを増減
• CRONの問題
• 同じCRONタスクが複数のサーバで実行されてしまう
• CRON実行用のLayerを作成して、1つのインスタンスに設定
• ...
Ruby on Railsは
プログラミングではない?
• Ruby on Rails・・・に限らずフレームワークは道具
• 道具の使い方を覚えただけでマスターしたつもり?
• (僕含め)中級者にありがちな万能感
• どう使うかが大事=プログラ...
以上
Upcoming SlideShare
Loading in …5
×

最近やった決済システムの実装の話

3,061 views

Published on

プラガブルな決済フレームワークを実装したときの話。

Published in: Technology
  • Be the first to comment

最近やった決済システムの実装の話

  1. 1. 最近やった 決済システムの実装の話 タケユー・ウェブ 竹内雄一 @takeyuweb
  2. 2. タケユー・ウェブ 竹内雄一 • さいたま市大宮周辺 • フリーランス8年目 • 基本ひとりで設計/実装/運用 • 高専クラスタ • 昔rack-ketaiってgemを作った ぐらい出典:ウィキメディア・コモンズ (Wikimedia Commons) https://commons.wikimedia.org/w/index.php?title=File:JRW_mimasaka-emi_sta.jpg&oldid=149101608 限界集落で起業 ディーゼル気動車 on Rails (ワンマン運転)
  3. 3. 事例 • 様々な支払い方法 • 様々な決済タイミング • 様々な商材 • アフィリエイト対応
  4. 4. 事例 様々な支払い方法 • 利用者が決済方法を選択できるようにして欲しい。 • 銀行振込 • クレジットカード • 前回のクレジットカード(クイック決済) • Edy • 楽天ID決済 • PayPal Express Checkout • 特定の条件でのみ選択できるもの。 • 楽天ID決済 … 楽天IDログインのみ • 前回のクレジットカード(クイック決済) • ※決済方法・業者はクライアント指定
  5. 5. 事例 様々な決済タイミング • 基本は毎回決済手続き • 都度決済 • 会員プラン契約の支払いについては、次回以降は自動継続出来 るようにして欲しい。 • 自動定期決済 • また、初回はクレジットカード認証(オーソリ)だけで、無料 期間後自動課金したい。 • クレジットカード認証(オーソリ) • 自動決済に失敗したら通知しつつ、都度決済に自動変更しつつ 猶予期限を設けたい。
  6. 6. 事例 様々な商材 • プラン契約 • 課金後一定期間有効 • 上位プランへのアップグレードは差額支払い+延長 • 下位プランへのダウングレードは即時 • サービス内通貨(コイン)パック • 購入後会員所有のパック規定のコインを加算 • 一定期間後失効 • 物品 • 購入者へ商品発送 • 上記はそれぞれ管理者が追加変更できるようにすること。
  7. 7. 事例 アフィリエイト対応 • アフィリエイトリンクから獲得した会員の決済などのタイミン グで成果を発生 • 自前のアフィリエイトシステム • 外部のアフィリエイトASP • チャージバック(決済取消) • チャージバックが発生したら、自前のアフィリエイトシステムでの報 酬については取消
  8. 8. 結構大変 • 様々な支払い方法 • 支払い方法ごとにフローが異なる • 様々な決済タイミング • 手動 • 商材ごとに別のUIから発生 • 自動 • 定期処理 • 様々な商材 • 商材ごとに決済後の処理が異なる • アフィリエイト対応 • 支払い方法や商材の組み合わせで発生したりしなかったり
  9. 9. 決済フレームワーク作っとくか • 抽象化し、再利用可能なコードの共通化 • 簡単なルールで決済方法、商材の追加に対応 • 支払い方法は商材がどれかを知らなくて良いし、商材は決済方 法を知らなくても良い • 呼び出し場所問わず、決済フローの開始・進行 • Controller • Grape • ActiveJob • rake など
  10. 10. 決済フレームワークを考える (決済フロー) • 共通の決済フロー括りだし • 請求伝票発行 • 支払い完了 • ペンディング • 差し戻し • 支払い方法変更 • キャンセル • 期限切れ失効 etc…
  11. 11. 決済フレームワークを考える (支払い方法) • 共通インタフェースの括りだし • 属性 • 名称 • 説明 • HTML(外部決済サービスへの接続など) etc… • 利用可能チェック • 決済フローの各イベント前後で必要な処理 • コールバック • before_open(billing) • after_open(billin) • before_close(billing) etc… • false を返したらロールバックして失敗を通知
  12. 12. 決済フレームワークを考える (商材) • 共通インタフェースの括りだし • 属性 • 商品名(見出し) • 価格 など • 購入可能チェック • 決済フローの各イベント前後で必要な処理 • コールバック • before_open(billing) • after_open(billin) • before_close(billing) etc… • false を返したらロールバックして失敗を通知
  13. 13. 決済フレームワークを実装する • ドメインサービス的なもの? ※DDDよくわかってない • 支払い方法オブジェクトと、商材インスタンスオブジェクトを 受け取って伝票を発行 • 行いたいフロー上のイベントを伝票を渡すとよしなに • 利用者による操作 • 管理者による操作(銀行振込の入金を確認した、など) • コンソールからの操作 • 決済代行会社のサーバからのコールバック etc… billing = Payment.new(user).open(payment_method, product) Payment.new(user).close(billing )
  14. 14. 支払い方法を実装する • 「支払い方法」抽象クラスを作成 • 継承によって各支払い方法ごとに 必要なコールバックやビューを追 加 • 例)クレジットカード決済 • 決済代行会社へのリンク • 決済代行会社からのコールバックのハ ンドリング • クレジットカード決済成功時に「前回 のクレジットカード」登録 • 銀行振込の入金があった場合の管理者 承認処理 etc… • クライアント指定で実装はしな かったけどStripeとかも組み込める はず
  15. 15. 商材を実装する • 「商材」モジュールを作成する • 各商材クラスにmix-inして必要な処理 を実装 • 例)契約の更新処理、差額を反映した 金額の計算、コインの加算処理 etc… • ダックタイピング • バリデーションしたいなら item.class.include?(module)して ArgumentError • 継承を使わない • STI(単一テーブル継承) • 商材ごとに必要なカラムはいろいろ • STIすると「あるモデルに不要なカラム」 がたくさん
  16. 16. アフィリエイトへの対応 • モジュールに分離 • アフィリエイトに対応させる支払い方法、商材にmix-inして必要に応じ て実装 • 成果発生条件 • 成果率 • 決済取消時に成果を取り消す etc… • 外部アフィリエイトASP • 支払い結果にアフィエイト成果タグ埋め込み
  17. 17. 定期自動決済の実装 • そこまでタイミングの要求が厳しくなかった(契約期限切れ後 猶予期間設定あり) • CRON(whenever) • 決済フレームワークを使って、「クイック決済」の伝票を発行、自動 決済ジョブを発行。 • 自動決済ジョブ(Active Job) • 決済代行会社にリクエスト送信 • 応答やコールバックで決済フローを進める • 失敗時一定回数リトライ • だめなら、決済フレームワークの機能で支払い方法の変更を実行
  18. 18. 定期自動決済とOpsWorks • OpsWorks • 負荷や時間に応じてインスタンスを増減 • CRONの問題 • 同じCRONタスクが複数のサーバで実行されてしまう • CRON実行用のLayerを作成して、1つのインスタンスに設定 • CRON実行用Layer以外ではwheneverを使わないカスタムCookbook • 決済代行会社への自動決済リクエスト送信元サーバIPの制限 • 自動決済ジョブを格納する専用キューを用意 • 自動決済用のLayerを作成して、1つのインスタンスに設定 • 自動決済用Layer以外では自動決済ジョブを実行しない queue_as :payments
  19. 19. Ruby on Railsは プログラミングではない? • Ruby on Rails・・・に限らずフレームワークは道具 • 道具の使い方を覚えただけでマスターしたつもり? • (僕含め)中級者にありがちな万能感 • どう使うかが大事=プログラミングだと思います。
  20. 20. 以上

×