決済システムを作るまえにこれだけは知っておこう

近年、StripeとかPayjpとかLine PayとかPayPayとか便利な決済サービスの登場により、課金システムを作るハードルはかなり低くなりました。 しかし、これらのサービスはあくまで決済業務の一部を肩代わりしてくれるだけです。 決済代行サービスを使うだけで簡単に課金を伴うサービスを公開できるというわけではありません。 このへんを勘違いして、大変なことになる人が少しでも減ったらいいな～と思ってこの記事を書きました。

ここに書いてあることを前提の知識としてもっていない人は、安易に決済系に手を出してはいけません¹。 よくて自分が死ぬほど大変な思いをします。 悪い場合は会社が吹き飛んだりします。

決済システムの開発をフリーランスのエンジニアに依頼しようとする人は、ここに書いてあるような内容をエンジニアがちゃんと理解しているかどうかをチェックすべきです。 また、（決済システムに限りませんが）エンジニアに任せておけばなんかいい感じのものができるわけではありません。 見てくれはそれっぽいものが作れるかもしれませんが、業務フローと親和しないシステムを運用するのは非常に大変です。 運用でカバーが大変にならないように、プロセスのすり合わせは綿密に行うとよいでしょう。

業務設計をちゃんとやろう

かつて僕の上司にあたる方が「我々のシステムがやっていることは紙と鉛筆と電話があれば代替できる仕事」と表現していました。 言われてみると確かにそうで、システムというのは紙と鉛筆と電話があればできることを便利にしているに過ぎず、 逆に言うと紙と鉛筆と電話で決済業務を回す方法が理解できていなければ、まともなシステムを作ることはできません。 システム開発は、どんなデータをどのような手段で取得し、どこに記録していつ使うのか、また誰とやり取りするのかみたいな話を整理するところから始めることになります。 特に決済まわりの業務をシステム化するときはこのフェーズが非常に重要になります。

ECサイトでの物品購入やゲームの課金のように、1度の取引で一度課金して終わりのタイプのシステムは比較的シンプルなのであまり難しくないかもしれません。 一方で、分割払いやサブスクリプションモデルのような1度の取引に対して複数回課金が発生するタイプのシステムはいきなり複雑になります。

決済の機能に特化し、高度に抽象化された決済代行サービスはこういった複雑さをある程度見なくて良いようにしてくれます。 一方で、「支払いが正常に行われなかったユーザをあなたのサービス上でどのように扱うか」といったような サービスの仕様に密接に関連している部分については、決済代行サービス側ではほとんど面倒を見てくれません。 サービスの仕様はあくまでサービス側に責任があり、業務設計を行った上でシステム仕様に落とし込むことが必要です。

特に重要なポイントとしては、異常をどのように検知するのか、また検知したときにどのようなオペレーションを行うのか、 そのオペレーションはシステム上で実行可能か²といった観点が挙げられます。 これらを考慮に入れた上でシステムを設計するスキルが要求されます。

運用設計はもっとちゃんとやろう

便利なサービスがたくさん登場した現代においては、正常系がちゃんと動くだけの決済システムを作ることは非常に簡単になりました。 ところが、正常系が動くだけの決済システムというのは概ねクソシステムです³。

世の中にはサービスを利用しながら、お金を払い忘れる人もいます。 システムの調子が悪くて中途半端な状態でエラーになって決済を中断してしまうこともあります。 通信が遅いからと行って決済画面で更新ボタンを連打するユーザもいます。 あるいは、不正に利益を得るためにこのような事態を悪意を持って引き起こそうとするユーザもいます。 バグによって予期せぬデータが生まれてしまったり、自分たちのシステムと決済代行側のシステムでデータの整合性が損なわれたりすることもよくあります。

決済システムを運用していると、このような状況が頻発します。 運用でカバーと口で言うのは簡単ですが、人間の作業量はシステムのように都合よくスケールしませんので、 サービスが成長しはじめてユーザ規模がちょっと増えただけで手運用はたいへん厳しくなります。

お金が絡むだけに、不利益を被ったユーザ側の温度感もかなり高くなる傾向にあります。 ビジネス部門からの「早く何とかしろ」という圧力は日に日に高まり、気づけば一日中運用対応をやっていて他の開発に手が回らなかった、なんてことも珍しくありません⁴。 特に人数の少ないベンチャー企業や個人事業においては、これらの対応に時間を取られて本来やるべき作業が進められない（しかし、お金をもらっている以上安易にサービスを止められない）といった状況に陥ってしまうこともあります。

予期できる不具合に対しては、自動で復旧する仕組みを作ったり、ユーザが自分で操作することで正常な状態に戻ることができる機能を提供するなどの工夫をします。 また、同様の不具合が再発しないようにシステムをブラッシュアップしていくことも必要です。 加えて、システム上の対策にとどまらず、最後の砦として法的手段に頼ることができるようにするための利用規約の作成と規約への同意の取得も重要となるでしょう。

これらの対策を行ってもなお、異常ケースの発生を完全になくすことはできないと思います。 最終的にはマニュアルオペレーションが必要になります。 高いプレッシャーのもとで作業するエンジニアが少しでも楽になるために、ログやデータベースの状態から素早く状況をトレースできるようなシステムを作るスキルが求められます。 もちろんこのスキルにはシステムを取り巻く業務フローへの深い理解が前提となります。

