また、バナー広告やコンテンツ広告の支払いの形だけでなく、訪問者からのお金の形でもあります。
彼らが何を提供するかは関係ありません-アバターに対するクールな特殊効果、プロジェクトのシンボルが入ったTシャツ、またはサイトの最初の美しさのプライベートメッセージへのアクセス。 どうやって支払いを受けるかが重要です。 そして、ユーザーが苦労して稼いだお金を使うように心を変えるまで、すぐに望ましいことです。
このような制限により、Sberbankで領収書に記入する支払い方法のリストからすぐに削除されます。 はい、これもメソッドですが、メソッドは高速ではありません。 特に、中庭が夕方遅くになると、ユーザーはお茶
そもそも、多かれ少なかれ即時支払いの受け取りを整理する方法は何ですか？ 個人的に、私は3つを同時に思いついた。
- SMS
- プラスチックカード
- 電子マネー
SMSによる支払いは大きな手数料ですが、ほとんどすべてのユーザーが携帯電話を持っています。
プラスチックカードは普及していません（はい、はい、デフォルトシティの居住者、MKAD以外にも支払いの準備ができている生活があります！）、しかし手数料は最小限です。
電子マネー -さまざまなシステム、接続の技術的および法的困難がたくさんありますが、聴衆は大勢です！ そして、補充する方法！
この記事の最初の2つの方法については説明せずに、サイトでの電子通貨の受け取りの整理についてお話したいと思います。 WebMoney 、 Yandex.Money 、 Money Mail.Ruなど。 それぞれのケースでの作業の実装は気になりません。これらの支払いシステム（PS）のドキュメント、およびさまざまな種類の成功事例と失敗事例でこれについて読むことができます。
記事を読んだ後に起こるべき主なアイデアは（そして、それが起こることを願っています）、支払い受け入れシステムを正しく設計すれば、各新しいシステムを接続することは難しくないということです。
すぐに予約します。以降、「アカウント」の下で、 アカウントではなく請求書を理解します 。 便宜上、支払いに関する情報を含むユーザーのアカウント、ユーザーの支払い残高などのサイズ、および何かの支払いの請求書と混同しないように、後者は「注文」または「注文」と呼ばれます。
一般に、私がたまたま出会った支払いシステムは2つのタイプに分けられます。
- 支払いの事実について販売者に独立して通知する（通常、事前に合意したURLにバックグラウンドでデータを送信することにより）
- 支払い状況についてインタビューする必要があるシステム。
したがって、2番目についてお話しましょう。
売り手の観点からそのようなシステムを操作するための典型的なシナリオは次のようになります。
- 支払いプロセスのユーザー初期化、支払い用のアプリケーションの保存
- 請求データに基づいてアプリケーションを生成し、秘密鍵または証明書でアプリケーションに署名する
- 支払いシステムにデータを送信し、会計システムで注文番号を受信する
- この番号をシステムに保存する
- この注文のステータスの変化に関する支払いシステムの調査
- システム内のアプリケーションのステータスを変更し、ユーザーにサービスを提供する
支払いについて話しているので、ユーザーの支払い/アプリケーションのアカウントに何らかの請求が必要になることは明らかです。 それはarbitrarily意的に複雑でも単純でもよく、私たちにとっては「ブラックボックス」でもかまいません。必要なのは、アプリケーションの量とその数の2つだけです。
この番号が一意である理由を具体的に議論すべきではないと思いますよね？
請求からの残りのデータ（サービスのテキストによる説明など）はオプションです。
正しく請求書を書く方法は、記事グループ全体のスピーチであるため、今は彼についてではありません。
ご希望の方は誰でも、請求に関する質問は、私宛にまたはメールでお願いできます。
それでは、一般的なアーキテクチャから始めましょう。
奇妙なことではないように、説明されたシナリオによる支払い受付システムアーキテクチャのレシピは非常に単純です。 必要なもの：
注文キュー-1個
キュー処理ディスパッチャ-1個
アプリケーションでの作業の一般的なライブラリ-1個
一般的なWebインターフェイスライブラリ-1個
支払いシステムを使用した作業の一般的なライブラリ-1個
特定の支払いシステムでの作業のライブラリ-システムの数ごとのN個。
次に、各パーツについて詳しく説明します。
1.アプリケーションキューとは何ですか？
すべてがシンプルです-これは、さまざまなステータスのアプリケーションのテーブルです（最も単純な概算では、「有料」、「未払い」、「処理中」）。 アプリケーションに関する情報を保存するため、および処理のためにどのアプリケーションをディスパッチャに送信する必要があるかを理解するために必要です。
「正規化」および「リレーショナルデータベース」という言葉を既に認識している読者は、テーブルがもっとあるべきだと主張するでしょうが、私はそれで十分だと主張します。
2.キュー処理ディスパッチャ。
これは、デーモンとして、または単にクラウンによってバックグラウンドで起動される特定のスクリプトであり、重要ではありません。
そのタスクは、アプリケーションの注文を処理し、支払いシステムに連絡し、アプリケーションのステータスを変更することです。
3.ライブラリはアプリケーションで動作します。
実際、これはキューを操作するためのライブラリです（「データベース」を読んでください）。 それから、いくつかの機能のみが必要です。
- アプリケーション作成
- アプリケーションに関する情報を受け取る
- ステータスおよびその他のアプリケーションデータの変更
- キューからのアプリケーションの受信
- アプリケーションを削除
4. Webインターフェース。
必要なものについては、ユーザーに注文に関する情報を表示し、ユーザーが「支払い」ボタンをクリックできるようにすることは理解できます。
このライブラリから、いくつかの形式（少なくともhtmlとjson / xml）から同じデータを提供できる必要があります。 HTMLは何に対しても理解可能であり、JSONはページをオーバーロードするのではなくAJAXを使用するために使用されます。 原則として、それなしでも可能です。
Webインターフェースから必要な機能は4つだけです。
- 関数を呼び出してリクエストを作成します
- 関数要求データを呼び出す
- アプリケーションの削除機能の呼び出し
- エラー処理の基本的な機能と目的の形式でのデータ出力。
5.特定の支払いシステム（BPS）を操作するためのライブラリは 、
- PSでアプリケーションを作成するリクエストのURLとデータを生成します。
- 支払いシステムの応答を分解し、支払いシステムの番号付けで注文番号を返す
- アプリケーションステータスをリクエストするためのURLとデータを生成する
- 支払いシステムの応答を解析し、アプリケーションのステータスを返します。
6.ペイメントシステム（OB）を含む一般的な作業ライブラリからも少し必要になります。
- BPSからアプリケーションの作成に必要なデータを受信し、このデータを支払いシステムに転送する機能。
- BTSに応答を送信し、そこからアプリケーションステータスを受信する機能
- 一般設定（たとえば、接続された支払システムに関する情報）を操作する機能
説明された作業シナリオは、新しい用語でどのように変わりますか？
0.支払いプロセスのユーザーによる初期化。
Webインターフェイスには、使用可能な支払いシステムと支払い情報のリストが表示されます。
ユーザーが[Pay]を押すと、ステータスが[new]のアプリケーションが作成され、それに関する情報がキューに入ります。 この時点で、ユーザーは「All will be、wait」というメッセージを受信し、時々アプリケーションのステータスを確認します。 ここでは、JSONでアプリケーションに関する同じデータが必要になります。AJAXを使用して、すべての種類の時間、進行状況バーなどを画面に描画しながら、アプリケーションのステータスについてキューに問い合わせます。
1.請求データに基づくアプリケーションの作成、秘密鍵または証明書を使用したアプリケーションの署名。
2.データを支払いシステムに送信し、会計システムで注文番号を受信する
3.この番号をシステムに保存します。
ディスパッチャは、ステータスが「新規」の注文をキューから削除し、ステータスを「処理中」に設定し、データをOBに転送し、PSへの送信に必要なデータを受信します。 それらを送信し、応答を受け取り、OB、BPSに渡し、注文番号を受け取ります。 順番に注文番号と支払いURLを保存し、アプリケーションのステータスを「支払い準備完了」にします。
次のポーリングでは、ユーザーキューがURLにスローされ、支払いが続行されます。 彼がそこで行うことは彼のビジネスです。 この電子通貨がないことに気付いた場合は、注文ステータスのページで、アプリケーションを削除し、別の通貨を選択できる新しいアプリケーションを作成するためのリンクを提供します。
4.注文のステータスの変更に関する支払いシステムの尋問。
ディスパッチャは定期的に「支払い準備完了」ステータスのリクエストを受信し、支払いシステムでステータスを確認します。 ステータスが変わらない場合は、より良い時間までアプリケーションを脇に置きます。
良い方法では、支払いシステムに無期限に問い合わせないように、アプリケーションの「有効期限」を考慮する必要があります。
5.システムでアプリケーションのステータスを変更し、ユーザーにサービスを提供します。
ステータスが変更されるとすぐに、支払いシステムの応答に応じて、ディスパッチャはアプリケーションを「支払い済み」または「拒否済み」としてマークします。 彼女はもうディスパッチャに到着しません。 これで、バックグラウンド請求スクリプトは請求が支払われたという情報を受け取り、注文されたサービスをユーザーに提供します。
記載されているシステムが優れているのはなぜですか？
1.ユーザーとのすべての操作を非常に迅速に実行できます。
アプリケーションをキューに保存し、一意の番号でアプリケーションに関するデータを受信するのは非常に簡単な操作です。
遅い作業はすべて、バックグラウンドでディスパッチャによって実行されます。
2.優れた拡張性。
さまざまなパーティション方法を使用して、多数のキューを整理できます。
各キュー、ステータス、または通貨を処理する数百人のデーモン。
3.彼女はシンプルです。
新しい支払いシステムを接続するには、新しいライブラリを追加するだけです。これは、上記で説明した4つのことだけが可能でなければなりません。
この記事では、特定の実装の詳細については述べません。ツールは重要ではありません。
PerlまたはPHP、またはWeb /データベース用のPythonを使用できます。
キューイングには、MySQL、SQLite、Oracle、またはPosgreSQLを使用できます。
file_get_contents（）、LWP :: UserAgent、またはHTTPで作業するためのCURLを指定できます。
支払いシステムでリクエストステータスポーリングの間隔を2倍にできます。 あなたは3.14159でできる...
実装はあなた次第です。
upd：全文（図および追加を含む）が私のWebサイトで入手可能