3

Zend Framework を使用して php で有料会員サイトを構築しています。ユーザーに課金するためのワークフローを考え出す必要があります。さまざまなレベルのサービスを提供する多数の月額パッケージがあります。例:

1つのワークスペースと1人のユーザーを作成できる無料プラン

5 つのワークスペースと 3 人のユーザーを作成でき、月額 15 ドルの Basic プラン

20 個のワークスペースと 10 人のユーザーを作成でき、月額 35 ドルのプレミアム プラン

50 のワークスペースと 30 のユーザーを作成でき、月額 65 ドルのヘビー デューティー プラン

今のところ、AlertPay のようなサードパーティのゲートウェイと統合する可能性が高いですが、パッケージは月単位で、申し訳ありませんが、これまでのところ、月単位のメンバーシップ サービス サイトに実際にサインアップしたことはありません。毎月のユーザー。

クレジットカードの詳細を毎月入力するように主張しますか、それとも実際に一度詳細を尋ねてから毎月請求しますか - 正直なところ、後者が考慮されるとは思えません。

または、ユーザーは使用したい月数に対して前払いしますか? 通常はどのように行われますか?

また、サインアップ時にすべての有料パッケージの 10 日間無料トライアルをユーザーに提供したいと考えています。これをコードにどのように実装しますか。私は自分のアプリケーションをセットアップし、すべてのユーザーが管理者であるかのように機能しています。つまり、何も保持していないため、収益化するために制限を組み込みたいと考えていますが、これを行うためのワークフローとコードの実装とデータ設計について少し迷っています.

アプリケーションにプラグインし、サイトのこの側面を処理するために使用できるオンライン サービスまたはオープン ソース アプリケーションはありますか?

更新 =========================

非常に包括的な回答ですが、開発レベルでは、データベースに何を保存する必要があり、必要なテーブルをどのように設計しますか。毎月のサブスクリプションの場合、毎月、私がゲートウェイに提供する URL に対してポストバックが行われることを理解していません。ここでのデータベースの必須要素は何でしょうか。

4

2 に答える 2

1

さて、あなたは2つの質問をしています。

毎月ユーザーにどのように段階的に請求しますか?

あなたが探しているのは定期的な支払いです。ほとんどの支払いゲートウェイはそのようなオプションを提供しています (Paypal は提供しています)。基本的に、クレジット カード情報を安全なデータベースに保存し、毎日 cron を実行して定期的なプロファイルをチェックし、承認を求めます。ただし、実際には自分で行うことはお勧めしません。それは困難であり、ほとんどの国では何らかの形で違法です. (CC 番号を自分で保存することはできません)。

一部の Web サイトでは、 nか月に1 回料金が請求されますが、ユーザーの観点から言えば、それを恐れている可能性があります。

これをコードにどのように実装しますか?

Zend Frameworkには、アクセス制御リストZend_Aclの作成に役立つコンポーネント ( ) が付属しています。

できることは、サブスクリプション タイプごとに 1 つの「ロール」を作成し、それぞれが異なるリソースに対して異なる権限を持つことです。

MoSCOW 法を知っている場合は、なんとなく似ています。

  • (役割)フリープランで(権限)登録できる(リソース)Webサイト。
  • (ロール)基本プランでは、(権限)5つの(リソース)ワークスペースを作成できます。
    等

ほとんどの場合、役割を継承する方法について、一種の特権エスカレーションがあることに注意してください。

分離して、リソースを見つける必要があります。リソースは、必要なものであれば何でもかまいません。動的で、その場で作成することもできます。

アサーションを使用すると、役割ごとのワークスペースの数を制限できるはずです。

Class WorkspaceCountAssertion {

    const MAX_WORKSPACE = 5;

    public function assert(Zend_Acl $acl,
                           Zend_Acl_Role_Interface $role = null,
                           Zend_Acl_Resource_Interface $resource = null,
                           $privilege = null)
    {
        //retrieve the current workspace count
        if ($workspaceCount > self::MAX_WORKSPACE) {
            return false;
        }

        return true;
    }
}

$acl->allow('basic', 'workspace', 'create', new WorkspaceCountAssertion());

それはあなたにアイデアを与えます。

ユーザー、コントローラーなどの用語を使用したことがないことに注意してください。実際には、ロール、リソース、特権の観点から考える必要があります。

単純な多対 1 の関係で、関連付けられたアカウントと共にロールを保存する必要があります。
各アカウントは 1 つのロールを持つことができます。支払いが停止したときにこれを更新するにはどうすればよいですか? 場合によりますが、ほとんどの場合、支払いゲートウェイに応じて、サブスクリプションの終了を確認し、定期的な支払いを確認する cron を実行する必要があります。結果のトランザクションをポストバックするか、Web サービスで直接返します。支払いが失敗したか拒否された場合は、ロールを無料アカウントに戻すことができます。

これを行う方法はいくつかありますが、アプリケーションと要件によって異なります。

月ごとのサブスクリプションを保存したり、リンクされたアカウント/サブスクリプションの行を更新したりすることができます。

于 2011-04-03T20:45:40.033 に答える
0

ほとんどの支払いゲートウェイは、サブスクリプションを管理し、ポストバック メカニズムを介してサイトに通知します。すなわち、

  1. ユーザーがサイトにアクセス
  2. ユーザーはあなたのサイトで購読料を支払います
  3. ユーザーは、自分自身または支払いゲートウェイ (ゲートウェイによって異なります) によってホストされている支払いフォームにリダイレクトされます。
  4. ユーザーがフォームにクレジット カード情報を入力すると、支払いゲートウェイに送信されます。
  5. 支払いゲートウェイがサブスクリプションを開始し、ポストバックを介して (バックグラウンドで) サイトに通知します。
  6. ユーザーの支払いフォームがローカルでホストされていて、送信を支払いゲートウェイに投稿するだけか、支払いゲートウェイがフォームを処理しているかに応じて、ユーザーを成功/失敗ページにリダイレクトするか、単にリダイレクトする必要がある場合があります。適切な応答を表示します。

サブスクリプションの変更、つまり、再請求、キャンセル、チャージバックが発生すると、支払いゲートウェイは別のポストバックを開始して、新しいイベントを知らせます。アプリケーションは、ユーザーのステータスを適切に更新する責任があります。

これはかなり一般的な情報ですが、ほとんどの支払いゲートウェイが従う手順はおおよそです.

于 2011-04-03T20:32:07.050 に答える