関連法規・業界規制にどんなものがあるかは把握しておこう

エンジニアにとって決済まわりで一番ハードルが高いのはこのあたりではないでしょうか。 すごく難しいのですが、ここをないがしろにしたサービスはすぐSNSでオモチャにされて炎上してしまいます。 会社（サービス）としては信用を一瞬で失い、激しいバッシングに晒されることになります。

ここに書いてある内容は正確性に欠けているはずなので、実務に利用する場合はかならず専門家に相談してください。 記事の内容を鵜呑みにしてみなさまが不利益を被った場合、僕は一切の責任を負いませんのでご了承ください。

僕が仕事で決済システムをやるときはかならず会社の法務に相談しますし、個人で仕事を受けるときも弁護士のチェックを通してもらいます。 このへんでやらかすと社内のオペレーションが大変とかでは済まず、簡単に会社が潰れたりするので注意が必要です。

また、法令上の規制や制限は日々の運用を行う中でも重要です。 過去経験した中で最悪のパターンとしては、良かれと思ってやった作業が実は法令に違反していてやってはいけなかったっていうやつがありました。 こういう誰にとっても不幸な事故を未然に防ぐ仕組みを作るためには、やはりある程度の関連法規に関する知識が必要と言えます。

それでは、決済システムを作る際によくでてくる法律や規制について見ていきましょう。 ここで取り上げているものは一例であり、全てを網羅しているわけではありません。 提供するサービスによっては他の法令の規制を受けたりもするのでご留意ください。

特定商取引法

Webサービスないしモバイルアプリで決済システムを作る上でほぼ間違いなく避けて通れないのが特定商取引法です。 みなさんもチラっと目にすることがよくあるかと思いますが、「特定商取引法に基づく表記」はこの法律によって要請されているものです。 他にも、ECサイト等でよくある購入前の確認画面の要件や、フォームの周りにごちゃごちゃ書かれているよくある注意文言などにも基準が定められています。

定期購入（いわゆるサブスクリプションモデル）の場合は話がさらにややこしくなります。 利用規約と併せて、いつ契約が始まり、いつ契約が終わり、どの段階であらためて利用規約への同意取得が必要になるのか、みたいな話はよく整理しなくてはなりません。

遵守していない場合は行政処分⁵の対象になります。

景品表示法

二重価格問題とかでたびたび燃え上がるやつです。 過剰な割引なども規制されていますので、ECサイトや前払式支払手段を扱うサイトでは注意が必要です。

ビジネス側の人も詳しくないままに開発を依頼してきたりするので、担当する業務ドメインにおける違法行為の典型例は知っておくと良いと思います。

個人情報保護法

Webサイトのフッタ部などによくあるプライバシーポリシーの設置はこの法律によって要請されているものです。

個人情報保護法は事業者を対象としており、個人には適用されないことになっています。 ただし、課金システムを作ってお金を稼ごうというレベルになると事業をやっているとみなされ、個人情報をデータベースにもっている場合には個人情報取扱事業者と認定される可能性があります。

決済システムに特徴的な部分でいうと個人情報の第三者提供になるかなとおもいます。 Stripeのような決済代行サービスを利用しようとすると、ほとんどの場合で氏名やメールアドレスなどの情報を提供することになります。 このあたりが規制の対象となるポイントです。

ちなみに、ちょっと前まであった個人情報5,000件以下の例外規定は現在なくなっているらしいです。 個人情報保護法は頻繁に見直しがされることに加え、個人情報とは何かという点に関してはかなりふんわりした定義になっています。 実際の運用としては、経済産業省や金融庁などの行政機関が公表しているガイドライン、世論、国際情勢など大きく影響を受けます。

開発時に一度クリアしたからOKという性質のものではありませんので注意が必要です。 システム運用をする上では定期的にチェックをしなければなりません。

なお、違反すると刑事罰の対象になります。

PCI DSS

クレジットカード決済を行う際に、クレジットカード情報をどのように扱うべきかを定めたセキュリティ基準です。 クレジットカード決済を扱う場合は（ほぼ確実に）この基準を満たす必要があります。

クレジットカード情報を自社で保持するためのコストは大企業であっても安くありません。 自社が金融サービスを提供しているのでもなければ、クレジットカード情報の非保持・非通過を遵守することになるでしょう。

いずれにせよ、このセキュリティ基準を満たすためのシステム設計に関する知識・理解が必要になります。 現在はPCI DSS v3.2が発行しており、そんなに遠くない将来にv4.0にアップデートされるようです。 v4.0以降では、非通過の要件がより厳しくなるそうです。 僕が知っている範囲では、StripeやPayjpの最新のSDKはv4.0に対応しています。 よくわからんひとは、システムを作る前にこれらのサービスのドキュメントを熟読しましょう。

遵守していない場合は、おそらく加盟店契約（決済代行会社からのサービス提供）が打ち切られることになるでしょう。

まとめ

決済システムで決済をできるようにするのはちょっと慣れたエンジニアなら誰でもできるけど、 ちゃんと運用するのはすごくすごく大変だからよく考えてから作りましょう！！

エンジニアはだいたい決済周りからは逃げていたほうが幸せになれるぞ！！⁶