大規模プロジェクトでの請求

プロジェクトを「収益化」するにはさまざまな方法があります。 ただし、共通点が1つあります。それは、ユーザーのウォレットから組織のアカウントへの送金方法です。 今日は、Badooでの支払いの受け入れ方法と、支払いゲートウェイ市場で何が見つかるかについて説明します。 この記事では、会社の資金の売上高に関する具体的な数字は見当たらないが、他のすべてはそれほど興味深いものではないとすぐに警告します。

請求とは何ですか？

私たちにとって、請求はユーザーからのお金の受け取りに関連するすべてです：価格設定、支払い受付ページ、支払いの直接受け入れと処理、有料サービスの提供、さまざまなプロモーション、そしてもちろん上記のすべての監視。



当初、すべてのスタートアップと同様に、有料サービスはありませんでした。 サイトが2006年に正式に開始されたという事実にもかかわらず、収益化に向けた最初の深刻なステップは2008年に始まりました。 実験では、フランスが選択され、SMSを介してのみ支払いが受け入れられました。 支払いの受け入れ自体はファイルで構成されていました。 各リクエストは個別のファイルに書き込まれ、bashスクリプトによって1つのフォルダーから別のフォルダーに転送されたため、処理ステータスが変更されました。 データベースは、正常に処理されたトランザクションを記録するためにのみ使用されました。 このようなスキームは1年以上にわたって正常に機能し、その後維持が困難になり、データベースを使用してファイルを破棄し、すべてを書き換えることに決めました。



有料サービスが利用できる国は多くなかったため、新しいバージョンの開発は十分に迅速でした。 ただし、SMSを介して支払いを受け取るためだけに設計されています。このため、処理済みテーブルには、MSISDN（電話番号）やショートコード（短いSMSの送信先）フィールドなど、いくつかの面白いアーティファクトが残っています。支払い。



現在、私たちはほぼ世界中で支払いを受け付けています。 毎秒、ユーザーはサイトや人気のあるすべてのモバイルプラットフォームのアプリケーションで何かにお金を払おうとします。 これをマップに配置すると、「夜の宇宙からの地球の眺め」という画像が得られます。







さまざまなパートナーから約50の支払い方法を利用できます。 最も人気のあるものは、銀行カード、SMS、モバイルアプリケーションでの直接請求および購入です。







その中には、エキゾチックなものもあります。たとえば、インターネットプロバイダーの口座からの直接引き落としや、固定電話による支払いです。 そして、普通郵便で支払いを受け取ったら！

銀行支払い

すべての支払いシステムでは、ユーザーからの支払いを受け入れることができます。 そのような直接統合は、それらが多くなり、よく知られているシステムをデバッグされたプロセスに接続するまで行うのが便利です。 しかし、地元の市場に参入する必要がある場合、問題が発生し始めます。 さまざまなAPIの「動物園」を維持することはますます難しくなり、規制当局の要件は異なります。一般的なローカル決済システムは、外国のクライアントと低速で取引することを拒否したり、契約に署名して法的問題を解決したりするのに時間がかかる場合があります。 このような困難にもかかわらず、地元の決済システムは、その変換であなたを喜ばせることができます。 たとえば、この国で人気のあるiDeal支払い方法を接続した後、私たちがあまり有望ではないと考えたオランダは、30〜40％多くのお金をもたらし始めました。



需要があれば、オファーがあります。 市場には多くのアグリゲーター企業があり、または別の方法で、単一のAPIの下でローカルシステムを含むすべての一般的な支払いシステムを統合することを目的とする支払いゲートウェイがあります。 このような統合を行った後、世界中の数十の支払いシステムを介して支払いを受け取る機会が得られます。 ウェブサイトで支払いページを作成する必要はありませんが、アグリゲーターが提供する既製のものを使用し、自分だけのデザインを調整してください。 特に先進的な企業は、CSSおよびJSファイルのアップロード、写真の変更、翻訳テキストの作成、さらにサブドメイン（payments.example.comなど）での結果ページの登録さえ可能にします。 これにより、「カスタマイズ」の機会が非常に豊富になり、ユーザーは自分のサイトを離れていないという感覚を覚えます。 複数のアグリゲーターと同時に作業するため、この機会は自宅では使用しませんが、一部のアグリゲーターにとっては非常に便利なソリューションになる可能性があります。



