今回とある案件でオンライン決済会社のROBOT PAYMENT様の決済システム導入（コンテンツ課金）を行いましたのでサイト側の実装方法についてシェアしたいと思います。
ROBOT PAYMENT様の決済方式には「HTMLリンク接続」と「トークン方式」のふたつがありますが今回はHTMLリンク接続での決済（自動課金・商品登録あり）の実装にチャレンジしています。
今回は決済ステータスをもとにサイト側のコンテンツ制御を行いますので、ROBOT PAYMENT側から返されるキックバックパラメータを取得し、その結果に応じてサイト側のユーザー情報を書き換えるという実装が必要となります。
まず最初に決済導入の大まかな流れをご紹介したいと思います。
- ①管理画面にログインして設定を行う
- ②購入ページを実装する（フォームを設置するだけ）
- ③決済後のキックバックパラメータ取得処理を実装する
決済導入の実装時にサイト側で対応が必要となる作業は主に上記になります。
以下順番に説明をしてまいります。
目次
①管理画面にログインして設定を行う
ROBOT PAYMENTが送るキックバックパラメータを受け取るには管理画面にて以下の設定が必要になります。
- ・商品を登録する
- ・決済結果通知URL、自動課金結果通知URLを設定する
これで決済の下準備が完了しますので、あとは購入フォームの設置と通知URLの実装を進めてゆくことになります。
②購入ページを実装する（フォームを設置するだけ）
<form action="https://credit.j-payment.co.jp/gateway/payform.aspx" method="post">
<input type="hidden" name="aid" value="店舗コード">
<input type="hidden" name="pt" value="1">
<input type="hidden" name="rt" value="0">
<input type="hidden" name="iid" value="商品コード">
<input type="hidden" name="cod" value="店舗オーダー番号">
<input type="submit" name="submit" value="購入">
</form>
管理画面で登録した商品情報をもとに、サイト上に上記のような購入フォームを設置します。
購入ボタン押下後は決済会社側のページへ遷移しますので、ユーザーがそこでクレジットカード情報を入力し決済処理を行ったのち、決済会社側で設定した通知URLをGET形式の引数付きで叩いてキックバックパラメータをサイト側に引き渡すという流れです。
尚、自動決済の場合次回の自動決済が行われる度に決済通知URLが叩かれることになります。
この通知をトリガーにしてユーザー情報を更新（例えばチケット配布等）をすることで、決済アクションとコンテンツ制御を紐づけることができるでしょう。
※通常の商品購入であればこれだけで実装は完了です。
③決済後のキックバックパラメータ取得処理を実装する
以下商品登録ありの継続決済における決済通知パラメータの実装サンプルです。
初回決済通知URLにて
<?php
/* IPアドレス制限 */
if($_SERVER["REMOTE_ADDR"] == "通知元のIPアドレス"){
/* パラメータ取得 */
$gid = $_GET['gid']; // 決済番号
$rst = $_GET['rst']; // 決済結果
$ap = $_GET['ap']; // カード会社承認番号
$ec = $_GET['ec']; // エラーコード
$god = $_GET['god']; // オーダーコード
$cod = $_GET['cod']; // 店舗オーダー番号（ユーザーID）
$am = $_GET['am']; // 決済金額
$tx = $_GET['tx']; // 税金額
$sf = $_GET['sf']; // 送料
$ta = $_GET['ta']; // 合計金額
$acid = $_GET['acid']; // 自動課金番号
// 決済成功
if($rst==1){
// 決済成功時の処理
// 決済失敗
} else if($rst==2){
// 決済失敗時の処理
}
}
exit;
?>
決済後のキックバックパラメータはこのような形で取得できますので、基本的には決済が成功したか否かのパラメータを確認して制御を行うというのが基本になるものと思います。
ただサイト側でユーザーの購入履歴を出したり、後にサイト側と決済側の処理の照合を行ったりする場合を考えると、サイト側でもこのパラメータはデータとして保存しておいた方がよいかとは思います。
今回は決済履歴を格納するテーブル構成については省きますが、基本的には格納してそれがサイト側のユーザーIDと紐づいていれば問題ないものと思います。
※ちなみに今回タドワークスでは決済履歴とユーザー、商品の紐づけ情報にはサイト側で設定可能な「店舗オーダー番号」パラメータに格納するようにいたしました。
二回目以降の決済通知URLにて
<?php
/* IPアドレス制限 */
if($_SERVER["REMOTE_ADDR"] == "通知元のIPアドレス"){
/* パラメータ取得 */
$gid = $_GET['gid']; // 決済番号
$rst = $_GET['rst']; // 決済結果
$cod = $_GET['cod']; // 店舗オーダー番号（ユーザーID）
$acid = $_GET['acid']; // 自動課金番号
$am = $_GET['am']; // 決済金額
$tx = $_GET['tx']; // 税金額
$sf = $_GET['sf']; // 送料
$ec = $_GET['ec']; // エラーコード
// 決済成功
if($rst==1){
// 成功時の処理
// 自動課金停止
} else if($rst==4){
// 自動課金停止時の処理
// 決済失敗
} else if($rst==2){
// 失敗時の処理
}
}
exit;
?>
2回目以降の決済も処理としては初回決済の場合と同様ですが、送信されるパラメータの数が異なるようですのでその点は注意が必要となります。
まとめ
コンテンツ課金の決済導入というとものすごく難しく感じてしまうかもしれませんが、しくみがわかってしまえば意外とシンプルなものですね。
このフローはおそらく他の決済会社でも類似しているものと思いますので、パラメータ名などを変えることである程度流用が可能なのではないかと思います。