Идеальный выход в оффлайн из онлайна

    image

    Всем привет!

    Типичный процесс оплаты реально существующего заказа, который я недавно забирал:
    (У продавца/в интернет-магазине я запросил №Z и предоставил все что нужно для персональной цены.)

    — Привет. Хочу оплатить и забрать заказ №Z. — говорит Клиент и подходит к продавцу.
    — Минутку. — говорит продавец. Продавец открывает систему интернет-магазина, копирует данные и печатает листочек. — Теперь в кассу и потом назад ко мне.
    Клиент идет к кассе, любуясь ассортиментом магазина.

    — День добрый, что оплачиваем, сумма? — запрашивает кассир из кассы.
    — Вот, по этим документам — отвечает клиент.
    — Секундочку. — говорит кассир. Кассир и касса просят помощи у платежного терминала и принтера, — «Платежный терминал — помоги провести оплату.»
    — Уважаемый Клиент, предоставьте карточку и пин. — платежный терминал, показавшись из окошка.
    Клиент предоставил все, что просил терминал.
    — Касса все OK, деньги заблокированы. — платежный терминал отсчитался перед кассой.
    — Эй принтер, напечатай чек! — запросила Касса, нужно отдать Клиенту.
    — Вот чек, спасибо за оплату. — вежливо ответил Кассир из кассы.
    Клиент идет к продавцу.
    — Вот, все оплачено, где мой долгожданный товар? — спросил Клиент.
    В истории дальше я получил товар и сопутствующие гарантии, но можно же было не гонять меня по залу.

    Так вот, чего же не хватает для выхода в оффлайн Интернет-магазинам, и наоборот, из оффлайна в онлайн.

    Один интернет-магазин, с небольшим складом, переехал на первый этаж. Меня попросили посмотреть какое решение подойдет для приема оплаты оффлайн. Задача, казалось бы, тривиальная. Но все расчеты «цен» и «остатков» должны идти через систему интернет-магазина, иначе это долгий и дорогой круговорот.

    Задача — Ускорить ручной режим.


    Максимально быстро и дешево открыть точку самовывоза/покупки товара, для интернет-магазина. Все цены, акции и программы лояльности должны быть одинаковыми всегда для онлайна и оффлайна по умолчанию.
    Найти самый быстрый путь для данных от БД магазина до терминала и принтера чеков.

    Итак, у нас есть системы, как актеры в диалоге:
    Клиент — владелец карточки.
    Продавец — тот-кто имеет права на пользование системой интернет-магазина.
    Интернет-магазин — знает все о заказе и может кому-то передать эти данные.
    Платежный терминал — Принимает карточку клиента.
    Принтер — Печатает чек клиенту.
    Касса и кассир — Передает данные терминалу, принтеру и что-то еще полезное.

    Превратим актеров в железо и софт. Глянем на способы связи Приложений в Браузере с Offline железом. Учтем стоимость внедрения и поддержки.

    Очевидным решением оказался mPOS c приложением/API на планшет.

    Концепт решения — Автоматизация


    Все шаги аналогичны, только вместо клиента с документами бегает по магазину продавец и подносит терминал, вернее его верный мобильный помощник.
    У Продавца в браузере формируется ссылка для работы с Кассой.

    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?{параметры ответа*}


    * среди параметров могут быть средства безопасности
    Все уже давно придумано, называется это custom scheme.

    Что такое custom scheme?


    Это элемент который был заложен в сам URI (Универсальный Ресурс Идентификатор).
    Все мы привыкли к http://, https://, ftp://, sftp:// и другим. Это уже реализовано в популярных платформах.

    myapp://path-to-file где myapp это та самая cхема.

    Для iOS
    Для Android

    Решение в условиях США


    Берем Paypal Here и совместимый принтер.
    Он предоставляет нужное API.

    Благо, приложение PayPal Here принимает оплату через mPOS Терминал и умеет печатать чеки на bluetooth принтере.

    Все в одном приложении: Касса, терминал и принтер.

    За недельку прикрутили нужное API в админке интернет-магазина и установили это дело на iPad. Все замечательно.

    Да, это немного лучше чем тот самый терминал, которым в России мы пользоваться не можем.

    Возвращение в реальность России


    Я не нашел ни одного решения, которое бы полностью могло решить вопрос так, как это удалось для магазина в США.

    Позволю себе предположить следующее:
    Пожалуйста: Atol, Эвтор, Модуль Касса, Yandex.Kassa, 2Can, все кто перечислены в статье, «Касса, которую я не знаю», добавьте в свое приложение Custom Scheme API.

    Если кто-то знает решения для суровой реальности, буду рад сотрудничеству. Делитесь своими наблюдениями ниже в комментариях.
    Готовы ли вы таким способом выходить в оффлайн?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну, и что?
    Реклама
    Комментарии 14
    • 0
      А что мешает продавцу просто дать в руки платежный терминал? Он же размером с калькулятор. Вам же в реальной жизни никто и не позволит вводить реквизиты карты и пин непонятно через какое устройство, чтобы потом передавать их платежному девайсу.
      • 0

        Тот же PayPal here позволяет вместо прокатывания карты вбить реквизиты и в США это вполне используется. Zero liability по кредитке очень расслабляет пользователей.

        • 0
          Привет,
          Подключали PinPad.
          Чтоб было больше уверенности у покупателя.
          Все один в один c Терминалом 2Can / Яндекс mPOS
        • +3
          Задача, казалось бы, тривиальная.

          По-моему, так и есть.
          Из всего что написано ниже около 90% — вода, остальные 10% — идея о том, что два разных сервиса могут делать друг на другая редиректы через апи с передачей данных (какая новость, однако).

          • 0
            Привет все дело в стоимости внедрения,
            Вместо писанины «кому-то нужных» касс, достаточно предоставить инженерам и интернет-продавцам дешевый выход в оффлайн.
            • 0
              Опять вода. Кто куда откуда должен выходить? Вы даже проблему нормальным языком не сформулировали. Для обзорных статей без конкретики есть гиктаймс.
              • 0
                Коллега, IT чаще всего решает задачу оптимизации времени.
                Для данного случая:
                Задача
                Mаксимально быстро и дешево открыть точку самовывоза/покупки товара, для интернет-магазина. Все акции и программы лояльности должны быть сквозными по умолчанию.
                Найти самый быстрый путь для данных от БД магазина до терминала и принтера чеков.
                Решение
                Использовать custom scheme для передачи необходимых данных для приема оплаты, печати чека в приложения на устройствах iOS и Android и попросить поставщиков касс/терминалов сделать такие API в приложениях.
                Ожидаемый результат
                Это должно уменьшить к-во часов инженеров на интеграции, уменьшить время запуска новой точки продаж, уменьшить стоимость поддержки на местах. Может и отрыть двери для построения розничных сетей под крышами Интернет-магазинов.
          • 0
            Stripe может работать с российскими банками, payworks может работать со страйпом.
            Думаю такое решение вполне может подойти и для российских магазинов
            • 0

              В 2can&ibox мы легко решаем этот кейс вызовом нативного приложения на Android по кнопке прямо из браузера, с передачей ему товарных позиций с ценой, количеством и налоговой ставкой для оплаты чека по карте через mPOS-терминал или регистрации его наличной оплаты с последующей фискализацией в соответствии с 54-ФЗ на регистраторах Атол или Штрих-М. Так уже давно работают небольшие ПВЗ одного очень крупного онлайн-ритейлера. Готов скинуть пример html-кода.

              • 0
                Уже радует, но какова стоимость внедрения?
                Если сравнить с:
                За недельку прикрутили нужное API в админке и запустили это дело на iPad. Все замечательно.
                • 0
                  Если админка позволяет повесить на кнопку линк, который вызовет наше приложение с передачей ему данных заказа, то можно все сделать за день.
                  Пример линка:
                  <a href=«intent:#Intent;action=ru.ibox.pro.acceptpayment;S.Description=»Заказ No 01";S.Email=логин@агента;S.Purchases= {«Purchases»: [{«TaxCode»:[«VAT1800»], «Title»:«Шарф шерстяной»,«Quantity»:«1»,«Price»:«3000»}, {«TaxCode»:[«VAT1000»], «Title»:«Перчатки кожаные», «Quantity»:«2»,«Price»:«1000»}]};S.PrinterFooter=Спасибо за покупку!;S.PrinterHeader=«Заказ No 01»;S.Password=пароль_агента;end|">Оплатить заказ
                  • 0
                    Еще лучше, уже идем в нужном нарпавлении.
                    Как получить сообщение о фактической оплате сразу после оплаты?
                    Продавцу нужно будет еще какую-то кнопку нажимать уже после оплаты.
                    • 0
                      После оплаты приложение закрывается с Callback JSON, где будут все параметры прошедшей оплаты (TransactionId, Invoice, RRN, IIN, PAN, Created и т.д.).
                      • 0
                        Также есть сервис «Уведомление внешних систем», в ЛК сервиса можно указать url внешнего хоста, куда будут улетать в онлайне те же данные об операциях.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое