エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン

決済システムに“民主革命”を~開発者向け決済APIの『WebPay』を生んだ、20代エンジニアの挑戦

公開

 

WebPay-image

「今、広く使われている決済システムは、1990年~2000年代に作られたレガシーなシステムがベースになっているものが多い。僕たちは、それを時代に見合ったもの、つまり2010年代の決済システムに変えたいと思っています」

そう語るのは、6月27日、正式にローンチした『WebPay』の開発者で、運営元であるfluxflexのCEO久保渓氏。彼と仲間たちが生み出した開発者向けのクレジットカード決済APIは、いわば「決済システムの民主革命」を起こし得るポテンシャルを秘めたものだ。

サービスサイトのTOPに《簡単な実装》、《豊富な機能》、《今すぐ試せる!》といった紹介文が並んでいるとおり、WebPayは開発者の使い勝手を徹底的に追求して設計・開発を行ってきた。

数多くのディベロッパーが、自ら運営するWebサイトやアプリ内に手間なく簡単に決済システムを組み込めるようにすることで、久保氏の言う「2010年代の決済システム」が自然に形成されていくと考えているからだ。

■WebPayのより詳しい特徴は、同社リリースにて

SaaSベースの総合決済ゲートウェイを提供するGMOペイメントゲートウェイと資本業務提携を結び、北米で先行して類似サービスを提供するStripe社のAPI と高い互換性を持たせたのも、すべては「僕ら1社で『システム』を作り替えるよりも、同じ方向性を持つ企業と連携した方が、『エコシステム』を構築しやすい」という判断から。

まさに、オープンイノベーションが重視される時代に沿ったやり方といえるだろう。

では、彼らがWebPayに可能性を見出した理由、6名(2013年7月11日時点)という少人数で巨大な決済システム市場に挑む原動力はどこにあるのか。久保氏と、現行バージョンの開発を手掛けた濱崎健吾氏に話を聞いた。

PayPalほか既存の決済サービスが不便なところを愚直に変える

WebPay-Devteam

(写真左から)fluxflexの久保渓氏と濱崎健吾氏

米サンフランシスコに拠点を置くfluxflexの設立は2010年3月。WebPayの開発は、ファウンダーの久保氏と、彼が米国留学をしていた当時、たびたび帰国しては「はてな」など複数のWebサービス会社でインターンをするうち顔見知りになった濱崎氏、そしてCTOを務める曾川景介氏の3人が中心となって進められた。

それぞれが、まだ20代半ばの若手エンジニアたちだ。

久保氏は、アメリカでいくつかのWebサービスの立ち上げや売却を経て、米で起業。2011年の半ばまでは、まったく別のサービス開発を行っていた。

その後、曾川氏、濱崎氏がジョインし、本格的に事業化を進めたのがWebPayだった。fluxflexの新規事業として、社会全体に大きなインパクトを与え得るテーマを模索した結果、行き当たったのが決済回りのサービス展開だったという。

Webサービスの開発者向けに決済システムを提供している企業として、すでにPayPalのような先達がいくつか存在していたが、これら先行サービスが抱える課題を解消することで、活路を見出せると考えたのだ。

「例えばPayPalを自社サイトに導入した場合、購入者の方が支払いをするには、いったんPayPalが用意した決済ページに飛ばなければなりません。PayPalの外部決済ページでコンバージョン率や離脱率などのアクセス分析を詳細に実施するのは難しいため、どう改善したら良いのか分からないという不便さをサービス開発者は抱えていました」(久保氏)

これらのプロセスがブラックボックスのままだと、Webビジネスで最も重要なコンバージョン改善などが的確に行えない。久保氏も、イチ開発者として不便だと感じていた。

この実体験こそが、WebPay開発の原動力となった。自分が不便だと感じることを解消するサービスを作りたい。そのためには、ディベロッパーが自由に決済機能を組込めるよう、APIとライブラリをオープンにするべきだ――。

この久保氏の考えに共感したのが、濱崎氏だった。

彼は前職のクックパッドで決済にかかわる部分の開発を手掛けていた際、通信キャリアやクレジットカード事業者が提供している決済用の機能が複雑過ぎると苦しんでいた。

