Kyashが明かす、フルスクラッチで作る決済システムの強みと特徴

Kyashの決済システムの裏側

井上智士氏（以下、井上）：よろしくお願いします。「Kyashの決済システムの裏側」ということで、Kyashでサーバーサイドを担当しています井上が発表します。

軽く自己紹介です。

2017年12月までソーシャルゲーム業界にいて、新卒から5年間ぐらい働いていたんですが、「転職しないとな」という焦りを感じて、FinTech業界に絞って転職活動し、昨年の1月に縁あってKyashに入社しました。

Kyashでは、Kyashアプリの全般、あとはオペレーションチームが使っているような管理画面の機能の開発に携っています。

今回話すことは、Visa決済、QUICPay+決済の仕組みについて。あとはKyashはフルスクラッチで内製開発しているのでその開発についてと、内部不正の監視について簡単に説明します。

Visa決済システムについて

まずは、Visa決済システムについてです。

簡単な図なんですが、国内の実店舗やECサイト、海外のECサイトなどの加盟店から、加盟店の管理等をしているアクワイアラ、そしてVisaを通じて弊社のサーバーにリクエストが送られてきます。

これは仮売上のフローです。仮売上とはその名の通り確定した売上ではなく、まずは残高から該当金額の枠を押さえるという決済特有の仕組みです。仮売上で計上していた売上は、後で実際の売上に変更する処理が必要になります。仮売上では、主に加盟店の判定や入力されたPAN（Primary Account Number）、カード番号や有効期限が合っているのか、そのカードに紐付く累計決済金額がKyashが定めている上限を超えていないかなどをチェックします。

Kyashはプリペイドカードなので残高という概念があり、残高が足りているか確認します。足りない場合は差額をKyashに登録しているクレジットカードやデビットカードから自動チャージします。あとは、アプリ内で見られる履歴の反映や、決済に関する通知を行っています。

これは売上の図です。1つ前のスライドでご説明した仮売上データと売上データを紐付ける必要があります。紐付けを行わないと、60日ぐらいで返金をしなければいけないルールがあるので、売上を確定させます。

ここでは売上と言っていますが、数日後に仮売上がキャンセルされたり、あるものを買って、後日オプションを付けるといった決済をした場合には追徴する必要があるので、返金・追徴の処理や、仮売上と同じくアプリ内履歴への反映を行っています。

これはざっくりとしたフローで、詳細については後ほどご説明いたします。

QUICPay+決済システムについて

続いて、QUICPay+決済システムについてです。

先ほどのVisaの仮売上とほぼ同じなんですが、QUICPay+に関しては実店舗の非接触決済のみになるので、ECサイトでの処理はありません。Google PayからQUICPay+のサーバーを経由して、Kyashに届く流れになっています。

Visaの仮売上のリクエストとQUICPay+のリクエストに関してはまったく異なるので、それぞれで自前で実装しています。

売上に関しても、先ほどとほぼ同じです。

フルスクラッチだから実現できていること

ここが一番強調して言いたいことです。先ほどの仮売上の処理について、詳細に説明したいと思います。

まず、この加盟店の利用可能判定をしてます。

プリペイドカードはカードの有効性確認と仮売上を同時に行う性質があります。売上金額の枠を即座に残高から確保して、確保された金額が売上となる仕組みです。そのため、仮売上の金額と売上の金額が乖離するような加盟店は、プリペイドカードには都合が悪く利用できないようにしています。ホテルやガソリンスタンドでプリペイドカードはが利用できないことが多いのは、プリペイドカードの仕組みによるためです。

具体的にお話ししますと、ホテルはチェックイン時にまずは部屋の料金を払います。ですが宿泊中に飲み物を買ったり、それ以外にもなにかグッズを買ったりして、チェックアウトする時に金額が変わっていることがよくあります。プリペイドカードでは売上で大きな差額を徴収できないケースがあるので、基本的に弾くようにしています。

