Pull to refresh

Comments 15

А с этими кард-ридерами в теории можно работать как-то автономно, чтобы прочитать номер карты? Или сначала надо выбирать провайдера (платежный шлюз?), а уж потом с ним решать вопросы, что из считанной карты он может передать в приложение?

С кард-ридера вы получите шифрованный пакет с карточными данными, расшифровать его может только тот кто выдал вам этот кард-ридер. Но даже если вы расшифровали то вам нужно провести транзакцию через процессинговый центр банка. Т.е. нужна интеграция с банком и с ридером, а еще (раз вы работает с карточными данными) то вы еще и под PCIDSS попали, со всеми вытекающими…

Платежный шлюз, как правило, предоставляет SDK|приложение для ридера и для интеграции со шлюзом — т.е. приложению нужна интеграция (простая) с SDK от платежного шлюза.

Тот же SDK/приложение может также содержать интеграцию с нужным фискальным принтером.

Т.е. вы просто кидаете сумму и описание платежа в SDK|приложение, а в ответ получаете информацию о проведенном платеже (при этом принтер печатает фискальный чек) или об ошибке, а все fallback-и приличные интеграторы прописывают уже внутри своего sdk|приложение.

То есть просто купить на рынке кард-ридер и читать информацию с карты не получится, как я понял :( У нас сейчас проблема в том, что не можем придумать надежный и безопасный способ передачи информации о карте клиента платежному шлюзу с девайса оператора. С девайса клиента решили вопрос — во фрейме окно шлюза, куда клиент вводит номер карты и CVC, а шлюз передаёт нам токен для дальнейшей работы с картой. Но то же самое сделать в приложении для наших операторов смысла не видим по психологическим причинам — есть подозрение, что мало кто из клиентов захочет вводить номер и CVC в приложении на чужом девайсе, а вот к кард-ридерам народ привычный.

На рынке вам никто и не продаст кард-ридер, если только на черном…
Ридер можно купить (официально у поставщиков), но есть одно «НО». Там ключи которые прописывает производитель и этими ключами можно расшифровать пакет с ридера. И там будет вся инфа с карты — только вот вам в таком случае надо свое приложение и вашу организацию проводить через PCI DSS аудит. А шлюз (обычно) может принять и карточные данные (в открытом виде).

Но транзакция может идти в разных режимах — если проверка PIN идет в ридере (на самой карте), то там только криптограмму специальную надо передать вместе с данными карты (по сути это подтверждение проведения аутентификации плательщика устройством). Но если требуется проверка через банк эмитетнт, то тут уже идет PIN блок (шифрованный). Только вот PIN блок — его раскрывать — еще более строгий и дорогой уровень сертификации. А без PIN — только оплата по NFC на сумму не выше 1000р.

В общем тут очень много нюансов. И если не охота с этим возится то лучше купите решение от шлюза. Сейчас все нормальные шлюзы предлагают решения для мобильной торговли (с кард-ридером и без необходимости серьезной сертификации клиентского приложения ибо через него все карточные данные идут в закриптованном виде, расшифровываются только на стороне шлюза). Если ваш шлюз не предлагает мобильного решения — переходите к другому.
В реальности все куда дольше, и вы сами прекрасно знаете почему.
А действительно, почему — автоматизации нет? А если же просто хозяин проката не уважает клиентов? — тогда автоматизация тут не поможет — хозяин урежет (экономия!!) ещё какой-то ресурс, и всё вернётся на круги своя.
а когда был сдан этот проект?
А то ведь 58ФЗ уже начал помаленьку работать, а там уже кассы без фискального накопителя. А с отправкой данных на сервер провайдера фискальных данных.
т.е технически хорошее решение — экономически не понятно
54-ФЗ. Как раз теперь в ККТ или в фискальных регистраторах будут фискальные накопители. Раньше было ЭКЛЗ.
Схему представленную в статье показывали на конференции Атол.
Насколько я помню решение для курьерских служб и разъездной торговли.
В нашем случае соблюдение новых требований по фискальному учету ложится на плечи эквайрингового оператора — iBox предоставили нам и картридеры, и фискальники, и сейчас обновляют принтеры под соответствие обновленным правилам 54-ФЗ. Если бы не ребята, нам (в смысле заказчику) пришлось бы все обновлять самим, а тут «полный сервис».
какой-то странный у вас flow

мой опыт
неделю назад бы на покатушках
в кассе обычный кассовый аппарат с терминалом для карточек
1 заплатил за скипас и аренду амуниции
2 получил чек со штрихкодом

аренда, там стоят терминалы
3 завел свой аккаунт по номеру прав (можно и по кредитке)
4 отсканировал код с чека
5 указал рост, размер обуви, вес
6 распечатал бумагу с кодами на аренду
7 по этой бумаге получил шлем и боты
8 проверил боты по ноге
9 получил лыжи по бумаге
какой-то странный у вас flow

вполне распространенный вариант
думаю что связано с тем, что в выходные/праздничные запросто может не быть нужного размера, а списать деньги а потом отправить клиента за возвратом как-то не очень
Спасибо! Полезно! обновим в статье, с Вашего позволения. Ваша библиотека с документацией будет более понятна.
С понедельника начну интеграцию печати из android-приложения на вот такую беду… не спрашивайте почему именно такой, шеф пришел, сгрузил, дал цу разобраться и интегрировать печать -_-
Про почему спрашивать не будем. Всякое бывает :) Просто напомним про то, что если вы собираетесь эту штуку применять в России для печати чеков, вам нужен фискальник. Да не простой, а соответствующий обновленным требования 54-ФЗ, как верно заметили bi4ara и RuJet. А ваш судя по краткому описанию, не таков. За рубежом таких проблем нет. Сами делали зарубежный проект, и простой термопринтер закрывал все наши потребности.
Не РФ, живу и работаю в маленьком огрызке земли недогосударстве ПМР, что между Молдовой и Украиной. Что самое не позитивное в задании, так это полная неопределенность в целях использования, они ещё сами не знают зачем им нужна печать =\ Может так случиться, что будет «разберись — разобрался — интегрируй — интегрировал — полежало — ну… ладно, это нам не надо, выпиливай из проекта»)
Sign up to leave a comment.