キャッシュレス決済システムの設計・開発とは？拡張性と安定性を支える工夫

実店舗向けQR決済を支える2つのキャッシュレスサービス

まずは２つサービスをご紹介します。最近このようなキャッシュレスサービスを作りました。まずはGMO Cashless Platformのご紹介をいたします。こちらは、システムというよりゲートウェイシステムではありますが、実店舗向けのQR決済のゲートウェイシステムです。PGマルチペイメントサービスはEC・WEB（オンライン）の決済サービスであり、こちらは実店舗向けの決済サービスです。アイコンを掲載しておりますが、こういった決済手段を繋いでいるゲートウェイの決済サービスといった形になります。

もう１つが、GMOどこでもキャッシュポイントです。今年の7月にプレスリリースしておりますが、自動精算機や券売機といった、いわゆる街中にある指で操作する端末と、スマートフォンで管理している、最近流行のコード決済「○○Pay」や「電子マネー」、その他銀行の口座といったものとをQRコードという仕組みを使って橋渡しをします。

それらのサービス・スマホと、キャッシュポイントにできるものが例として資料にありますが、それぞれにニーズがあります。スマホウォレットで言えばお客様（エンドユーザー様）の口座情報・残高を持っていますが、世の中への接点というのを探しています。一方で券売機やATMは色んなメニューを持っているものの、新しいサービス・提供できるサービスを探しています。そういったところを繋ぐことを支援します。

ただシステムとしてAPIを作るだけではやはり成り立たない部分もあります。こちらのサービスは直近で私が担当したサービスですが、どういったことを考えながらこのシクミを作っていったか、ご紹介していきたいと思います。

繰り返しにはなりますが、QRコードを使ったサービスです。この決済サービスをより広めるため以下を考えました。

1点目は「ユーザーが使いやすく、導入しやすいシクミとは？」2点目は「今後のサービス拡大に耐えうるシクミとは？」3点目は「スピーディかつ安心・安定したシクミにするには？」以上3点です。

ひとつずつ簡単に触れていきます。

使いやすい決済システムの設計：APIとお金・データの流れ

弊社はペイメントゲートウェイという社名がついているとおり、ゲートウェイシステムを提供するサービスを作っています。GMOどこでもキャッシュポイントはそのゲートウェイが提供する「API形式」で、このシステムをアプリケーション提供しています。それに加えて、そもそもどういったAPIが欲しいのか、エンドユーザーが触る端末はどういった表示でどういったデータが必要なのか、といった点を導入の段階から色々検討します。

例ですが、「どうやってQRコードを使おうか？」を考える場合2種類あります。スマホを操作してバーコードを見せる形のCPMと、券売機やATMなどの画面にQRコードを表示する形式のMPMです。このどちらが良いのかというのを考えます。また、APIを提供するにあたっては、ユーザーの接点となる端末がどういった情報をやりとりさせたいのか、というところが検討の段階で一番大事だと考えています。3つ目に、「実装された結果、どういったデータとお金の流れになるのか」というところを導入のタイミングで考慮しています。

エンジニアとしてシステムを作っていると、データの流れというのはインターフェース・仕様書といった形でAPIを設計するときに作るため、わりとイメージしやすいと思います。一方こういった新しいシクミ、システムを含んだシクミを作るにあたり、すごく大事なのはお金の流れだろうと考えています。この両者を意識的に設計のタイミングで検討しています。まず、データの流れについて概念図を用意しました。ユーザーの設定（端末）から弊社システム、そして連携先のシステムに流れていきます。しかし、お金の流れには様々なパターンがあります。例１のように途中で「取り分」として、左から右に流れていく中で少しずつ抜いて、最後にお金を振り込むというケースもあれば、例２のように一回振り込んだ後で、返金してもらうというケースもあります。データは左から右へ流れますが、実はお金の流れは必ずしも一致しないケースがあります。

特に決済システムはシステムを設計するタイミングで、お金の流れを事前にしっかりおさえておくということが大事になります。ここを曖昧に、手を抜くと後々開発にも手戻りが多く発生します。

