決済代行サービスについて

新しい案件依頼に決済機能がほしいとの要件があった。しかもサブスク。自前で決済機能を用意するのは難しそう。なので決済代行サービスを上手く利用したい。今のところ決済代行サービスについてはほとんど分かっていない。Wordpressでお手軽に実装できることは知っているが。
難しければ案件を断ればいいし、気軽に決済サービスについて調べていこう。

さっそく、「決済代行サービス API」で検索すると「Gateway(APIゲートウェイ)」という見知らぬ言葉が出てきた。
"APIゲートウェイとは、APIの管理や実行を容易にするしくみ"とある。CURLとCORSなのだろうか？またはそれ以外の方法か？

APIゲートウェイとは

例えばクライアントが決済サービス、メール通知、レコメンド機能の３つのAPIを利用している場合、クライアントは合計３回の通信が必要である。しかしAPIゲートウェイを利用すると、クライアントは１回の通信で済むという。クライアントは細かなところを気にする必要ない。APIゲートウェイ側で全部やってくれる。 APIゲートウェイとは"技術"というよりも"サービス"と呼んだほうがふさわしい。技術用語でなくビジネス用語の部類なのだろう。
決済代行である場合、APIを指してゲートウェイ方式と読んでいるところもあるようだ。それに対になる言葉はおそらくリンク方式なのかもしれない。

API Gatewayで検索すると「Amazon API Gateway」が検索結果に多くあらわれる。またREST APIというワードも見かける。
REST API、つまりCORSの技術を利用しているのだろう。となるとトークン、秘密キー、公開キーなどとも関係があるのだろうな。
AmazonのAWSは"s3"など、それっぽいサービスをたくさん提供している印象がある。使ったことはないが。
結論としてシステムエンジニアからすれば、API GatewayはただのAPIに１つにすぎないということだ。たぶんだけど。

決済代行サービス会社は多い

しかし、「決済代行サービス」というワードで検索すると広告サイトの多いこと。これは競争の激しいサービスであることを物語っている。どこの決済代行サービスをつかうか比較しなければならないということだ。お金がらみなので信用が第一だ。バックにいる企業の知名度は重要になるだろう。

決済代行サービスの技術的な仕組み

どこでもいいので、決済代行サービスの技術的な導入方法を知りたい。「決済代行サービス JavaScript」でググる。それでも広告が多いが、ゼウスという決済サービスサイトに技術的情報が書かれていた。(なお、私はゼウスなる会社のまわしものにあらず。たまたま見つけただけ)
サイトを見回すと以下の情報を見つけた。

	事業者側サイトにて決済情報（カード番号、有効期限など）を入力いただき、ゼウス提供のJavaScriptプログラムにて決済処理
	指定URLに必要情報（パラメータ）を送信
	受注システム連携：レスポンス取得、CGI送信
	メールによる決済結果通知
	レスポンス取得
	CGI送信による結果パラメータ受信

CGIという言葉を久しぶりに聞いた。CORSやCURLでパラメータ送信ということだろう。
パラメータはカード番号とその有効期限である。
メールによる決済通知とあるがこれは多分クライアントへのメール通知であり、一般客へメールするわけではないのかもしれない。一般客へは、クライアント側でメール通知しないといけないのかもしれない。レスポンスは決済成功かどうかの情報であることが推測される。
当たり前であるが一般客情報はクライアント側のシステムで管理しないといけない。しかしカード番号や有効期限をデータベースで管理する必要はないだろう。こういう大切な情報は保持するだけでリスクである。お金を払ったかどうか、これだけをデータベースで管理すればよいだろう。
言葉選びが開発者向きだ。ゼウスの開発者には親近感がもてる。
一応、クレジットカード支払いだけの対応なのかな。クレジットカード以外の支払いも可能なのだろうか。

他の決済代行サービスの情報も見てみる。大手のGMOを調べてみよう。
テスト環境などもあるらしいが技術の資料請求せよとのこと。まあ、予想はつくので資料までは見る必要もあるまい。
支払い方法はクレジットカード以外にもたくさんあるようだ。
接続方式つまり情報のやり取り方法はリンクタイプPlus,リンクタイプ、モジュールタイプ、プロトコルタイプがある。

リンクタイプ系はURLにパラメータをセットする方式かな。支払いのレスポンスはどのようになっているのだろうか。

モジュールタイプ、これはPHPのモジュールのことを指しているのかもしれない。PHPモジュールの方法はパラメータにもよるが難しそうに見えて意外と簡単だ。

プロトコルタイプ、これは通信プロトコルのことを指しているのかもしれない。HTTPSプロトコルならRESTとCORSだろう。 SSHプロトコルもありうる。使わないけど。

結論としては考えることが多い。つまり開発者の作業量が増えるということだ。GMO決済サービスを利用するなら見積もり工数を多めにしようかな。

サブスクリプションについて考える

さて、今回の案件依頼はサブスクリプション、いわゆるサブスクだ。サブスクは2021年からおおいに流行っている。しかし、私はサブスクが嫌いであまり利用していない。利用しているのはGoogle Driveの容量増加サービスくらい(月額250円）。
まあ、ここで重要なのは解約するまで自動的にお金を定期的に支払い続ける仕組みになっているということだ。普通の決済代行サービスでは一回限りの支払いだが、サブスクは毎月あるいは毎年と定期的に自動支払いをする。取引の仕方が違う。つまり決済サービスもサブスクに対応したサービス会社を探さねばならないというとうことだ。
技術的にも1回支払いのパラメータとは異なるだろうし、毎月、毎年の支払いチェックも必要になってくるのかもしれない。うーん想像するだけで頭がいたい。

サブスク決済に対応する会社について

「ROBOT PAYMENT」とかいう会社が出てきた。顧客データベースなんかも用意しているらしい。しかし、サイト情報だけでは詳しい技術が不明。説明がアバウトすぎてよく分からない。
詳細は資料請求しないといけないようだ。作業を増えそうなので次の会社を探そう。

上記にもでてきたゼウスがまた出てきた。サブスクリプション決済にも対応しているらしい。なかなか優秀だなこの会社。以下の２種類の方法があるようだ。

ゼウスの売上管理画面による継続課金（定期課金）システム

システムへの組み込みが容易になることが想像できる。問題は自動支払いかどうかだ。一般客が毎月手動で支払いというものでは意味がない。

気になる情報が。

A.  API連携で毎月自動で決済をあげることはできますか？

Q. 
いいえ、毎月請求データを登録する必要がございます。
毎月、事業者様にて”追加”で決済をあげていただく仕様の継続的な決済となります。
月2回の請求や、隔月での請求など、事業者様の運用に合わせてご利用いただけます。
もし毎月自動での決済をご希望場合は、定期購入機能に対応したショッピングカートや毎月自動的にバッチ処理を行う仕組みを構築いただくことで、対応が可能となります。

どうしようこれ。一般客が支払い手続きするのでなく、クライアント側の担当者が毎月請求手続きをするということになっている。
手動なので担当者の目でしっかりと確認できるというメリットもある。というか実際の運用ではお金の流れを担当者が管理しておく必要もあるだろう。

クライアントのサービスシステムに組み込む場合を考えて見る。
クライアントの担当者が手動でゼウスの売上管理画面で一般客の支払い状況を確認し、支払いがなされていたらその客のサービスシステム利用を継続、支払いされないのであれば担当者は手動で利用停止するという流れになるのだろう。

運用はシンプルになるので開発コストは安くすむ。目視でお金をチェックできるのも良い。しかし、担当者の仕事が増えるのはデメリットであろう。
とはいえCSVに対応している。CSVファイルで一括作業も可能、つまり担当者の工夫次第で時短できるということだ。これならクライアントの負担も軽減できる。すばらしい。この方法は第一候補だな。
問題点
テスト環境を用意するのがたいへんんそうだ。自分のクレジットカードやデビッドカードでなんとかするしかないか。いろいろ考えないと。
クライアント向けのテスト環境も必要だろう。
クレジットカード番号変更もできるととはあるが、この辺も気になるところだ。

ゼウスのAPI連携・バッチ処理での継続課金（定期課金）システム

バッチ処理を行うとのこと。バッチ処理はゼウス側で行うのだろうか？
そうみたいだ。クレジットカード情報はゼウス側で保持管理してくれるというので安心。

初回決済と継続決済に分けて考えられている。初回決済は、まあ初回のクレジットカードとかだな。そう難しくはあるまい。リンク型、トークン型(JavaScript)、API型、メールリンク型などいろいろなパターンが用意されている。

継続決済はクライアントのデータベース、ゼウスデータベース、クレジットカード会社の３つのデータベース間で処理が行われているようだ。開発者からしてみればクライアントのデータベースとゼウスデータベースだけを考えればよい。ゼウスデータベースでは会員ＩＤがユニークＩＤとして扱われている。クライアントデータベースでもゼウス会員ＩＤなるものを用意すべきだな。クライアントのシステムから請求データをゼウスのシステムに送らねばならないようだ。請求データ送る方法は何だろうか。送信データ件数にも制限とかありそうだ。図解を見る限り決済結果はクレジットカード会社から送られてくるように見える。これはちょっと問題だ。クレジットカード会社とのやりとりまでは考えたくない。

資料を見る

資料請求するとしばらくて資料サイトへの案内メールが届いた。 PDF資料か。ビジネス的なことが書いてあり、技術的な事柄は書かれていない。サブスクの場合、クライアント側の審査が必要のようだ。

調査の終わりに

クライアントにはゼウスを紹介しようかな。ビジネスには疎いのでよく分からないが、ゼウスのバックにはソフトバンクがいるような感じだし信頼性も高かろう。
料金形態が複雑なので私のほうから説明することは不可能であることも伝えるべきだろう。あと審査もあることも伝えよう。
さて今回、依頼案件、受注できるかなー。余裕はあるので無理して受注することもない。

おまけ Paypal

Paypalも知名度があるので調べてみることにした。しかし、開発者向けのサイトがセキュリティソフトにより警告される。何が起きている？
古い記事だが参考サイトもあった。サブスクのではなさげだけど。→ PayPal 決済の実装方法

導入

技術資料 https://www.cardservice.co.jp/guide/set.html
https://www.cardservice.co.jp/zmc/manual/system.html

決済代行サービスについて | ワクガンス

導入