この記事はカンム Advent Calendar 2019の4日目の記事です。

バンドルカード という1分で誰でもつくれて、3分でお買い物ができるVisaプリペイドカードのアプリを作っています。

バンドルカードとは何なのか、どういう課題を解こうとしているのか、という話は他のメンバーに任せ、この note ではバンドルカードのシステムの概要及びその前提となるクレジットカードのエコシステムについて、システム的な側面からお話します。

4-party model

4-party model とは、人々がカードを利用する場面に関わる 加盟店、カード会員、アクワイアラ、イシュア（後述）の4者及び、アクワイアラとイシュアをつなぐ国際ブランドからなる形態です。4-party scheme とも言います。この中でバンドルカードはイシュアという立ち位置にいます。

カード会員
これはそのままですね。物を買う、サービスを受けるためにお金を払う人です。

加盟店
実際にカードを利用して物やサービスを買える場所です。コンビニだったり飲食店だったりECサイトだったり。

アクワイアラ
加盟店の開拓やその管理業務を行うことをアクワイアリングと言い、それを行う事業者のことをアクワイアラと呼びます。

イシュア
カードを発行し、カード会員の開拓、その管理業務を行う会社です。いわゆるカード会社ですね。バンドルカードを運営するカンムもここに属します。

国際ブランド
Visa、Mastercard などのカードのブランドです。イシュア、アクワイアラは国際ブランドの名を冠して加盟店や会員の開拓を行い、その結果それらが相互運用可能になります。

ちなみにアクワイアリング業務とイシュイング業務を同じプレイヤーが行っている形態を 3-party model と呼んだりします。JCB や、カードではありませんが QR コード決済業者の多くは3-party model に分類できます。

また、加盟店とアクワイアラの間に PSP(決済代行) がいたり、アクワイアラとイシュアが国際ブランド以外のネットワークで接続していたりと実情はもっと複雑ではありますが、簡略化したモデルということで。

バンドルカードのシステムが行うこと

以上のモデルを踏まえて、一般的(?)なサービスが行うユーザー管理等以外に、カードという文脈でバンドルカードのシステムが行っていることは以下になります。

カードの発行/管理
アプリをインストールし会員登録するとカード番号やらセキュリティコードやらが発行されるような仕組み、及びカードのインターフェースとしてのアプリの提供です。ただでさえ簡単ではないカードという仕組み、さらにはカードというものに触れるのが初めてだったりする方もいらっしゃる中で、如何にして一人ひとりのリアルな日常に溶け込むパーツになれるのかというところは挑むに値する課題です。
また、これらのカード情報の取り扱い要件は PCI DSS というセキュリティ規格で厳密に定められているので、セキュアでいい感じに保管する必要があります。さらに、バンドルカードではアプリだけでなく、カードを実店舗でも使えるようにリアルカードも発行しているため、カードの印刷業者とのカード情報の受け渡しや、カード自体の配送フローも（セキュアに）構築する必要があります。

決済業務
決済のフローは大きく2つに別れます。１つ目はオーソリゼーション、もしくは単にオーソリ、と呼ばれるもので、決済が可能かどうか確認するフローです。会員が加盟店でカードを切った瞬間に加盟店-アクワイアラ-国際ブランドのネットワークを経由してバンドルカードのシステムに ISO 8583 というプロトコル（をベースにしたもの）の電文が届きます。それをもとにバンドルカードのシステムは利用可能残高を確認し、購入してもオッケーかどうかを返答します。そしてそのタイミングでアプリに決済のお知らせのプッシュ通知を送ります。
2つ目がクリアリングと呼ばれるもので、要するに売上の確定です。オーソリゼーションの時点では、あくまでも利用可能かどうかを確認しただけで売上は確定しておりません。後日、加盟店で売上を確定しそれをアクワイアラに上げ、それがイシュアにやってきます。イシュアはそれを元にカードの利用額を確定します。
プリペイドカードでなくクレジットカードであれば基本的には月一回の引き落としなので、オーソリゼーションで仮想的な利用限度枠のチェックを行い、クリアリングで確定したものを帳尻合わせて月1度の引き落としをすればよいのですが、プリペイドカードやデビットカードの場合よりユーザーから見たリアルタイム性が増すのでインターフェースにも工夫が必要です。

チャージ機能
バンドルカードはプリペイドカードなので、事前にチャージをしなければ利用できません。コンビニだったり、クレジットカードだったり、ビットコインだったり様々な手段でのチャージ方法を提供しています。そのために各種決済代行と接続したり、チャージ用のシステムを実装しています。またプリペイドカードではあるものの後払い機能も提供しています。

その他
決済/金融の文脈に戻ると、AML/CFT もそうですし、特にバンドルカードでは後払い機能も提供しているので、いかに不正な利用を防ぐかというところはシステム、オペレーションともにかなり重要です。

バンドルカードのシステムの概要

大人の事情で詳細な構成図は出せないので、箇条書きベースで書きます。
気になる人はぜひ声をかけてください。

フロントエンド
・React Native で iOS、Android 版出してる感じです。Flow を使ってますが TypeScript 移行の機運が高まっています。
・イベントのログは Firebase で収集してます。
・CI は CircleCI と Bitrise を使ってます。

バックエンド
・アプリとやりとりするAPI、決済業務を行うサービスなどほぼ全て Go で書いてます。
・開発フロー自体は、PR出してレビューして、CircleCI で CI回して、という感じです。デプロイは Slack から出来るものもあれば、コマンドラインで実行するところもあります。
・管理画面のみ Python で書いてます。

インフラ
・AWS で、出来る限りマネージドサービスに寄せるようにしています。基本的にほぼ全てのデーモンがEC2上で動いてます。コンテナではない。
・AWS上のリソースは Terraform で、EC2のインスタンス自体は Ansible で構成管理してます。
・Direct Connect 経由でのDCへの接続もあったりします。

機械学習周り
・不正検知などに利用しています。SageMakerで学習、推論用のエンドポイントの提供をし、API Gateway -> Lambda 経由で必要なサービスからアクセスしています。

監視周り
・メインの監視ツールは mackerel で、アラート管理は PagerDuty です。
・エラー監視はバックエンドもフロントエンドも Sentry を使ってます。

データ周り
・基本的に Redash 経由で各種データソースにアクセス出来るようにしてます。
・ログは fluentd で S3に集めて必要に応じて利用という感じです。

まとめ

以上のような感じでやってます。

プロダクト的な意味でもシステム的な意味でも課題は無限にあります。フロントエンドとデザイナの連携もっといい感じにやりたいよね、監査対応的な意味での管理コストの低減のためにコンテナ移行したいね、データパイプラインもちゃんと整備したいね、、、挙げ初めたらキリがないです。が、その中で自分たちが提供できる価値を最大化するためにやるべきことはなにか、日々頭を悩ませながらバンドルカードを作っています。

そして、そんなバンドルカードを作っているカンムではソフトウェアエンジニアを強く募集しています。バンドルカードはもちろんのこと、今仕込んでいる投資x決済の新規事業をリードしていく方も募集しています。
これを読んでちょっとでも興味持っていただけたら、ぜひカジュアルにお話しましょう。