ガソリンスタンドも同様です。まずはカードを通してその有効性を確認し、ガソリンを入れた金額分を売上で上げてきます。

どちらも仮売上と売上金の大きな乖離があるため利用できない設定にしています。

続いて先ほど触れたカードの有効性確認についてです。ECサイトで決済する時は、カード番号と有効期限、裏面に記載されている3桁～4桁のセキュリティコードを入力すると思いますが、それらが正しいかどうかをチェックしています。

実はKyashではセキュリティコードは一切保存していません。

ではどうやって照合しているかというと、入力されたカード番号と有効期限から、Kyashに割り当てられた暗号化キーによって、必ず1つのセキュリティコードの数値が算出できるので、その算出した結果と入力されたセキュリティコードが一致するかを、毎回チェックしています。

累計決済金額に関しては、デイリーとマンスリー、あとはそのカード番号に紐付けられた全期間累計の決済金額のそれぞれで上限を設けているので、それを超えていないかをチェックしていきます。また、残高の確認もしています。

Kyashでは、残高が不足した際、その差分だけ登録されたクレジットカードやデビットカードから自動チャージする仕組みになっています。これは実は画期的な仕組みで、自社開発を行なっているからこそ可能なのです。

次に、アプリ内の利用履歴へ即座に反映されることです。これは普通の与信を使ったようなクレジットカードの場合、売上確定後に反映されるため、決済直後にマイページを見ても反映されてないことってよくあるかと思います。Kyashはプリペイドカードで、仮売上の段階で減算しているということもあるので、リアルタイムですぐにアプリ内の利用履歴に反映されます。

そして、決済が成功した場合は成功の通知、失敗した場合にも可能な範囲で失敗理由をリアルタイムで通知するようにしています。

例えば、Kyashはカードをロックする機能があるんですが、ロックされたままの状態で決済してしまった場合に、「ロックされているので、解除してからお使いください」ですとか、「この加盟店ではKyash Visaカードはご利用になれないので、他のカードを使ってください」など、できるだけわかりやすいプッシュ通知が届くようにしています。

そして、いろいろ機能はありますが一番これが大事です。ユーザーからいただいた声や改善案、あとは、ほとんどありませんがバグが出てしまった場合、ベンダーのパッケージソフトを使っていたりすると、修正してからリリースまでに1ヶ月かかってしまったりします。Kyashでは早くて翌日、遅くとも2日後ぐらいにはリリースができるようになっています。

どうして「早くても翌日」と表現したかというと、Visaの決済なので、まずはVisaに対して「この日にデプロイするよ」と申請しなければいけないからです。なので、1日、2日ぐらい余裕をもつようにしています。

内部不正の監視

続いて「内部不正の監視」です。

前提として、同僚を疑っているわけではありません。弊社はPostgreSQLを使っているんですが、auditという機能で残高のテーブルに対してinsertとupdate、delete、truncateの実行ログを必ず残すようにしています。当然truncateは実行されないので、いままでそのログが出たことはありません。

実行ログには、対象のテーブル、ユーザー名、日次、実行元のIPアドレス、実際に発行されたクエリが記録されます。

弊社にはそんな人はいませんが、万が一不正を働いて、残高を不正に増やしたり、誰かの残高を減らしたりといったことをやった場合に、ちゃんと気付けるようになっています。

audit以外にも、「残高が何によっていつ変動したのか」を記録しているので、先ほどの例にあったように直接更新した場合にはそうした履歴から追ったり、期が締まる時に、会計から「こういう数値が上がってきたんだけど一致してないよ」みたいな話があった時に、ちゃんと「いつ何のクエリが発行されたからズレ始めたんだよ」ということが確認できるようになっています。

「でも、やられてから気付くのでは遅いのでは？」という話があると思いますが、クレジットカードのセキュリティ要件でPCIDSSというものがあります。その要件で「データベースをいじれる人は絞る必要がある」という規定があるので、これである程度は防止できています。誰でもいじれるわけではない仕組みになっています。