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

0. Stripe がやってきた

今週火曜（2016-10-04）、ストライプさんが日本市場に本格参入したんだそうです。　（「個人や企業がインターネットを通して料金を受納する方法を提供する企業」 by Wikipedia）

多くの報道は『日本企業が130以上の通貨でビジネスできる』に注目していましたが、、、個人的には、“中間搾取” （？）や “上納金” （？？）を自動化できる『Connect 機能』が「超アツい！」と思いました。たとえば、代理店販売における事務作業が一気に無人化されちゃうかも～

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

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

まぁ「日本上陸！」と叫んだ所で、この業界、、、コンナモンです。（えぇ、誰も期待してません）

イイですね。

何度訪れても、まいど「リンク迷子」になれちゃう某Google社のマニュアル (+_+) と違って、迷うことなくサラっと読めてしまいます。機能概要の把握には、（API に慣れていれば）、チュートリアルに30分、APIリファレンスに１時間といった所でしょうか。

ちなみに、ログインもしていない段階から「貴様のターミナルで、この CURL コマンドを投げてみろ！」（ビリーズブートキャンプ風　←勝手な妄想）と言ってきます。スゴク“強引”というか、“男らしい”というか。。。　うまく表現できませんが、「まだ手も握ってないのに、いきなりキスを求めてくる」みたいな感じのチュートリアルです。（は？）

リファレンス・サンプルコードについても、「シンプルな作り方はコレ！」という一点張りな書き方。。。「いさぎよい」というか、「すがすがしい」というか。。。でも密かに「見習いたいな」と思いました。

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

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

バクっと要約するに、

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

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

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

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

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

正直、Questetra 自身（クラウド型ワークフロー）も見習うべきインターフェース（というか設計思想）だと思いました。実際、「API の利活用」は、実装者からすれば「テストしてもテストしても不安！」な訳です。この「Test Mode / Live Mode」を対等に扱う、というシステムデザインは、実装スピードや実装品質を高いレベルに押し上げることに貢献してるんだろうな、と思いました。

さて、立場上、当然の流れなのですが、、、（よくある流れで恐縮なのですが）、クラウド型ワークフロー『Questetra BPM Suite』の自動処理工程から、Stripe API にアクセスしてみました。

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

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

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

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

「サービス工程アドオン」の自作方法

せっかくなので、この自動処理工程をパッケージ化しておきました。これを使えば「スクリプトなんて書けないよー」という方でも、Stripe API への POST ができます。

以下は「自分用のパッケージを作るんだー！」という方のために、Addon の内容をカンタンに説明します。（詳しいマニュアルはコチラ： M415自動工程業務プロセス定義で利用可能な自動工程を追加する）

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桁」）

しかし考えてみれば、、、この手の EC システムは、みんな独自に（自前で）作っていたワケですよ。。。（つい最近まで・・・）

500万円、1000万円、2000万円。。。そんなプロジェクトが世界中にゴロゴロあったワケですよ。。。（きっと今でも・・・？）

しかし、今となっては Stripe と Questetra だけでも、ココまで簡単に構築できるんです。他のクラウドとも連携させれば、もっとスゴイことができるでしょう。

つまり「数年前ならン千万円」なシステムが、自前で！、数日で！！、無料で！？！作り上げてしまうことができるんです。。。（もちろん、ビジネスアイデアは別途必要です！）　イヤハヤ恐ろしい時代になったなぁ、と改めて・・・・

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

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

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