「分厚い仕様書を読み込まないと実装できないし、テスト用環境の提供まで長く待たされ、実際の動作の確認まで膨大な時間が掛かります。それに、仕様が機密情報扱いなのでライブラリもほとんど公開されず、同じ目的の実装をしている開発者が世の中にいっぱいいるはずなのに全部イチから作らざるを得ない。さらには、その仕様も現代の技術に対応しているとは言い難く、そこに依存した部分の実装だけが浮いてしまい、ほかの機能と同様に改善を進めることが難しくなります」(濱崎氏)

同じ思いを持つ彼らは、WebPayの開発方針を「導入が簡単で、導入後の改善もしやすいものに」と決め、改善を重ねてきた。

最重要となるセキュリティ面の担保に、「最新技術+α」で対応

WebPay-image2

現在公開している「開発者向け情報」は、今後も内容の充実&改善に注力していくと話す

「技術者として、過去の自分を救いに行く作業だった」(濱崎氏)という改善の結果、WebPayは久保氏が1人で開発したプロトタイプから、格段にシンプルなサービスに生まれ変わった。

詳しくはWebPayの「開発者向け情報(https://webpay.jp/docs/introduction)」を参照してほしいが、わずか10行のソースコードやコマンドが用意されており、ターミナルで実行するだけで課金処理を実装できる。

さらに、APIドキュメントがcurlコマンドのほかRuby、PHPと複数の言語で公開されているので、それぞれのディベロッパーが得意なプログラミング言語で実装可能だ。

「WebPayはStripe社のAPIと互換性を持たせましたが、定期課金の部分で使いづらいところがあったので、そこは当社独自の仕様に変更するため機能の取り下げを行いました。複雑で分かりづらいものを、いかにシンプルで使いやすいものにするか。そこにこそ、技術者の腕が試されると思っています」(濱崎氏)

ただし、既存の決済システムが複雑かつ難解で、導入時の承認審査にも時間が掛かっていたことに、理由がないわけではない。クレジットカード番号という重要な顧客データを扱うシステムとして、法対応とセキュリティの確保が絶対条件だからだ。

「導入・運用が容易で、カスタマイズも自由な決済API」という打ち出しをしているWebPayは、お手軽なものほど安全面に不安が残るという世の常識と戦っていかなければならない。

WebPay-Devteam2

決済関連のサービスで最も重要な、セキュリティ面での対応について説明する2人

この点は、プロトタイプの設計・開発時から考慮していたと久保氏は強調する。

「クレジットカード取り扱い事業者だけでなくすべてのECサイト運営者は、国際セキュリティ基準のPCI DSSへの準拠が必要ですが、特に組込み型の場合だと通常288項目にものぼる基準を満たす必要があります。

WebPayはクライアントサイドとサーバーサイドの双方でトークン化して、クレジットカード情報の取り扱いを安全に回避する仕組みを導入できるように設計してあるので、利用するディベロッパーの方は準拠に必要な項目をわずか13項目まで減らすことができます。PCI DSSの準拠に関しては、弊社自身もLevel 1という最高基準を満たすために対応を進めており、先日3日間に及ぶ実地での監査を実施しました」(久保氏)

「また、セキュリティ面で生じる不安を払拭して安心してご利用いただくためにも、こうした基準への対応はもちろん、説明用のドキュメンテーションにも工夫と改善を重ねながら、1つずつクリアしていきたいと考えています」(濱崎氏)

6月の正式ローンチ後、問い合わせやTwitterの反響として「簡単過ぎて不安」、「シンプルだが(セキュリティ面で)大丈夫なのか?」という声がいくつか上がってきたという。それらを踏まえ、より的確な伝え方にチューニングしていくことが、直近の最重要事項だと2人は話す。

《技術で「最新の安全」を提供するだけでは、既成概念を変えることはできない》

この現実に、現在進行形で挑んでいるWebPayが、本当に新しい“決済のエコシステム”を創ることができるか。今後の展開から目が離せない。

取材・文/浦野孝嗣 撮影/伊藤健吾(編集部)