直接統合とアグリゲーターのどちらを使用するかは、主にコミッションの規模に依存します。 顧客が支払いシステムを使用すればするほど、コミッションを節約して直接接続できるようになるため、収益性が高まります。 2番目の重要な要素は、APIの品質、使いやすさ、安定性です。 ここでは、アグリゲーターを使用して粗さを滑らかにし、直接接続よりも安定したサービスを提供することがあります。

SMS支払い

SMSによる支払いと携帯電話の残高からの直接控除は区別されます。 多くの国、特にヨーロッパでは非常に厳しく管理されています。 現地の規制当局または州自体には、支払いページの外観やSMSメッセージのテキストについて特別な要件がある場合があります。 そのような要件の変更は監視され、変更は時間通りに行われなければなりません。 そのため、たとえばベルギーでは、黒い背景に短いフォントを白いフォントで記述し、その横にコストを表示するというルールがあります。







SMS請求のタイプは異なります-MO（モバイル発信）またはMT（モバイル着信）。 MO課金では、すべてが非常に簡単です。ユーザーが短い番号にSMSを送信すると、私たちはお金を受け取りました。 しかし、MTにはいくつかのオプションがあります。 ユーザーがSMSメッセージを送信した時点ではなく、特別な有料SMSを受け取った後に支払いが行われます。 つまり、支払いの事実は、支払い済みのSMSが正常に配信されたというアグリゲーターから受信した通知です。 このアプローチの主な目的は、有料のSMSメッセージをユーザーに送信する前に追加のチェックを追加し、SMSの誤ったテキストに関連するエラーを防ぐことです。 このため、支払いは2段階で行われます。 1つ目は、ユーザーが何かの支払いを希望することを表明することであり、2つ目は確認です。 たとえば、支払いプロセスは次のようになります。

• SMSを短い番号に送信し、着信SMSに特定のテキストを使用して、またはテキストなしで応答します。
• SMSを短い番号に送信し、受信したPINコードをサイトに入力します。
• Webサイトで電話番号を入力し、PINコードを取得して、Webサイトで入力します。

幸いなことに、SMS決済市場にはアグリゲーター企業もあり、そのサービスを利用する価値があります。 それらは、控えめな、時にはそれほどではないが、そのような詳細に対処するための「喜び」をあなたから奪うためのものです。 別の素晴らしいボーナス-彼らはしばしばエンドユーザーをサポートする責任を引き受けます。 ユーザーは自分の問題について短い番号の所有者に直接書き始めます。 アグリゲーターに。

技術的な詳細

Badooは多くのPHP + MySQLで実行されるため、同じテクノロジーを使用して支払いを処理します。 コードは、共通プールから分離された別個のサーバーグループで実行されます。 内部では、受信リクエストを処理するためのサーバー、バックグラウンド操作と統計収集のためのサーバー、データベースサーバー、銀行カードの支払いを処理するためのサーバーなど、いくつかの論理的なサブグループに分けました。 後者は別のグループに割り当てられます。これは、銀行カード所有者データを処理または保存する組織のために、Visa、MasterCard、American Express、JCB、およびDiscoverが参加して開発したPCI DSSセキュリティ標準に準拠する必要があるためです。



支払い処理には、PerconaのMySQLを備えた2つのデータベースサーバーを使用し、 マスター/マスターレプリケーションで作業します。 主な負荷はそのうちの1つだけになります。2つ目は、事故発生時の「ホット」交換、またはメインサービスの交換（サービス中、監視システムからの要求または統計収集）に使用されます。



課金システム全体は、いくつかの大きな部分に分割できます。

• コア。 これには、 Order 、 Payment 、 Servicesなどの基本的なエンティティと、それらのアカウンティングとプロビジョニングのルール、さまざまなインフラストラクチャのものが含まれます。
• アグリゲータープラグイン。 私たちと支払いシステムの間の通信に責任があるすべてのもの。
• サービスを選択して支払うためのページ。

