Skip to main content

顧客への課金

GitHub Marketplace上のアプリケーションは、GitHubの課金ガイドラインと、推奨サービスのサポートを遵守しなければなりません。 弊社のガイドラインに従うことで、顧客は予想外のことなく支払いプロセスを進んで行きやすくなります。

Note

この記事は、GitHub Marketplace でのアプリの公開にのみ適用されます。 GitHub Marketplace での GitHub Actions の公開について詳しくは、「GitHub Marketplaceでのアクションの公開」をご覧ください。

支払いを理解する

顧客は、アプリケーションの購入時に月次あるいは年次の支払いサイクルを選択できます。 顧客が請求期間やプランの選択を変更した場合は、常に marketplace_purchase イベントがトリガーされます。 marketplace_purchase Webhook ペイロードを参照すると、顧客が選んだ請求期間と、次の請求日がいつ始まるかを確認できます (effective_date)。 Webhook ペイロードの詳細については、「GitHub Marketplace APIのためのwebhookイベント」を参照してください。

アプリケーションのUIにおける支払いサービスの提供

アプリケーションのWebサイトからは、顧客が以下のアクションを行えなければなりません。

  • 顧客は、個人とOrganizationのアカウントで別々にGitHub Marketplaceのプランを変更したり、キャンセルしたりできなければなりません。
  • GitHub Marketplaceから購入した有料プランをキャンセルした顧客は、そのアプリケーションに無料プランがあれば自動的にダウングレードされなければなりません。 顧客がGitHub Marketplaceのサブスクリプションをキャンセルした場合、GitHubは自動的にアプリケーションをアンインストールしないので、顧客は無料の機能を使い続けられることが期待できます。 顧客は以前のプランを再度有効にできるようにすることが強く推奨されます。
  • 次の形式でアップグレード URL を指定すると、顧客はアプリのユーザー インターフェイスからアップグレードできるようになります。https://www.github.com/marketplace/<LISTING_NAME>/upgrade/<LISTING_PLAN_NUMBER>/<CUSTOMER_ACCOUNT_ID>
  • シート(ユニット単位の価格プラン)もしくは無制限のコラボレーターを提供するプランを購入した場合、どのユーザがアプリケーションにアクセスできるかを、顧客がアプリケーションのWebサイトから変更できるようにするべきです。
  • 以下の変更は、顧客が自分のアカウントで、アプリケーションのWebサイトの支払い、プロフィール、もしくはアカウント設定のセクションにおいてすぐに見ることができるようになっているべきです。
    • 現在のプランと価格。
    • 購入された新しいプラン。
    • アップグレード、ダウングレード、キャンセル、無料トライアルの残り日数。
    • 支払いサイクルの変更(月または年単位)。
    • 定額及びユニット単位のプランの利用状況と残りのリソース。 たとえば、価格プランがユニット単位であれば、アプリケーションのサイトは使用されたユニットと使用可能なユニットを表示すべきです。

アップグレード、ダウングレード、キャンセルのための支払いサービス

明確で一貫性のある支払いプロセスを保つために、アップグレード、ダウングレード、キャンセルについて以下のガイドラインに従ってください。 GitHub Marketplace 購入イベントの詳細な手順については、「アプリケーション内でのGitHub marketplace APIの使用」を参照してください。

marketplace_purchase Webhook の effective_date キーを使うと、プランの変更がいつ発生するかを判断し、プランのアカウントの一覧表示を定期的に同期することができます。

アップグレード

顧客が価格プランをアップグレードしたり、月次から年次へ支払いサイクルを変更したりした場合、その変更をすぐに有効にしなければなりません。 新しいプランに対して日割引を適用し、支払いサイクルを変更しなければなりません。

顧客がプランをアップグレードし、支払いに失敗した場合、GitHub はその顧客の GitHub Marketplace サブスクリプションを以前の状態に戻します。 また、GitHub はその顧客に対して失敗を知らせ、購入をもう一度試みることができるよう、メールを送ります。 以前のプランに戻すように要求する changed アクションを含む Webhook を受け取ります。

アップグレードとダウングレードのワークフローをアプリに組み込む方法については、「プラン変更の処理」を参照してください。

ダウングレードとキャンセル

ダウングレードは、顧客がFreeプランから有料プランに移行し、現在のプランよりも低コストなプランを選択するか、支払いサイクルを年次から月次に変更した場合に生じます。 ダウングレードもしくはキャンセルが生じた場合、返金は必要ありません。 その代わりに、現在のプランは現在の支払いサイクルの最終日まで有効です。 顧客の次の請求期間が始まる時点で、新しいプランが有効になると、marketplace_purchase イベントが送信されます。

顧客がプランをキャンセルした場合、以下を行わなければなりません。

  • Freeプランがある場合には、自動的にFreeプランにダウングレードします。

    顧客がGitHub Marketplaceのサブスクリプションをキャンセルした場合、GitHubは自動的にアプリケーションをアンインストールしないので、顧客は無料の機能を使い続けられることが期待できます。

  • 顧客が後でプランを継続したくなった場合には、GitHubを通じてプランをアップグレードできるようにします。

キャンセル ワークフローをアプリに組み込む方法については、「プランのキャンセルの処理」を参照してください。