私たちは、過去 1 年間開発されてきた大規模な Web アプリケーションのリリースに向けて準備を進めています。サービスの定期的なサブスクリプション料金を処理するために ActiveMerchant を統合するプロセスを開始しようとしています。
私たちの要件 (以下にリスト) を考慮したベスト プラクティスに関するアドバイス、およびよくある落とし穴や特別な考慮が必要な特定の問題に関する追加のヘッドアップについて、アドバイスを求めています。使用する支払いゲートウェイはPaymentExpressです。これは、定期請求があり、米国外で事業を行う企業にとって特別な条件がない、サポートされている数少ないゲートウェイの 1 つです。このアプリケーションの背後にあるビジネスは、英国を拠点としています。
アプリケーションのユーザーは、アプリケーションとそのデータにアクセスしてカスタマイズできるサブドメインでアカウントを作成します。請求の仕組みに影響を与える可能性のある要件/機能の一部を以下に示します。
- すべてのユーザーが 30 日間の試用を利用できます
- 無料プランなど様々なプランあり
- より高い価格のプランでは、アカウントに保持できるデータ (ユーザー、プロジェクトなど) の量に大きな制限があります。
- 請求期間は月単位で、試用後に開始されます
- プランなどで、通常価格から 1 年間割引される割引 / クーポン コードがあります。
- 機能が追加されると、プランの価格が変更されます
私が予測できる具体的なハードルは、次のようなものです。
- 下位レベルのプランのプラン制限に違反した場合のダウングレードの処理方法。
- クレジット カードの有効期限が切れた場合や支払いが完了しなかった場合の動作 (読み取り専用モードが強制されている可能性があります)
- プランの価格が変更された場合、既存のユーザーに対して一定期間 (6 か月など) 以前の価格を適用し、その後、より高い料金の請求を開始したいと考えています。プラン価格が下がった場合は、すぐに有効になります。
役立つその他のアドバイスは、アプリケーションの流れに関するものです。請求フォームはユーザーにどのように提示する必要がありますか? クレジットカード情報が必要になるのはいつですか? 請求書はどのように送信、保管、およびアクセスする必要がありますか?
多くのコード ベースをSaaSyに基づいて作成する予定であることを明らかにしておく必要があります。SaaSy は、すべてのサインアップとアカウント管理の側面を処理する別の Rails アプリとして使用するように設計されています。ただし、最初からこれを計画したことはなく、そのように動作するようにアプリケーションを適応させるのは面倒なプロセスになるため、これはうまくいきません。その結果、SaaSy からコードとアイデアを取得してアプリにマージします。