個人プロジェクトとして、LOSLESというオープンソースの決済処理システムを作って公開しました。
このプロジェクトの中核となるアイデアは、「口座振込の検知 + 金額そのものを注文IDのように使う」というものです。
一般的な口座振込決済は、通常次のような流れをたどります。
- PG事業者への登録
- 事業者登録
- 審査
- API連携
- 決済手数料の発生
- 精算待ち
個人開発者や小規模プロジェクトにとっては、かなり負担になることが少なくありません。
そこで、「金額だけで注文を識別できないだろうか？」という発想から作ることになりました。
たとえば商品の価格が10,000ウォンだとすると、
最初の注文:
10,000ウォン
30分以内の同じ商品の2件目の注文:
9,999ウォン
3件目の注文:
9,998ウォン
4件目の注文:
9,997ウォン
...
このように、注文ごとに固有の金額を割り当てます。
（実際の実装では99ウォンから始めて、98ウォン、97ウォン、96ウォン... という形で割引額を差し引きます）
そのためサーバーは、別途注文番号を入力しなくても、金額を見るだけでどの注文かを識別できます。
LOSLES Android Appは、カカオペイのチャージ通知を検知して外部サーバーへ自動送信する役割を担います。
Androidの通知アクセス権限（Notification Listener）を利用してカカオトーク・カカオペイアプリの通知をリアルタイムで監視し、
チャージ金額を含む通知を受信すると、その金額を抽出して設定されたサーバーURLへPOSTリクエストを送信します。
LOSLES WEB Serverとあわせて使うことで、ユーザーの入金から決済完了処理までの流れを自動化できます。
全体のフロー
- ユーザーが注文を作成
- サーバーが固有の金額を割り当て
- ユーザーがその金額で口座振込（現在はカカオペイのみ対応）
- Androidアプリがチャージ通知を検知
- 金額をサーバーへ送信
- サーバーが金額と注文をマッチング
- 自動で決済完了処理
つまり、
「誰が送ったか」ではなく
「いくら送ったか」を基準に決済を識別します。
注意事項
重要なのは、LOSLESが公式なPGを置き換えることを目指したプロジェクトではないという点です。
大規模サービスでは、PG事業者が提供する返金、精算、領収書、紛争対応、セキュリティ機能が依然として重要です。
ただし、個人プロジェクトや小規模なデジタルコンテンツ販売においては、
「決済を受けるために事業者登録から始めてPG審査まで受けなければならない状況」
を過剰だと感じ、
その手続きを経ずに自動決済を実装できる方法を実験してみたプロジェクトです。
現在はベータ版で、フィードバックを受け付けています。
特に以下の点について意見を聞きたいです。
- 金額ベースの識別方式の問題点
- 重複注文の処理方法
- セキュリティ改善のアイデア
- 実運用経験のある方の意見
ありがとうございます。
7件のコメント
問題点にはとても共感するのですが、ソリューションは少し曖昧な気がします。ほかはさておき、うまくいったとしてもほとんど機能しなくなるはずです。注文しておいて実際には決済しない人もとても多いですし、そうなると99円を後で再利用しなければならないのですが、重複して入金されると非常に厄介になります。
Gumroad のようなものが本当に必要だと思います。私も何か簡単なものに決済を付けようとすると本当に大変なので、間違いなくソリューションが必要だと思います。暗号資産取引所では入金ノートを使っていますが、それだけでも自動入力できればかなり便利そうなんですけどね。
例えば、キムチチゲもテンジャンチゲも10,000ウォンの店で10,000ウォンの注文が入ったとき、それがどのメニューの注文なのかは区別できないということですか？
同一価格の別商品についても、割引額を1ウォンずつ変える必要があります。実際に利用する際は、LosLesサーバーに商品を登録するのではなく、商品の定価を見て自動的に割引額を変えてくれます。
では、同じ商品をずっと違う価格で売り続けなければならないんですか？
半分は合っていて、半分は違います。定価が1万円であることは同じですが、
30分以内の最初の決済リクエストは99ウォン割引、
30分以内の2回目の決済リクエストは98ウォン割引、という形です。本文でうまく伝えられていなかったようですね。
顧客が誤って違う金額を送ると、マッチングが崩れてしまいそうですね。
それが最大の欠点ではあります。
手動でDMで問い合わせできる程度の小規模 プロジェクトなら問題ありませんが、大企業ではPG社と契約してから使うのがよさそうですね