みなさんこんにちは！
私が最近取り上げた実際の注文の典型的な支払いプロセス：
（売り手/オンラインストアにNo. Zをリクエストし、個人的な価格で必要なものすべてを提供しました。）
-こんにちは。 注文番号Zを支払い、受け取りたいです。 -クライアントが売り手に言ってアプローチします。
-ちょっとだけ。 -売り手は言います。 売り手はオンラインストアシステムを開き、データをコピーしてリーフレットを印刷します。 -今、レジに行き、それから私に戻ります。
クライアントはチェックアウトに行き、店の品揃えを賞賛します。
-こんにちは、私たちは何を払っていますか？ -レジ係にレジ係に尋ねる。
-ここで、これらの文書によると、クライアントは答えます。
-ちょっと待って。 -レジ係は言います。 レジ係とレジ係は、支払い端末とプリンターに助けを求めます-「支払い端末-支払いを支援します。」
-親愛なる顧客、カードとピンを提供します。 -ウィンドウから表示される支払い端末。
クライアントは、端末が要求したすべてを提供しました。
-現金デスクは大丈夫、お金はブロックされています。 -支払い端末はレジの前でカウントされます。
-ちょっとプリンター、小切手を印刷！ -キャッシャーが要求した、クライアントに与える必要があります。
-お支払いありがとうございます。 -キャッシュデスクからキャッシャーに丁寧に答えました。
顧客は売り手に行きます。
-ここで、すべてが支払われます、私の待望の製品はどこですか？ -クライアントに尋ねた。
さらに物語の中で、私は商品と関連する保証を受け取りましたが、私をホールの周りに連れて行くことはできませんでした。
そのため、オフラインからオンラインストアに、またはその逆にオフラインからオンラインに移行するために欠けているものはありません。
小さな倉庫のあるオンラインストアが1階に移動しました。 どのソリューションがオフラインでの支払いを受け入れるのに適しているかを尋ねられました。 タスクは一見些細なことです。 しかし、「価格」と「残高」のすべての計算はオンラインストアシステムを経由する必要があります。そうでなければ、長くて高価なサイクルです。
タスク- 手動モードを高速化します 。
できるだけ迅速かつ安価に、オンラインストアのピックアップ/購入ポイントを開きます。 すべての価格、プロモーション、ロイヤルティプログラムは、デフォルトのオンラインとオフラインで常に同じでなければなりません。
ストアデータベースからターミナルおよびレシートプリンターへのデータの最速の方法を見つけます。
したがって、対話のアクターのようなシステムがあります。
顧客はカード所有者です。
売り手 -オンラインストアシステムを使用する権利を持つ人。
オンラインストア -注文に関するすべてを知っており、このデータを誰かに転送できます。
支払い端末 -顧客カードを受け入れます。
プリンター -小切手を顧客に
印刷します。
キャッシャーとキャッシャー -データを端末、プリンター、その他便利なものに送信します。
アクターをハードウェアとソフトウェアに変えます。 ブラウザ内のアプリケーションをオフライン鉄と接続する方法を見てみましょう。 実装とサポートのコストを考慮してください。
明らかな解決策は、タブレット上のアプリケーション/ APIを使用したmPOSでした。
ソリューションコンセプト-自動化
すべての手順は似ていますが、売り手が店内を駆け回って端末を持ち込むドキュメントを持っているクライアントの代わりに、またはむしろ忠実なモバイルアシスタントを持ちます。
売り手は、キャッシャーと連携するためのブラウザ内のリンクを持っています。
kass-api://payNow?callback=[ecommerce-system-url?{ *}]&order={ }
キャッシュデスクは即座にデータを決済端末アプリケーションに転送します。
pay-api://payNow?callback=[kass-api://paymentResult?{ *}]&order={ }
クライアントは、支払いターミナルを通じて注文の代金を支払います。
支払い端末はキャッシャーに制御を返します。
kass-api://paymentResult?{ *}
レジ係は、支払いのためにデータをすぐにプリンタに転送します。
print-api://payNow?callback=[kass-api://paymentResult?{ *}]&order={ }
プリンターは小切手を印刷し、他のことをして、コントロールをカッサに返しました。
ecommerce-system-url?{ *}
*パラメータの中に安全オプションが含まれる場合があります
すべてが長い間発明されてきたもので、カスタムスキームと呼ばれています。
カスタムスキームとは何ですか？
これは、URI自体（Universal Resource Identifier）に規定された要素です。
http：//、https：//、ftp：//、sftp：//などに慣れています。 これはすでに人気のあるプラットフォームで実装されています。
myapp：// myappが同じ回路であるファイルへのパス。
iOSの場合Android向け米国のソリューション
Paypal Hereと互換性のあるプリンターを用意してください。
目的のAPIを提供し
ます 。
幸いなことに、PayPal Hereアプリケーションは
mPOSターミナルを介して支払いを
受け取り 、Bluetoothプリンターで小切手を印刷できます。
キャッシャー、ターミナル、プリンターのすべてが1つのアプリケーションに。
1週間、オンラインストアの管理パネルで必要なAPIをねじ込み、iPadにこのものをインストールしました。 すべてが素晴らしいです。
はい、これはロシアで使用できない
同じ端末よりもわずかに優れています。
ロシアの現実に戻る
米国の店舗のように問題を完全に解決できる単一のソリューションは見つかりませんでした。
次のことを想定してみましょう。
お願い：Atol、Euthor、Kassa Module、Yandex.Kassa、2Can、
記事 「Cashier I Do n't Know」にリストされているすべての人が、カスタムScheme APIをアプリケーションに追加します。
誰かが厳しい現実の解決策を知っているなら、私は協力してうれしいです。 コメントであなたの意見を共有してください。