Pull to refresh

Comments 14

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

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

Задача, казалось бы, тривиальная.

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

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

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

Уже радует, но какова стоимость внедрения?
Если сравнить с:
За недельку прикрутили нужное API в админке и запустили это дело на iPad. Все замечательно.
Если админка позволяет повесить на кнопку линк, который вызовет наше приложение с передачей ему данных заказа, то можно все сделать за день.
Пример линка:
<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|">Оплатить заказ
Еще лучше, уже идем в нужном нарпавлении.
Как получить сообщение о фактической оплате сразу после оплаты?
Продавцу нужно будет еще какую-то кнопку нажимать уже после оплаты.
После оплаты приложение закрывается с Callback JSON, где будут все параметры прошедшей оплаты (TransactionId, Invoice, RRN, IIN, PAN, Created и т.д.).
Также есть сервис «Уведомление внешних систем», в ЛК сервиса можно указать url внешнего хоста, куда будут улетать в онлайне те же данные об операциях.
Sign up to leave a comment.

Articles