/ Flickr / Muhammad Ashiq / CC BY-SA
背景
2012年から1cloudで IaaSサービスを提供しています。 この間、私たちは多数の支払いゲートウェイと連携することができました 。 最初の1つはMoney Onlineでした。 私たちは彼と2年間働き、その後、技術的な問題が発生する可能性がある場合に代替サービスを接続し始めました。
代替案として、PayPalとRobocassaが検討されました。 その結果、両方のプラットフォームが接続されましたが、これにはいくつかの困難がありました 。 最初のケースでは、クライアントIDを支払いフォームにインポートするために、CSSルールを調整し、Webページの標準要素を変更する必要がありました。 Robocassaの状況では、APIの多くのリクエストがその説明と一致しませんでしたが、テクニカルサポートの助けを借りて、状況も解決されました。 これらの決定にとどまらず、潜在的なパートナーから提供された他のオプションを検討しました。
そこで、PayMaster決済システム（「Money Online」に代わるもの）の使用を開始しました。このシステムは、手数料に関する有利な条件と便利なAPIを提供してくれました。 長い間、この支払いゲートウェイはメインのゲートウェイとして機能していました。 ただし、最近、サービスの使いやすさを再設計し、個人の銀行カードによるサービスの支払いプロセスを簡素化することにしました。 UXが要件を満たすために、別の支払いゲートウェイであるCloudPaymentsを統合しました。
UX支払いプロセスを改善できるものがあるため
前払いモデルに取り組んでいます。 クライアントは自分のアカウントに自分のアカウントを補充し、IaaSサービスが消費されると（10分ごとに借方記入）、このアカウントから資金が借方に記入されます。
PayMasterの場合、銀行カードで残高を補充するために、クライアントは4段階のプロセスを経る必要がありました。
- コントロールパネルのフォームに支払い金額を入力し、[支払い]ボタンをクリックして支払いゲートウェイページに移動します。
- 小切手を受け取る電話またはメールアドレスを指定して、[続行]をクリックします。
- カードの詳細を入力し、もう一度「支払い」ボタンを押します。
- 銀行が3Dセキュア手順の一部として送信した取引確認コードを示します。
免責事項：上記のアルゴリズムは、個人による銀行カードの支払いに適用されます。 法人は、請求書に基づいてIaaSプロバイダーのサービスに対して支払います。 使いやすさを向上させながら、このような請求書の自動請求のメカニズムを完成させましたが、法人が支払いゲートウェイと相互作用しないため、この資料のフレームワーク内では考慮しません。
ユーザーの支払いプロセスを簡素化し、一般に、銀行カードのデータを入力するフォームの外観と使いやすさを向上させることにしました。 これを行うために、私たちは自分自身のために2つのタスクを特定しました。これについては後で説明します。
タスク1：支払いゲートウェイページへの通路を除外する
上記のように、ユーザーがサービスの料金を支払うと、カードの詳細を記入するために、支払いゲートウェイのサイトに行くように強制されました。 そのため、多くの確認ボタンを押して、アカウントの補充に関する情報を含むページの読み込みを待つ必要がありました。
この場合、別の問題が発生しました-ユーザーが口座にお金を預けた後、特別なリンクをクリックして1cloud.ruに戻るまで、彼は支払いゲートウェイページにとどまりました。 これにより、たとえば支払い後にユーザーがITインフラストラクチャに容量を追加したい場合に、コントロールパネルでの作業が困難になりました。
「分析によれば、リンクをたどって当社のサイトに戻ったのはほんの一握りの顧客だけでした」と1cloud.ruの開発責任者であるセルゲイ・ベルキンは言います。 -一部は、クライアントが「オンラインストアに戻る」リンクをクリックする必要があったためです。 これは、当社のサービスがオンラインストアではないという事実にもかかわらずです。」
さらに、ユーザーが入力するフィールドの数を最小限に抑え、操作に本当に必要なフィールドのみを残したいと考えました。 このタスクを達成するために、CloudPaymentsペイメントゲートウェイを選択しました。CloudPaymentsペイメントゲートウェイの従業員は当初、迅速かつ完全なテクニカルサポートの対応で注目を集めました。
さらに、この支払いゲートウェイにはカザフスタンに駐在員事務所がありました。 これにより、ホスティングサービスoblako.kzの新しい支払い方法を実装できるようになりました 。 それ以外の場合、カザフスタンからロシアへの（またはその逆の）すべての転送は、追加の手数料の対象となります。
CloudPaymentsは、特別なchekoutスクリプトの使用を提案しました。 コントロールパネルで支払いフォームを直接実装し、完成したデータをGoogle側に保存せずに支払いゲートウェイに転送できます。
スクリプトを実装するには、認定された組織の1つで、CloudPaymentsの要件であるPCI DSSセキュリティスキャンを実行する必要がありました。 スキャンは、標準への技術的な準拠を確認し、サイト上のフォームに入力する際にユーザーデータが盗まれる可能性を排除するために必要です。
PCI DSSコンプライアンス監査は、ARintegによって実施されました。 私たちは彼らに、監査を受けたいという意向を示す申請書を送り、アンケートに記入し、検証の日付を設定しました。 ARinteg側では、スキャンの準備に約半日かかります（つまり、ほぼすぐにスキャンできます）が、インフラストラクチャを慎重に準備するためにさらに4〜5日かかりました。
スキャンには数日かかりますが、スキャンは約15時間続きました。 ARintegのスペシャリストは、SSLをチェックし、Webサイトでインジェクションリクエストやその他の脆弱性に対する保護を確認しました。
最初のテストには合格せず、修正が必要な問題のリストが提供されました。 それらはすべて重要ではありませんでした。たとえば、ユーザーがサイトでステップバイステップの手順を評価したときに使用されたポストメソッドがありました。 すべてのコメントを削除し、2回目の監査の試みは成功しました。 次に、chekoutスクリプトの実装に進むことができます。
スクリプトは当社のウェブサイトに登録され、指定されたフォームからカードデータを収集し、CloudPayments APIを介して支払い用の暗号データを作成します。 次のようになります。
this.createCryptogram = function () { var result = checkout.createCryptogramPacket(); if (result.success) { // alert(result.packet); } else { // , `result.messages` : // { name: " ", cardNumber: " " } // `name`, `cardNumber` `<input ... data-cp="cardNumber">` for (var msgName in result.messages) { alert(result.messages[msgName]); } } }; $(function () { /* checkout */ checkout = new cp.Checkout( // public id "test_api_00000000000000000000001", // , document.getElementById("paymentFormSample")); });
銀行カードデータを入力するためのフォームは次のようになります。
スクリプトとフォームの実装中に、ユーザーが入力するフィールドの数を最小限に減らすことができました。 彼らは手術に本当に必要なものだけを残しました。 たとえば、「名」フィールドと「名」フィールドは削除されました。 支払いゲートウェイの代表者が私たちに説明したように、銀行はこれらのデータをチェックしません（カード番号、日付、およびCVVのみが重要です）ので、それらを省略してプロセス全体を簡素化することにしました。
さらに、 割引プログラムに関する情報をより明確にしました：5,000ルーブルからの1回限りのアカウントの補充により、その10％がボーナスの形でクレジットされ、10,000ルーブル-20％、100 000ルーブル以上-25％。 また、ユーザーのマップデータを保存する機能も追加しました。 この情報はすべて、暗号化された形式でCloudPayments支払いゲートウェイの側に保存されます。
タスク2：自動支払いを実装する
これは、ある条件下で自動的に発生する支払いです。 多くの場合、この機能はサブスクリプションサービスで使用されます。 ただし、ほとんどの支払いゲートウェイは、スケジュール（特定の日付）で自動補充が行われる場合にのみオプションを提供します。 クライアントがアカウントの資金を使い果たした場合はいつでも、アカウントを補充する機会が自動的に利用可能であることが重要です（前払いに取り組んでいるため）。 したがって、自動支払いを実装するために、「記憶された」カードから支払うときに使用される方法を使用しました（一時トークンを使用）。
次のように機能します。ユーザーが最初に支払いを完了した後、ゲートウェイはサービスカードペアのトークンを生成し、ポストバック応答で送信します。 このトークンは保存され、再支払い時に既に転送されており、カードデータは転送されていません。 APIキー（リクエストが1クラウドから送信されたことを示す識別子）、トークン、および金額を示すリクエストをゲートウェイに送信します。 ゲートウェイは、そのようなトークンが作成されたかどうかを確認し、すべてが正常である場合、指定された金額の支払いを処理します。
自動支払いを行う必要がある日付は、ユーザーによるサービスの現在の消費量とアカウントの残高に基づいて動的に計算されます。 クライアントが貸借対照表に1000ルーブルを持ち、過去10分間に2ルーブルを消費したとします。 ゼロ調整のおおよその日付が500分10分間隔で来ることは明らかです-これは約34日です。 したがって、資金の終了の数日前に自動支払いを行うことができます。 顧客は、自動支払いサイズを個別に選択します。
次は何ですか
現在、これらのソリューションをテストし、実装の結果を評価しています。 顧客の投票によると、ほとんどはかなり変更可能です。 システムに関するフィードバックをより深く研究し、データを分析し、必要に応じて調整を行います。