新しい支払い方法をシステムに接続するには、プラグインを作成するだけです。 彼は、私たちと支払いゲートウェイの間のすべてのやり取りを担当します。これは、私たちがイニシエーターの場合（プルリクエスト）とイニシエーターがアグリゲーターの場合（プッシュリクエスト）の2つのタイプです。 プルリクエストの場合、HTTPは通常、純粋なプロトコルとして、またはJSON / XMLまたはSOAPのトランスポートとして使用されます。 最近人気のあるREST APIの概念は、イギリスのGoCardlessなどの市場の新しい会社や、PayPalなどのAPIを再設計することを決めた古い会社の間でのみ頻繁に見られることはありません。 プッシュ要求の場合、SOAPは実際には使用されません（この形式のプッシュ通知を提供する人の中で、Qiwiのみが簡単に記憶されます）。 純粋なHTTPが主に使用されるか、すべて同じJSONおよびXMLのトランスポートとしても使用されます。



APIの実装後、テストフェーズが開始されます。 Habrには、開発と自動化の プロセスがどのように見えるかについての記事が既にありました。 ただし、請求については、コードだけでなくアグリゲーターとの相互作用もテストする必要があるという事実に主に関連する機能がいくつかあります。 このために、実際の支払いの受け入れを完全にエミュレートするテスト環境があれば非常に便利です。 存在しない場合は、アグリゲーターの動作をエミュレートする「スタブ」を作成します。 これにより、手動テストが簡素化され、支払いプロセス全体を検証するセルフテストを作成できます。 スタブの1つがどのように見えるかの例を次に示します。







テスト環境の後、すべてが実際にどのように機能するかを確認し、実際に支払いを行う必要があります。 ただし、SMSによる支払いの場合、規制当局またはオペレーターから承認を得る必要があり、これには数か月かかる場合があります。 本番サーバーに半完成コードを広めないために、External Shotのようなものを思いつきました。 これは通常のショットです。これはタスクブランチのあるディレクトリであり、本番サーバーでテストすることを目的としていますが、ローカルドメインに加えて、誰でもアクセスして変更を確認できる追加の外部アドレスがあります。 セキュリティのために、このような「ショット」は各タスクではなく、本当に必要な場合にのみ作成されます。 パートナーにリンクを提供し、パートナーは昼夜を問わずいつでも変更を確認できます。 これは、時差が12時間に達する可能性のある他の半球に位置する国に特に当てはまります。

サポートと運用

新しい統合が運用サーバーに配置された後、その運用とサポートの段階が始まります。 テクニカルサポートには時間の約60〜70％がかかります。







これには、まず、ユーザーの苦情の分析が含まれます。 単純な状況はすべて第一線のサポートチームによって解決されますが、異なる言語からの苦情も英語に翻訳されます。 したがって、開発者の注意を本当に必要とする最も複雑なケースのみを取得します。



テクニカルサポートの2番目のコンポーネントは、バグの修正または既存の統合の変更です。 エラーはさまざまな理由で発生します。 たとえば、ドキュメントまたはその中のスペースを不注意に読んだためです。 新しいシステムのドキュメントがまだ準備できていないため、一度ではなく、アグリゲーターの開発者とチャットログを使用する必要さえありました。 アグリゲーターが通知なしで対話プロトコルまたはそのパラメーターを変更した場合がありました。 また、アクワイアラーバンクがゲートウェイを切断し、トラフィックを緊急に別の場所にリダイレクトする必要がありました。 後に判明したように、それは80年代の古代のサーバーであり、銀行によると、何も処理すべきではありません。 一般的に、特にダウンタイムが1分ごとに利益を失うことを考えると、退屈する必要はありません。



このような問題を解決するために、アプリケーションの詳細なログを作成します。 エラーが発生するだけでなく、アグリゲーターシステムとのすべてのやり取り、またはクエリの実行中に発生する重要なイベントも発生します。 各要求には独自の一意の識別子があり、これにより、関連付けられているすべてのレコードを検索して処理を復元できます。 これは、数週間または数か月が経過したエラーに対処する必要がある場合に特に役立ちます。



これが、Badooでの請求の構成方法です。 もちろん、たとえば監視、PCI DSS認定、銀行カード支払いの処理など、将来についてお伝えする予定の興味深いトピックはまだたくさんあります。 今後の記事のトピックについて質問や提案がある場合は、コメントを歓迎します。



アナトリーパノフ

主任開発者