2

私たちはフリーミアム製品を持っています。これは、毎月のサブスクリプションが支払われている場合にいくつかの機能が利用可能であることを意味します。有料でない場合は、無料の機能を引き続き利用できます。

これが私がそれを処理することを考えている方法ですが、確認したかったのです：

1) 誰かがサブスクリプションを購入すると、定期的な請求スケジュールが作成されます。

2) ユーザーはフィールド (paid_up) を「y」に設定します。

3) ユーザーが再度ログインすると、認証スクリプトは、paid_up が「y」であるかどうかをチェックします。存在する場合は、セッション トークンを作成します

4) トグルを切り替えるバッチ スクリプトが必要だと思います。それを行う方法を知りたいですか？最後に正常に処理されたクレジット カードの日付を保存しますか?

4

4 に答える 4

0

定期的な請求プロセスがあなたの側で実行するものである場合、プロセスの一部としてこれらのチェックを含めることができます。これについてアルゴリズム的に考える方法は次のようなものです。

期限が到来する顧客ごと
    にアカウントで請求を実行
    成功した場合：
        再試行を0にリセットし
        ます有料顧客としてマークします
        次のアカウントに進みますそれ以外の
    場合：
        再試行カウンターを増やします         再試行カウンターが最大に達した場合に顧客に              アラート
        を送信します：それらを無料としてマークするように切り替えます

他の何かが請求を実行して結果を通知する場合は、同じことをバッチで実行できます。「自分のアカウントで請求を実行する」を「最後の請求の試行からの結果を読み取る」に置き換えるだけです。再試行カウンターは、請求が毎日のスケジュールで実行されると仮定すると、猶予期間のようなものを実装するため、カードの有効期限が切れたなどの理由でプレミアム機能が取り消されるのではなく、請求の問題を修正する機会があります。

于 2009-04-14T17:31:45.123 に答える
0

これらのいくつかを以前に書いたことがあるので、あなたがしなければならないことがいくつかあります。

まず、他の人が述べているように、ある種のpaid_through_dateフィールドが必要です。これはいくつかの理由で重要ですが、主な理由は、たとえばサーバーがダウンした場合に柔軟性を追加し、ユーザーに追加の1日分の無料サービスを提供することを決定することです。payed_through_dateの値を1日遅らせるだけです。これにより、無料トライアルの実装も簡単になります。

次に、サブスクリプションシステムで作業している場合でも、Authorize.netの自動定期請求などを使用しないでください。支払いがいつスケジュールされるかを完全に制御する必要があり、その責任をゲートウェイにオフロードすることは、ほとんどの場合、悪い考えです。ほとんどのゲートウェイでは、サーバーにクレジットカードを保存できます。彼らはあなたにそのカードのIDを返します、そしてあなたはカード自体の代わりにその中間IDに対して料金を発行することができます。

第三に、すべてのトランザクションをログに記録します。私はこれを十分に強調することはできません。実際、おそらくこのログをユーザーにも公開する必要があります。基本的には、彼らが行ったすべての支払い、金額、および最終的な残高の表にすぎません。このテーブルにも請求書を入れるのが一般的です。請求書にはプラスの金額があり、支払いとクレジットにはマイナスの金額があり、ユーザーが最終的な残高を取得するためにすべてを合計するだけです。必要に応じて、このテーブルに任意のクレジットを簡単に導入できます。

24時間ごとに起動するcronスクリプトを実行して、請求書を生成するために必要なユーザーを確認します。このcronスクリプトには、3つの重要なプロパティが必要です。まず、何らかの理由で実行されない場合でも、1日分の料金を失うことはありません。第2に、1日に2回以上実行する場合、または途中で中止して再実行する場合は、2回請求するべきではありません。そして第3に、サーバーの日付が誤って2090に変更された場合でも、すべてのユーザーに数百万ドルの請求が自動的に行われるべきではありません。同様に、過去の日付（特に、1970年1月1日）にリセットすると、地獄が発生するはずです。私の経験では、夏時間が問題になることはめったにありません。

それは大部分のことをカバーしていると思いますが、課金システムには常に注意しなければならない落とし穴はほとんどありません。

于 2009-04-15T20:28:24.007 に答える
0

私はこれを反対側から処理し、支払い済みの日付が格納された支払い先フィールドを用意します。そうすれば、ユーザーがサブスクライブをキャンセルしても、ユーザーが行った支払いの利益を得ることができます.

于 2008-12-30T22:23:04.813 に答える
0

もちろん、「last_payment」という列を作成します。MySQL を使用している場合は、これを DATE フィールドとして作成できます。毎月の支払いを受け取るたびに、クレジット カード請求会社が Web サイトのスクリプトに何かを投稿すると思います。(つまり、paypal は IPN を送信します)。これを受け取るたびに、次のようなクエリを実行します。

UPDATE members SET `last_payment`=CURDATE() WHERE user_id='$user_id';

24 時間ごとに 1 回実行され、次のクエリを実行するスクリプトを CRON で実行することをお勧めします。

UPDATE members SET paid_up='N' WHERE DATEDIFF(CURDATE(),last_payment) > '30';

これにより、支払いが 30 日以上行われていないすべてのレコードが更新され、paid_up フィールドが N に設定されます。その後、通常のログイン コードが機能します。

CRON を使用したくない場合は、ログイン クエリを次のように変更できます。

SELECT 1 FROM members WHERE 
username='$user' AND password='$password'
AND DATEDIFF(last_payment) <= '30';

ちなみに、クレジット カード処理会社は、サブスクリプションがキャンセルされたときに POST を送信する方法を持っている場合があり、これにより、paid_up フィールドを N に設定できます。

お役に立てれば。ご不明な点がございましたら、お気軽にコメントしてください:)

于 2008-12-30T21:43:55.750 に答える