オンライン決済 Stripe を試してみた

2016年秋、ネット決済の巨人 Stripe が日本上陸! とりあえず体験記

◆0. Stripe がやってきた

今週火曜(2016-10-04)、ストライプさん(※)が日本市場に本格参入したんだそうです。

※「個人や企業がインターネットを通して料金を受納する方法を提供する企業」(Wikipedia

 

多くの報道は『日本企業が130以上の通貨でビジネスできる』に注目していましたが、、、個人的には、“中間搾取” (?)や “上納金” (??)を自動化できる『Connect 機能』が「超アツい!」と思いました。

 

(たとえば、代理店販売における事務作業が一気に無人化されちゃうかも)

 

techcrunch-stripe-debuts

http://jp.techcrunch.com/2016/10/07/20161003stripe-debuts-payments-in-japan-with-new-investor-sumitomo-mitsui-card-company/

 

◆1. さっそく試してみよう

で、、、「習うより慣れろ」ですね。。。

Stripe 社のホームページや正式版リリースに関するブログは、とっても綺麗な日本語に翻訳されているのですが、Stripe API のマニュアルの方は、、、見事に「全編英語」にてお届けされております。

 

まぁ「日本上陸!」と叫んだ所で、この業界、、、コンナモンです。

(えぇ、誰も期待してません)

 

stripe-api-reference-page

 

◆2. マニュアルの感想

イイですね。

何度訪れても、まいど「リンク迷子」になれちゃう某Google社のマニュアル (+_+) と違って、迷うことなくサラっと読めてしまいます。

 

機能概要の把握には、(API に慣れていれば)、チュートリアルに30分、APIリファレンスに1時間といった所でしょうか。

 

ちなみに、ログインもしていない段階から

「貴様のターミナルで、この CURL コマンドを投げてみろ!」
(ビリーズブートキャンプ風) ←勝手な妄想

と言ってきます。

 

スゴク“強引”というか、“男らしい”というか。。。 うまく表現できませんが、「まだ手も握ってないのに、いきなりキスを求めてくる」みたいな感じのチュートリアルです。(は?)

 

 

リファレンス・サンプルコードについても、「シンプルな作り方はコレ!」という一点張りな書き方。。。

「いさぎよい」というか、「すがすがしい」というか。。。

でも密かに「見習いたいな」と思いました。

 

 

個人的で無責任な感想ですが、、、、「PayPal さん少し御歳だし…、若くてたくましい Stripe さんに惹かれて…」という人が急増しそうな予感がします?!?

 

#ちなみに「分かりにくいな」と思うところがあれば、日本国内向け御用達の『WebPay』(←これはコレで、超おすすめ!)のサイトで機能比較する(あるいは事前学習する)のもアリかも…です! (爆)

 

※追記:WebPay さんは 2017年04月30日にサービス停止となります。ご注意ください。

 

customer-charge-on-stripe

 

◆3. Stripe 基本構造

バクっと要約するに、

-A. 【Customers】で顧客情報/カード情報
-B. 【Charges】で課金情報

を管理している訳ですね。(シンプルです)

 

平たく言えば、Aを登録して、そのAに対しての課金情報 B1 B2 B3 B4 B5 B6 B7 B8 B9 を送信できれば、わーい、という仕組みになっています。

 

stripe-easy-to-test

 

※追記(201702): その後のUI変更で「切り替えトグル」の位置は変わってます

 

◆4. Stripe の特徴

今まで Google の各種 API を中心に、”Kintone API” やら、はたまた “法人番号システム Web-API” やら・・・、いろいろな API を経験してきましたが、”Stripe API” は、、、何というか「独特」ですね。

 

特筆すべきは、『Test Mode』が、とても使いやすい、という点です。

 

正直、Questetra 自身(クラウド型ワークフロー)も見習うべきインターフェース(というか設計思想)だと思いました。

実際、「API の利活用」は、実装者からすれば「テストしてもテストしても不安!」な訳です。この「Test Mode / Live Mode」を対等に扱う、というシステムデザインは、実装スピードや実装品質を高いレベルに押し上げることに貢献してるんだろうな、と思いました。

 

#具体的には4つの key (Basic 認証)を使い分けます。そして「OAuth 2.0 のグラントフロー」なんて見向きもしない男気w

 

sample-workflow-with-stripe-api

 

◆5. ワークフローから呼び出すなら

さて、立場上、当然の流れなのですが、、、(よくある流れで恐縮なのですが)、

クラウド型ワークフロー『Questetra BPM Suite』の自動工程から、Stripe API にアクセスしてみました。

※ グレーの四角形が自動工程、ブルーの四角形がヒューマン工程

 

要は、購入者が入力した「クレジットカード情報やらメールアドレス情報やら」は、全て Stripe さんに預けて、Questetra 側は「A.顧客情報」のみを覚えておけばイイのです。(前半の工程)。

※ 実際のデータは「cus_9K3Z1YSdyG6mvV」な感じになります。

 

そして後は、料金が発生するたびに「B.課金情報」を Stripe さんに送る、という流れです!! (後半のループ)

※ もちろん「Stripe.js」を使ってブラウザから直接 Stripe さんにお届けして、サーバには「cus_hogehoge」だけを届ける方式の方が「王道」ですよ。(クロスサイト問題はありますが…)

 

※追記(201709): Stripe Elements でブラウザ通信させる方法は以下を参照してください。

 

 

ちなみに、上のワークフロー図は、極めて味気ないサンプルになってますが、、、、たとえば『完成予定の確認』や『製品の出荷』といったヒューマン工程、あるいは『サンクスメールの送信』『明細PDFの送付』といった自動工程を追加していけば、本格的な業務プロセスになりますよ!

(業務プロセスの「モデリング」と言います、ハイ)

 

ところで、、、「クレジットカード番号は記録すべきではない」というのは、カード決済ビジネスの「とても重要なツボ」なのですが、それでも「クレジットカードの下4桁」くらいは記録しておくべきです。(「どのカードにチャージされた?」という問い合わせが入るかも知れないし…)。この例で言えば、「カード番号」を「カード番号下4桁」のレスポンスデータで上書きするのがオススメです!

 

M415-1

 

◆6. 具体的な API 呼び出し

せっかくなので、この自動処理工程をパッケージ化しておきました。

これを使えば「スクリプトなんて書けないよー」という方でも、Stripe API への POST ができます。

※パッケージ化した機能拡張ファイル(自動工程 Addon-XML)は、Questetra のサイトにこっそりと載せておきました。

 

以下は「自分用のパッケージを作るんだー!」という方のために、Addon の内容をカンタンに説明します。

 

1つ目の工程では、【A.Customers】の情報、つまり「顧客のカード情報や顧客自身の情報」が、8つのパラメータで送信される仕組みになっています。

var responseJson = "";
var uri = "https://api.stripe.com/v1/customers";
var response = httpClient.begin()
  .basic( secretKey, "" )
  .formParam( "description", stripeDesc )
  .formParam( "email", stripeEmail )
  .formParam( "source[object]", "card" )
  .formParam( "source[exp_month]", expMonth )
  .formParam( "source[exp_year]", expYear )
  .formParam( "source[number]", stripeCardNum )
  .formParam( "source[cvc]", stripeCardCvc )
  .formParam( "source[name]", stripeCardName )
  .post( uri );
var httpStatus = response.getStatusCode() + "";

「契約名」を “description” で、「カード番号」を “source[number]” で…、と言った形で POST されます。スグに「OK!覚えたぜ!」と返事が返ってくるので、そのレスポンス(JSON)の中で必要そうな情報をワークフロー側に格納しています。(「顧客ID」と「下4桁」)

 

2つ目の工程では【B.Charges】の情報、つまり「課金情報」がを4つのパラメータで送信される仕組みになっています。

var responseJson = "";
var uri = "https://api.stripe.com/v1/charges";
var response = httpClient.begin()
  .basic( secretKey, "" )
  .formParam( "description", stripeDesc )
  .formParam( "customer", stripeCusId )
  .formParam( "amount", stripeAmount )
  .formParam( "currency", stripeCurrency )
  .post( uri );
var httpStatus = response.getStatusCode() + "";

「サービスの提供内容」を “description” で、チャージ金額を “amount” で…、と言った形で POST されます。スグに「OK!課金しとくぜ!」と返事が返ってくるので、そのレスポンス(JSON)の中で必要そうな情報をワークフロー側に格納しています。(「チャージID」と「下4桁」)

 

workflow-addons

 

◆7. まとめ

しかし考えてみれば、、、この手の EC システムは、みんな独自に(自前で)作っていたワケですよ。。。

(つい最近まで・・・)

 

500万円、1000万円、2000万円。。。そんなプロジェクトが世界中にゴロゴロあったワケですよ。。。

(きっと今でも・・・?)

 

しかし、今となっては Stripe と Questetra だけでも、ココまで簡単に構築できるんです。

他のクラウドとも連携させれば、もっとスゴイことができるでしょう。

 

つまり「数年前ならン千万円」なシステムが、自前で!、数日で!!、無料で!?!作り上げてしまうことができるんです。。。(もちろん、ビジネスアイデアは別途必要です!)

 

イヤハヤ恐ろしい時代になったなぁ、と改めて・・・・

あっ・・・、最後に大切なお話!

クラウド型ワークフロー Questetra も無料で運用できますよっ!

クラウド好きな貴方! ぜひ一度お試しくださいませ! (←毎度、スミマセン)

 

questetra-modeldriven

 

.

IMAMURA Genichi の紹介

CEO & Founder - Questetra, Inc. || http://www.facebook.com/imamura.genichi
IMAMURA Genichi の投稿をすべて表示

あわせて読みたい
15.野望・展望・志 の前の記事 真っ先にワークスタイルを変革すべき人は、誰か?
15.野望・展望・志 の次の記事 東京都豊洲市場の「意思決定プロセス」について
IMAMURA Genichi の他の記事 超交流会の準備、始めます

アーカイブ

 RSS