私が取り組んだシクミでは、シクミ・流れ全体を考える時に何か特別なことをやっていたかというとそうではなく、非常にベーシックなシーケンスを使ってコミュニケーションを取っていました。個人で色々なツール、開発効率化ツールを使うことはありますが、実は関係する他者とのコミュニケーションはすごくベーシックなことが大事であると考えています。スピード開発となると設計書を作ることがなかなか難しい側面があるため、効率的に認識齟齬なく進めるとなると、このシーケンスでしっかり会話していくことが大事です。

サービス拡大を見据えた決済システムの拡張性

大きな流れ、シーケンスを作った後に、サービスの拡大に耐えうるシクミはなんだろうかと考えましたので、いくつか事例を挙げさせていただきます。先ほどは設計の話だったのに対して、こちらは実装的な話になります。例えばデータベースのデータの持ち方や、管理画面のメニューの持ち方、APIのURLの文字列と細かいところにこだわっています。共有しているのはタイトルにあるとおり、「できるだけ個別の業務色を持たない」ということです。すごく大事だと思っています。

GMOどこでもキャッシュポイントの拡張をしていくと、このような概念図になります。中心にあるPGのシステムに対し、左側にユーザーの接点（例に券売機・ATM）、右側に〇〇Pay。種類が増えれば増えるほどユーザーは増えていきます。色々な管理対象の端末や取引も発生します。そういったものが増えていくことを考えた場合、やはり1つ1つ作りこむと後に拡張性が落ちてしまいます。また、一気に制限をかけるとうまくいかないところもあります。例えば、URL Pathの文字列をマスター定義に合わせて、「station」（上図）と同じアプリケーションでも意図的に分けるようにすることで、のちのち流用制御しやすくします。件名参照する時もパスを条件として使うことで、意図せず見えてはいけないヒトにデータを見せないようにするといったところも制御ができるように工夫をしています。ただし、共通してロジックには極力書かない、外部定義化する、という点はこだわっています。これには関係者との調整が大事だったりします。

APIテストとインフラ選定で決済システムの安定性を支える

いわゆる普通のAPIのテストは当然としても、APIが呼び出される流れを見てテストすることを考えて実施しています。セキュリティ対策は、一般的なパラメーター改ざんをされたらどうなるか、といったテストはしますが、暗黙のうちに呼び出しノードは「こういうAPIの順番で呼ぶんだろう」と想定してしまうことがテストフェーズだとあると思います。そこであえて指定したAPIの呼び方ではない場合は大丈夫か、というテストに取り組んでみたり、イレギュラーなことをやり、どう呼び出されてもAPIのシクミとして動くとことをきちんと担保します。ここに『端末からは「こう呼ばれることになっている」の呪縛』という書き方をしましたが、私もはまりかけたことがあり気をつけているポイントです。

性能面は、決済システムに限る話ではないと思いますが、やはり安定したシステム、細かい性能評価も大事だと思います。SQLのパフォーマンスもきっちり確認します。

インフラはどういう風に考えているのか、という点についてです。冒頭で紹介した２つのシステムですが、結果的にオンプレとクラウドを併用しています。では、どのように使い分けてるのかというと、正直なところ厳密な仕切りはなく、アプリケーション観点で運用をどれくらい操作することがあるか、どれくらいの伸び率になりそうか、そもそも予測できるかどうか、という環境を都度選定しているのが実情です。

決済システム開発で重視する設計と拡張性

新しい決済サービスを提供するにあたり、弊社の場合はゲートウェイシステムという中心部分を担当しています。ゲートウェイシステムを作る担当だからこそ、全体を見た設計がすごく大事です。特にお金とデータの流れをしっかり押さえることが大事です。言い換えると、ビジネスの流れを押さえ、両者のシクミを作る必要があり、同時にそのシクミを作ることができるのがゲートウェイシステムを作る担当者、とい言えるのではないかと思います。

2点目は、先ほどの実装的な話の繰り返しですが、あまり接続元・接続先の色に染まり過ぎない設計と実装を常に頭の片隅におきながら作る。もちろんなかなか調整を含め難しい部分はあると思いますが、そういうところのこだわりが拡張性に繋がってくると考えています。

紹介した2つのシステムですが、ここ1年の間にそれぞれ立ち上げたサービスです。QR、バーコードをつかった様々な決済のシクミはこれからもまだまだ広がっていきます。こういった全体のシクミづくりには今後もチャレンジしていきたいなと考えています。

私からの紹介は以上となります。ありがとうございました。

FAQ