今回とある案件でオンライン決済会社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が叩かれることになります。
この通知をトリガーにしてユーザー情報を更新（例えばチケット配布等）をすることで、決済アクションとコンテンツ制御を紐づけることができるでしょう。
「店舗オーダー番号」には、ユーザーと商品をサイト側で特定するために、[ユーザーID]_[商品ID]などを設定しておくとサイト側での処理に便利です。
※コンテンツ課金でもポイント購入など継続課金ではなく初回決済のみで済む実装であれば難易度が相当低いと思いますが、やはり継続課金は魅力ですよね。
③決済後のキックバックパラメータ取得処理を実装する
以下商品登録ありの継続決済における決済通知パラメータの実装サンプルです。
初回決済通知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']; // 店舗オーダー番号
$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']; // 店舗オーダー番号
$acid = $_GET['acid']; // 自動課金番号
$am = $_GET['am']; // 決済金額
$tx = $_GET['tx']; // 税金額
$sf = $_GET['sf']; // 送料
// 決済成功
if($rst==1){
// 成功時の処理（パラメータをデータベースに入れる際はam、tx、sfはNULL値を許容する必要あり）
// 自動課金停止
} else if($rst==4){
// 自動課金停止時の処理
// 決済失敗、または、お試し終了後決済失敗
} else if($rst==2 || $rst==5){
// 失敗時の処理
}
}
exit;
?>
2回目以降の決済も処理としては初回決済の場合と同様ですが、送信されるパラメータの数が異なるようですのでその点は注意が必要となります。
尚パラメータのam、tx、sfの3つは場合によってNULL値を渡されますので、パラメータをデータベース側に格納する際にはこの3つのみNULL値を許容する必要があります。
また複数サイトで同じ決済を使用している場合は他のサイトの決済のキックバックパラメータを受信してしまう恐れがございますので、codパラメータに商品IDなどを登録して対象サイト以外の商品の処理をしないようブロックするといった対応も必要になります。
まとめ
コンテンツ課金の決済導入というとものすごく難しく感じてしまうかもしれませんが、しくみがわかってしまえば意外とシンプルなものですね。
このフローはおそらく他の決済会社でも類似しているものと思いますので、パラメータ名などを変えることである程度流用が可能なのではないかと思います。