大企業の和解、痛み、涙
簡略化するために、3つのグループが社内のプロジェクトの作業に関与しています。
- お客さま プロジェクトのビジネスアイデア、財務評価、販売を担当。
- プロジェクトマネージャー。 技術的な実装を担当し、影響を受けるグループを決定し、プロジェクトの全体的なタイミングと立ち上げを制御します。
- 開発者 プロジェクトを実装して起動します。
各ユニットには、キューと優先度を持つ独自のサブグループがありました。 このサイトを真剣に改訂するタスクは、大勢の同僚に影響を与えました。
- 支払い処理：
- 支払いJava開発者、大規模パートナーAPI、および標準外部API
- データベース設計とストアドプロシージャを担当するOracle開発者。
- Web開発：
- Web用のJavaバックエンド+ API開発者、
- JavaScript開発者、特にSPAの場合、
- レイアウトデザイナー。
- Q＆A、製品の最終リリースへの同意。
このアプローチにより、トップにとって最優先事項であったプロジェクトが迅速に開始されました。別のプロジェクトチームが割り当てられ、優先度やキューのない非常に複雑なプロジェクトを最短時間で開始しました。 ただし、他のすべての製品タスクは、実装のためにキューにスタックする可能性があります。 最も影響を受けたのは、すでに発売されている製品の開発です。
現在、QIWIは特定の製品のチームを結成しています。 同時に、たとえば、製品チームのJava開発者は、必要に応じて、支払い処理に変更を加えることができます。これはテストされ、受け入れられます。 以前は、処理開発者のみがこれを行う必要がありました。 Web開発者は、タスクキュー内の他のプロジェクトに切り替えました。 新しいアプローチにより、チームの柔軟性が向上し、新しい機能を実装する時間が大幅に短縮されます。 どのように変更することにしたかを見てみましょう。
8年後、私たちは決めました
メインプロトコルの変更は重要なステップですが、パートナー側の電話番号の必須入力は統合と支払いを複雑にします。 2つの開発オプションを調査しました。
1.サーバーRESTプロトコルでは、請求先電話番号を指定する必要があります。 任意の識別子または電子メールに請求するための改訂オプションを検討しました。
長所：
- 既存のパートナーからの潜在的な更新に便利な柔軟なアプローチ、
- 以来最大の保護 プロトコルにはサーバー間通信のみが含まれます。
短所：
- 新しいパートナー向けの複雑な統合。 支払いページにリダイレクトする前に請求する必要がありますが、
- 請求アラートで一括サービスを行うことは非常に困難です。
- 支払い処理でアカウントのアーキテクチャを大幅に変更する必要があります。
2.同社には、QIWI側に番号が入力されたhttpプロトコルがありました。 しかし、請求書がパートナーによって正確に発行されたことを、いかなる方法でも検証しませんでした。 このプロトコルは寄付の収集に理想的でしたが、大規模なパートナーにはこの形式で適用できませんでした。 解決策は、署名またはハッシュを追加し、請求書支払いページにリダイレクトするときにそれらを検証することでした。
長所：
- 新しいパートナー向けのシンプルな実装、
- チームによる低開発コスト。
短所：
- 秘密鍵を保存し、クライアントで署名を計算する「ギフト」パートナーが表示される場合があります。
いくつかの議論の後、2番目のオプションが選択されました。 当初、セキュリティサービス部門とIT部門は、公開鍵と秘密鍵に基づく署名の形成を好みました。 しかし、大規模なパートナーとの統合の経験、および証明書を置き換えるときに生じる質問や問題の数を思い出して、sha512ハッシュのチェックを停止することにしました。
質問がありました、どのパラメーターをハッシュするのですか？ 最も簡単なオプションは、すべてをアルファベット順にソートし、秘密鍵を追加してハッシュを取ることです。 分析後、コメントとエンコードに問題がある可能性があることが明らかになったため、リストを必要最小限のパラメーター数に減らしました。
秘密鍵をどのように決定するかという疑問が残りました。 基本認証では、RESTプロトコルはAPI IDとAPIパスワードのペアを使用します。これにより、パートナーのチェックを柔軟に構成できます。 1つのサイトに対して、複数の許可ペアを作成し、それらを異なるサーバーおよびサイトのバージョンで使用できます。
アルゴリズムと例
その結果、このアルゴリズムに到達しました。
- パラメーターの配列を作成します。
- api_id-秘密鍵を決定するためのID、
- 通貨-通貨
- from-プロバイダーID
- 合計-金額
- to（利用可能な場合）-電話番号、
- txn_id-プロバイダー側の一意のトランザクションID。
- api_idに関連付けられた秘密キーを配列に追加します。
- |を使用して、すべてのパラメーター値をストリングにマージします。 パラメーター間;
- ハッシュsha512を計算します。
- 16進数の小文字の文字列パラメーターシグネチャをリクエストに追加します。
PHPでの実装例。
// ID , API_ID, API url: https://ishop.qiwi.com/options/rest.action $shopId = '260***'; $apiKey = '4683****'; $apiPassword = '1T1ea7****'; $CCY = 'RUB'; $amount = 1.12; // 71231234567. $phone = null; // ID $txnId = 'habr'.rand(1,90000); $params = [$apiKey, $CCY, $shopId, $amount, $txnId]; if (null !== $phone) { $params = [$apiKey, $CCY, $shopId, $amount, $phone, $txnId]; } // $params[] = md5($apiKey); // "|" $paramsStr = implode('|', $params); // $signature = hash('sha512', $paramsStr); // query $query = http_build_query([ 'from' => $shopId, 'to' => $phone, 'txn_id' => $txnId, 'summ' => $amount, 'api_id' => $apiKey, 'ccy' => $CCY, 'signature' => $signature ]); // url $url = 'https://bill.qiwi.com/order/external/create.action?'.$query;
共同研究開発
実験として、プロトコルの開発方法を一緒に決定することを提案します。 いくつかの技術的な問題を解決していないため、プロトコルの開発方法を検討することをお勧めします。 このため、記事の最後に投票が追加されました。
主な問題は、アカウントのライフタイムの原因となるライフタイムパラメータのままです。 既存のプロトコルでは、数分で送信され、転送後すぐに請求書が発行されました。 新しいリンクでは、特にリンクが電子メールで送信された場合、請求書をかなり後で発行できます。 したがって、ほとんどの場合、絶対日付で新しいパラメーターを追加する必要があります。 たとえば、RESTで使用されるISO 8601（2016-09-12T00：00：00）の形式。 しかし、そこに秒が必要ですか？ そして、「：」を「％3A」にエンコードするか、「-」に置き換えるか、tkを尋ねます。 多くはまだURLコーディングなしでsuccess_urlを渡し、質問でサポートをノックしています。 ほとんどの場合、新しいパラメータも計算されたシグネチャに含める必要があります。
更新されたプロトコルは困難ですが、一括メール送信が可能です。 主な問題は、リンクの作成時に生成する必要がある一意のトランザクションIDです。 特定のアイテムを購入する大量郵送の場合、これは難しい場合があります。 ソリューションは、ストア内の購入IDとユーザーアカウントの組み合わせでもかまいませんが、ユーザーは何かを1回しか購入できなくなります。 この問題は、新しいパラメーターを作成し、一意性制約を削除することで解決できます。 確かに、これが市場で要求されているという疑問があります。 投票する
デザート用
新しいプロトコルは、パートナーを接続するための準備がすでに整っていますが、これまでのところ、サポートサービスを通じてのみ有効になっています。 テストに参加する場合は、 cms @ qiwi.ruに連絡するか、サポートにお問い合わせください。
ここで支払いページの現在の状態を評価できます 。 幸せなプログラマーの日！
PS私は、REST APIの実装に優れた経験を持つJava開発者をチームに参加させて、新しいishop.qiwi.comを立ち上げ、今年、数千のパートナーの質を向上させるため に 招待します。