サブスクリプションサービスをつくる時にエンジニアが考えること / Behind the Scenes: Engineering a Subscription Service「B/43 Tech Talk 〜 Fintech×サブスクリプションサービス立ち上げの裏側〜」にて @ohbarye が"サブスクリプションサービスをつくる時にエンジニアが考えること"と題して発表した資料です。 イベントURL: https://smartbank.connpass.com/…
メルペイ立ち上げの裏側 – 決済サービス開発のゼロイチ話 | メルカリエンジニアリング
はじめに こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。この記事は、Merpay Advent Calendar 2019 の21日目の記事です。 3年前、ソーシャルゲーム業界からメルカリに転職してから、幸運なことにゼロイチで決済サービスの開発に関わることができて、エンジニアとしても人生としてもとても充実の3年間を送りました。 そして、今、日本ではすでにキャッシュレスブームが始まっていて、これからFinTechの領域で様々な革命が起きていくと思っています。この記事では私がエンジニアとしてこれまでに決済サービスの開発に関わってきたことを振り返り、これからFinTechに関わりたい方への参考になればと思います。 社内向け決済基盤の検討 メルカリに入社してすぐ、当時社内ID基盤を開発していたPlat
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
Google Play アプリ内定期購入を実装する - クックパッド開発者ブログ
技術部モバイル基盤グループの宇津(@uzzu)です。 今年3月、クックパッドのAndroidアプリはこれまでサポートしていたクレジットカード、キャリア決済に加えて、Google Playアプリ内定期購入によるプレミアムサービス登録機能を追加しました。 Google Playのアプリ内定期購入機能は個人的に気に入っているので早速乗り換えました。 良い機会なので、この記事ではIn-app Billing version 3(以下IABv3)以降のアプリ内課金の実装を振り返りつつ、Google Play Billing Libraryの紹介も交えながら開発TIPSを紹介します。 TIPS1. Google Play Billing Libraryの採用 IABv3以降のアプリ内課金を実施するためには(ざっくりですが)以下のフローを実装する必要がありました。 ServiceConnection を
月額課金モデルの Web サービスの設計方法 - ボクココ
ども、@kimihom です。 今回は月額課金モデルの Web サービスを実現したい企業向けに設計の参考になる情報を提供できればと思う。こういう情報は割と自分なりに設計して実装するっていうパターンが多いかと思うが、とても大事なことなので慎重に検討していこう。 決済サービスの選択 まずは決済サービスをどれにするかって話。ここで一番大事なのは、扱うカード提供会社の種類だ。 Visa, Master は当然として、その他のクレジットカード会社が使えるのかどうか。ここは顧客のカード登録の自由度を決めるので、実は決済手数料よりもよっぽど大事な項目になる。要チェックだ。 あとは企業によっては収益が出た後の支払いフローも確認しておいたほうがいいかもしれない。収益の確定はいつで、支払いはいつなのか。黒字倒産するほど急成長することは稀だとは思うが、そのあたりのキャシュフローも事前に把握しておく必要がある。
Stripe Billing 101 - Qiita
背景 今まで Stripe Subscriptions として出してきた製品がこの 4 月に Stripe Billing としてパワーアップし、新しくなりました。今回は、従来の定期支払いの請求に加え、より複雑な請求方法を Billing で実装できるようになりましたので、紹介していきます。 これまで Stripe Subscriptions 101 Part 1 としていた記事の更新記事になります。 今回のアップデートでは、段階制料金体系を構築する Tiered Pricing や毎月の利用料に応じて請求できる Metered Billing といった、主に SaaS 界隈で採用されている手法に、さらに寄り添うことができる仕組みとなりました。 例えば、ライセンスの数量テーブルに応じて価格が異なるサービスやライセンスが増えるごとに単価が異なるようなサービス、決められたサイクルで定期的に請求
Rails を使った EC アプリケーション開発について学べる本 "Take My Money" を読んだ - kymmt
読みました。 Take My Money: Accepting Payments on the Web 作者:Rappin, NoelPragmatic BookshelfAmazon どんな本か 副題が "Accepting Payments on the Web" となっているように、決済 (payment) システムをもつ Web アプリケーションを作る方法について説明しています。『達人プログラマー』などでおなじみの The Pragmatic Bookshelf シリーズの本です。 チケット販売システムの開発を通して、次のような具体的な話題に触れています。基本的には Rails 5 を使ってロジックからビューまでを開発していきます*1。 決済システムの実装 ショッピングカート 外部決済サービスとの連携 サブスクリプション機能 エラーケースとその対策 管理画面の実装 返金など注文の操
なぜリファクタリングではなくマイクロサービス化を選んだのか？ メルペイの決済処理開発の裏側
2018年10月4日、株式会社メルカリが主催するイベント「Mercari Tech Conf 2018」が開催されました。メルカリグループ各社が、今後目指す方向や、これから取り組む技術的なチャレンジなどを語るエンジニア向けカンファレンス。2度目の開催となる今回は「Evolution（変化）」をテーマに、エンジニアたちがメルカリの技術のこれからを語ります。プレゼンテーション「どうして僕らは決済処理をマイクロサービス化しようとしているのか」に登壇したのは、メルペイ、ソフトウェアエンジニアの斎藤祐一郎氏。現在開発中の金融サービス「メルペイ」において、リファクタリングではなくマイクロサービス化を選択した理由を解説します。講演資料はこちら 決済処理のマイクロサービス化における3つの課題 斎藤祐一郎氏（以下、斎藤）：マイクロサービス化の話題が盛り上がって、数年が経ちました。みなさまは、さまざまな論文や
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
