読者です 読者をやめる 読者になる 読者になる

アプリの課金の仕様

銀行振込について

今からアプリを作るのであれば、行わない方が良いです。

  • クレジットカードに比べて手数料が高い
  • アプリで自動化できない(振込依頼とその確認はほぼ手作業でしかできない)
  • 料金の回収まで時間がかかり、アプリ側での扱いに困る

APIでアクセスできる決済手段、具体的にはクレジットカードやPayPalが良いです。 PayPalはまあ、ドキュメント読みましょうってことなので、ここからはクレカについて書きます。

クレカの場合

クレジットカード決済をアプリに導入する場合、Payment Gateway(以下、PG)という事業者を経由して利用します。 というのは、基本的に僕ら一般人はクレジットカード各社のAPIに直接アクセスできないからです。 また、PCIDSSという、クレジットカードを扱う事業者が満たすべきセキュリティ要件の大部分を、PGが満たしてくれます。

そのPGも複数あります。おすすめは、WebPay。 理由は、「ちゃんと使えるから」です。 webpay以外のPGは、初期手数料で100万円とかだったり、そこはかとなくレガシーさが感じられるAPIだったりして、厳しさがあります。

1: 金融の世界

PGの選定が終わった後は、テスト環境を申請します。大抵、割とすぐ試験的にAPIを利用できるようになります。 アプリの開発はもうそこから開始できるのですが、テスト環境なので、実際にお金を動かすことはできません。 アプリが完成したら本番環境を申請するのですが、そこからクレジットカード会社の認可がおりるまで大変です。 クレジットカード会社の審査があり、そこで取り扱い可能な事業者として認めてもらわなければなりません。

この期間は業態によって大きく変わるようです。 例えばクラウドファウンディングは、クレカ各社非常に慎重になっているため、時間がかかると聞きます。

2: アプリケーションの世界

ここからは、課金をアプリに実装するときに考えなければならないことについて。 普通のweb/スマフォアプリでは、課金の種類が大きく分けて2つあります。

  • (臨時)課金
    • 買い切りの課金です
    • Amazonで物を買ったり、消費型アイテム課金が該当します
    • (臨時)と括弧書きしたのは、普通課金といえばこちらをさすからで、区別するための造語の意味を含みます
  • 定期課金
    • 一度登録したら、一定周期ごとに課金が実施される方式です
    • 新聞アプリの月間購読料や、Evernoteの年間プレミアム会員料が該当します
    • 定期課金にも、自動更新タイプと自動更新に限りがある(1年間など)タイプがあります

臨時課金は、決済相当額をアプリ内ポイントに変換して扱うとか、個数更新時のトランザクションに気をつけるとかくらいの難易度だと思います。 問題なのは、定期課金です。 クレジットカード決済の場合、最初にクレジットカードの有効性を検証した後に登録し、以後一定期間ごとに決済が実行されるように設定します。 WebPayの場合は「定期課金」と呼ばれるAPIで登録処理を行います。 登録時のカード有効性検証から決済実行までタイムラグがあるため、この間に何らかの理由でカードが使えなくなり、決済に失敗する可能性があります。 具体的には、以下の理由が考えられます。

  • カード紛失による利用停止申請
  • カードの有効期限切れ
  • 決済時の与信枠が不足
  • 誤検知で不正利用と認識され決済却下
  • カード会社、あるいはPGのシステムトラブル

決済が成功すれば良いのですが、失敗した場合は、アプリケーションの挙動を変える必要があります。 会員制サイトであれば、購読権を剥奪するとか、強制退会させる、などが考えられます。 また、決済失敗後の挙動だけでなく、決済失敗後のリトライ(失敗した決済の再試行)と、そのリトライが成功/失敗したときの挙動も検討しなければなりません。 単にアプリケーションでのエラーハンドリングを超えて、そのビジネスが顧客にどう向き合うかというスタンスをはっきりさせなければならないもので、仕様・実装ともに非常に気を使うべき処理です。

3: 経理の世界

クラウドファウンディングの場合限定かもしれませんが、お金を右から左に動かす場合、経理担当者の事情も考慮する必要があります。 例えば以下の日程で月次の決済処理をスケジュールしたとします。

  • 毎月2日 クレジットカード決済実施(1回目)
  • 毎月10日 1回目の決済に失敗した場合の再試行(2回目)
  • 毎月20日 2回目の決済に失敗した場合の再試行(3回目)
  • 毎月末日 決済額をファンディングの成果として振込

実際は現金を会社の口座に集めなければならないため、その経理処理の期限が存在する場合、以下のように仮定して実装するかもしれません、

  • 毎月2日 クレジットカード決済実施(1回目)
  • 毎月10日 1回目の決済に失敗した場合の再試行(2回目)
  • 毎月15日 当月末に振り込む経理処理の期限
  • 毎月20日 2回目の決済に失敗した場合の再試行(3回目)
  • 毎月末日 決済額をファンディングの成果として振込
  • 翌月末日 3回目の決済で成功した金額を「前月繰り越し分」として扱い、翌月分とあわせて振込

もちろんここらへんの期日は、組織によって異なります。 そういった変更の可能性を考慮しないで進めた場合、利用規約の見直しや、各ユーザの仕様変更が必要になるかもしれません。

まとめ

金銭が直接関わるシステムの場合、アプリ(ビジネスロジック)、金融(クレカ)、経理(会社)の要件をうまい具合にすりあわせて仕様を決めないといけない、ということを知りました。