ワークフローサンプル: 第555話：Web受付、だけどカード情報は非保持(2)

業務：登録カードへの課金

「クレジットカード登録」の仕組みはできた！（前回記事参照）

『カード番号』や『CVC』といったカード情報は Stripe 社（決済代行会社）に預けられ、ワークフロー側にはその「預かり番号」としての『Stripe Token』(tok_{24文字})だけが流れる仕組みだ。つまり、日本政府が「2018年3月までにクレジットカード情報の非保持化を！」と言っている要件についても満たすことができたと言える。（非保持化＝カード情報保護のための第一の対策）

コレで「自社システムからカード情報が漏洩するリスク」はゼロになったと言ってもイイ！　安心して Web 登録してもらえる！！

※ Stripe Token は一度の処理にしか使えない仕様（single-use token）となっており、この例では『Stripe Token』から『Stripe CustomerID』(cus_{14文字})への自動変換も同時に行われています。（自動工程「Token to Cus_ID」）

課題：課金オペレーションにおける手作業の排除

しかし、良く考えてみれば、、、実現したのは「カード情報の保護」だけだ。

たとえば『課金金額』を間違えたり、たとえば『課金相手』を間違えたり、、、そんな「課金オペレーション」のミスリスクについては、ゼロになっていない。たとえば「Ｘさんのメールアドレス」に「Ｙさんの名前宛」で課金予告を送ってしまったとか、、、、考えるだけで寒すぎる。「課金業務フロー」における

お客様の名前
お客様のメールアドレス
Token or CustomerID

あたりのデータは、自動的にあらかじめ入力されているようにしたい。そうなっているだけでミス率はゼロに近づくハズだ。下流工程でチェックを担当する「頼りない上司」の負担も、少しは軽減されるだろう。

[クレジットカード課金プロセス]

[クレジットカード情報の登録受付プロセス（前回記事の拡張）]

解決：業務プロセス間のデータ連携

２つの業務プロセス「A.カード登録受付プロセス」と「B.カード課金プロセス」を接続すれば、Ａ案件のデータの一部（もしくは全部）を引き継いだＢ案件を自動開始させることが可能となります。

※ 具体的なフロー設定としては、Ａの最終工程付近に［メッセージ送信中間イベント（HTTP）］を配置し、Ｂの先頭に［メッセージ開始イベント（HTTP）］を配置します。
※ 参考マニュアル）「M411 プロセス接続: “納品プロセス” から “請求プロセス” が自動開始されるように設定する」

ここで紹介した「クレジットカード課金プロセス」で言えば、あらかじめ『お客様の名前』『Email』『Stripe Customer ID』『Last4』の4つのデータが引き継がれた状態で開始されます。つまり、最初のヒューマン工程『1.課金額の入力』の際に顧客に関する情報や Stripe 情報を入力する必要はなく、『課金金額』や『課金予定通知メールの文章』といった情報入力に集中することができます。

考察：二回目以降のカード課金

たとえば「得意先に対する販売代金を毎月請求する」といったケースでは、『クレジットカード課金プロセス』が毎月開始される必要があります。

その様な場合、（「メッセージ開始イベント」からの自動開始を待つのではなく）、ヒューマン工程『1r.課金額の入力』からの手動再開始でプロセスを開始し、前月の『Stripe Customer ID』を再利用して課金します。つまり、得意先に毎回『クレジットカード情報の登録』を行ってもらう必要はありません。

なお、手動で開始する際の『1r.課金額の入力』について、その全項目を手作業でコピー入力しても構わないのですが、、、もし前回データを［再利用してプロセスを開始］する機能を使えば、全データが複製された状態で開始することが可能です。すなわち、『金額』『課金日時』といった前回請求と値が異なる項目についてのみ編集すれば良くなります。

※参考マニュアル）「M103 新規開始: 過去のデータを再利用して新規開始する」

[クレジットカード課金プロセス：「1.課金額の入力」画面]