QR決済PJ(エリアコイン、〇〇pay)における留意点 #1

※ 本記事は、dev-pmで書いた内容の全てまたは、一部転載したものになります。（元記事：https://dev-pm.io/t-okada/items/615/）

初めまして。

私は普段ブロックチェーンの基盤を提供しているスタートアップベンチャーに所属し、そこでPMとして活動しています。PMとしてのキャリアは現在(2020年6月)まで1年半 ~ 2年程で、それまでは営業や開発など経験しました。

以前はDLT/ブロックチェーン基盤を使用したエリアコインやQR決済のサービスを中心にPMとして運営、管理を行なっていたので、今回は決済系のプロジェクトにおける抑えておくべき点やノウハウをまとめてみました。

これから決済系のプロジェクトに興味があるけど知識がない方や今後関わることがありそうな方には役立つかなと思っています。

是非参考にして頂けますと幸いです。

本記事を読んでもらいたい方

・決済系のプロジェクトに興味がある、また今後決済系PJに携わりたいと思っている方
・現在決済系のプロジェクトに携わって間もないの方
・今後決済系のプロジェクトに携わる可能性がある方
　　※既に決済系のプロジェクトの経験がある方はあまり参考にならないかと思います。

そもそも決済系のプロジェクトって他のプロジェクトと比べて大変なのか？

個人的な主観としては、結論他のプロジェクトよりもキツめではあるかな〜と思います。

もちろんこれはプロジェクトの種類、サービススコープなどにもよります。

キツめかなと思う理由としては

1. コイン発行事業者、加盟店事業者、加盟店、エンドユーザーなどユーザーの属性が多く、それぞれの管理ツールを用意しなければならない

2. 上記1の加盟店を開拓するための事業者も必要

3. 送金、決済ができないなどの障害が発生するケースが多い

4. QR決済の場合、QRコードを用意する必要あり(動的、静的)

5. 加盟店、発行体の清算の管理も必須

6. チャージ、出金のための銀行API連携やクレジットカード事業者との調整が必要

7. 上記6の銀行APIの接続におけるAPI接続チェックリスト(FISC)の遵守
決済系の法律のガイドラインの遵守(資金決済法)

などなど、基本的には上記を主にスコープ決定、スケジューリングし、ローンチ後は障害対応が必要となります。

パッと思い浮かんだ限りで箇条書きで出してみたのですが、やはりFintech領域である決済系はお金を扱うため、センシティブになりがちです。

そのため、厳重な取り扱いと遵守が必須となってきます。

特に日本では、資金決済法における法の制度が厳しく、イシュアーもある程度の規模のある企業でないと資金決済事業者の登録も厳しいのが現状です。

上記については、また別記事で詳しくかければと思うのですが、本記事ではこれらを一部抜粋して留意点を書いていければと思います。

ユーザー属性を適切に管理

前述しましたが、決済系のプロジェクトはユーザーの属性が多いです。詳しく記載しますと・・・

イシュアー(issuer)
コイン発行体事業者を指します。主にコインを発行、管理し、加盟店のための全体売上げの清算管理を行います。また半年以上サービスを継続する場合は、前払い式支払い手段や資金移動業者の登録が必要となります。

マーチャント(merchant)
加盟店 を指します。主にユーザーが実際に決済を行う際の店舗となります。イメージとしては、普段私たちが決済サービスを利用しているコンビニやスーパーなどです。
マーチャントディベロッパー、ディベロッパー(merchant developer/ developer)※ 発行体と同様になっているケースもあり
加盟店事業者を指します。主にマーチャントを管理する事業者です。イメージとしては大型ショッピングモールの各店舗を束ねている企業などです。

コンシューマー(consumer)
エンドユーザーを指します。主にその決済サービスを使用するユーザーです。
基本的には各事業者の役割を明確化し、要件定義、開発のスコープを管理し、加盟店開拓を並行して管理する必要があります。

※まだまだ要素がありますが、続きについては別記事に記載していきます。