Comments 15
А с этими кард-ридерами в теории можно работать как-то автономно, чтобы прочитать номер карты? Или сначала надо выбирать провайдера (платежный шлюз?), а уж потом с ним решать вопросы, что из считанной карты он может передать в приложение?
Платежный шлюз, как правило, предоставляет SDK|приложение для ридера и для интеграции со шлюзом — т.е. приложению нужна интеграция (простая) с SDK от платежного шлюза.
Тот же SDK/приложение может также содержать интеграцию с нужным фискальным принтером.
Т.е. вы просто кидаете сумму и описание платежа в SDK|приложение, а в ответ получаете информацию о проведенном платеже (при этом принтер печатает фискальный чек) или об ошибке, а все fallback-и приличные интеграторы прописывают уже внутри своего sdk|приложение.
То есть просто купить на рынке кард-ридер и читать информацию с карты не получится, как я понял :( У нас сейчас проблема в том, что не можем придумать надежный и безопасный способ передачи информации о карте клиента платежному шлюзу с девайса оператора. С девайса клиента решили вопрос — во фрейме окно шлюза, куда клиент вводит номер карты и CVC, а шлюз передаёт нам токен для дальнейшей работы с картой. Но то же самое сделать в приложении для наших операторов смысла не видим по психологическим причинам — есть подозрение, что мало кто из клиентов захочет вводить номер и CVC в приложении на чужом девайсе, а вот к кард-ридерам народ привычный.
Ридер можно купить (официально у поставщиков), но есть одно «НО». Там ключи которые прописывает производитель и этими ключами можно расшифровать пакет с ридера. И там будет вся инфа с карты — только вот вам в таком случае надо свое приложение и вашу организацию проводить через PCI DSS аудит. А шлюз (обычно) может принять и карточные данные (в открытом виде).
Но транзакция может идти в разных режимах — если проверка PIN идет в ридере (на самой карте), то там только криптограмму специальную надо передать вместе с данными карты (по сути это подтверждение проведения аутентификации плательщика устройством). Но если требуется проверка через банк эмитетнт, то тут уже идет PIN блок (шифрованный). Только вот PIN блок — его раскрывать — еще более строгий и дорогой уровень сертификации. А без PIN — только оплата по NFC на сумму не выше 1000р.
В общем тут очень много нюансов. И если не охота с этим возится то лучше купите решение от шлюза. Сейчас все нормальные шлюзы предлагают решения для мобильной торговли (с кард-ридером и без необходимости серьезной сертификации клиентского приложения ибо через него все карточные данные идут в закриптованном виде, расшифровываются только на стороне шлюза). Если ваш шлюз не предлагает мобильного решения — переходите к другому.
В реальности все куда дольше, и вы сами прекрасно знаете почему.А действительно, почему — автоматизации нет? А если же просто хозяин проката не уважает клиентов? — тогда автоматизация тут не поможет — хозяин урежет (экономия!!) ещё какой-то ресурс, и всё вернётся на круги своя.
А то ведь 58ФЗ уже начал помаленьку работать, а там уже кассы без фискального накопителя. А с отправкой данных на сервер провайдера фискальных данных.
т.е технически хорошее решение — экономически не понятно
Схему представленную в статье показывали на конференции Атол.
Насколько я помню решение для курьерских служб и разъездной торговли.
мой опыт
неделю назад бы на покатушках
в кассе обычный кассовый аппарат с терминалом для карточек
1 заплатил за скипас и аренду амуниции
2 получил чек со штрихкодом
аренда, там стоят терминалы
3 завел свой аккаунт по номеру прав (можно и по кредитке)
4 отсканировал код с чека
5 указал рост, размер обуви, вес
6 распечатал бумагу с кодами на аренду
7 по этой бумаге получил шлем и боты
8 проверил боты по ноге
9 получил лыжи по бумаге
Интеграция Android-приложения с фискальным принтером и кардридером