-
#1
Стала выпадать в iikoFront ошибка:
[2022-10-24 18:17:00,180] INFO [53] [MessageService:Add:108] — Message: Dual Connector: операция не выполнена. Причина: «Операция обмена завершилась с ошибкой!
Код ошибки: 13
Описание: Connection error. «, Sender: Dual Connector, Type: Error, ReceiveTime: 10/24/2022 18:17:00, ExpireTime: 10/25/2022 06:17:00
Ошибка возникала, когда клиент прикладывал банковскую карту к терминалу оплаты. Причем этобыло не всегда, а рандомно.
Что на данный момент помогло решить вопрос:
Был обновлен сам Dual Connector, а потом драйвера пин пада.
Далее, в самом терминале оплаты (терминал оплаты подключен к кассе по USB, в моем случае) проверяем:
- Жмем 1
- Выбираем Параметры
- Выбираем пункт: Редактирование
- Выбираем пункт: SMARTSALE
- Выбираем пункт: Связь с банком
- Выбираем Через кассу
Коды ответов
Результатом выполнения и критерием успешности любой операции является Код ответа (Responce Code (RC)). В рамках протокола ISO 8583 он передается в поле 39 ответного сообщения. Формат RC зависит от версии ISO 8583: в версии ISO 8583:1987 он двузначный, в версии ISO 8583:1993 — трехзначный. Главным образом будем рассматривать обмен в рамках версии 1987 г., по причине ее большей распространенности. При этом заметим, что каждый конкретный разработчик ПЦ использует различные подходы к обеспечению совместимости между версиями: какие-то хосты передают в рамках P2H три символа RC, при этом, в случае если обмен выполняется в рамках версии 1987 г., заполняя лидирующий символ (первый слева) нулем. В других случаях ПЦ выполняет конвертацию трехзначного RC версии 1993 г. — в его двузначный эквивалент версии ISO 8583:1987 и в таком виде отправляет его на POS.
Коды ответов можно разделить на успешные и негативные. Негативным является любой ответ, кроме явного ответа «Одобрено» либо его семантического эквивалента. При этом причиной может быть как техническая ошибка, так и отказ эмитента в выполнении той или иной операции.
Ниже приведем наиболее распространенные RC, разбив их на две условные группы — Технические и Сервисные.
Технические RC
В это группу включим основные коды ответов, полученные в результате тех или иных технических сбоев, либо ошибок при заполнении сообщения. Заметим, что вариативность причин возникновения любого их описанных ниже RC более или менее широка, и в рамках материала дана исключительно в целях примера.
00 — Approved (Одобрено). Транзакция завершена успешно.
12 — Invalid Transaction (Неверная транзакция). Неверны какие-либо параметры транзакции. Допустим, поля сообщения заполнены таким образом, что из них следует, что операция Выдача наличных выполняется в торговом POS-терминале. Что, в общем случае, недопустимо.
13 — Invalid Amount (Неверная сумма). Поле 4 (Сумма) заполнено неверным значением. Данный RC может возникнуть в случае срабатывания какого-либо лимита, либо в рамках операций, подразумевающих предварительную авторизацию с ее последующим завершением (например, предварительное бронирование услуг с последующим расчетом).
14 — Invalid Card Number(Неверный номер карты). Неверно заполнено поле 2 (Номер карты), либо имеет место быть попытка выполнить транзакцию по карте, отсутствующей в базе данных эмитента.
15 — Invalid Issuer (Неверный эмитент). Такой RC обычно отправляется авторизационной платформой ПС и говорит о том, что маршрут отправки операции эмитенту не найден (в большинстве случаев, по причине неверного БИНа карты).
30 — Format Error (Ошибка формата данных). Возникает в результате тех или иных ошибок при заполнении сообщения в рамках определенного диалекта. Например, какое-либо поле превышает допустимое количество символов, либо вообще отсутствует, либо заполняется в неверном формате и/или кодировке. При этом ряд ПС, в случае отправки данного RC, направляет в ответном сообщении дополнительное поле с конкретным указанием на ошибочный элемент входящего сообщения.
88 и 89 — Cryptographic Failure (Криптографическая ошибка). Транзакция отклонена по причине ошибок криптографии. К примеру, таких как, ошибка шифрования пинблока, ошибка проверки цифровой подписи и других.
96 — System Error (Системная ошибка). В общем случае ошибка свидетельствует о том, что произошел сбой на каком-либо из этапов обмена. Как правило, в рамках ПЦ эквайрера, однако нам известны случаи, когда данный RC передавался и в рамках H2H.
Сервисные RC
К сервисным RC можно отнести коды ответов по операциям в рамках которых отсутствовали технические ошибки, а отказ был получен по причине ограничений доступа к тому или иному сервису со стороны эмитента или ПС, либо других условий, не связанных с техническими проблемами.
00 — Approved (Одобрено). Транзакция завершена успешно.
01 — Refer to Call Issuer (Позвоните эмитенту). Для завершения транзакции необходимо связаться с эмитентом.
04 — Capture Card (Изъять карту). Эмитент или ПС направил команду на изъятие карты.
05 — Do Not Honor (Не оплачивать). Отказ без объяснения причины. В подавляющем большинстве случаев такой RC отправляется эмитентом. Причины также следует уточнять у эмитента.
41 — Lost Card (Карта утеряна). Попытка выполнить операцию по карте, помеченной в БД эмитента или ПС как утерянная.
43 — Stolen Card (Карта украдена). Попытка выполнить операцию по карте, помеченной в БД эмитента или ПС как украденная.
51 — Not Sufficient Funds (Недостаточно средств). Сумма операции превышает сумму доступных средств на карточном счете.
52 и 53 — No Checking/Saving Account. Попытка выполнить операцию с неверным карточным счетом.
54 — Expired Card (Карта просрочена). Попытка выполнить операцию по карте с истекшим сроком действия.
55 — Incorrect PIN (Неверен пин). При выполнении операции с онлайн-пинкодом он был введен некорректно.
57 — Transaction Not Permitted to Issuer/Cardholder (Транзакция не разрешена для Эмитента/Держателя карты). Попытка выполнить операцию, не разрешенную для конкретного эмитента или держателя карты.
58 — Transaction Not Permitted to Acquier/Terminal (Транзакция не разрешена для Эквайрера/Терминала). Попытка выполнить операцию, не разрешенную для конкретного эквайрера или терминала.
Таков список наиболее часто встречающихся кодов ответа, имеющих одинаковые значения для всех ведущих ПС. Заметим, что их число несколько шире и варьируется в зависимости от конкретного диалекта ПС. Например в рамках спецификации Visa могут присутствовать RC, отсутствующие у Mastercard, и наоборот.
Оффлайновые коды ответов
В общих чертах следует коснутся и оффлайновых RC. К ним относятся коды, сгенерированные программным обеспечением POS-терминала. Поскольку в данном случае обмен выполняется не в рамках ISO 8583, а условия возникновения таких RC наступают в процессе т.н. EMV Transaction Flow, ограничимся общим описанием (Вопросы APDU/EMV-обмена будут подробно освещены в будущих материалах).
Z1 — OFFLINE DECLINED (Отклонено оффлайн). Было принято решение отклонить транзакцию, не отправляя онлайн-сообщение.
Z3 — NO ONLINE, DECLINED (Нет связи, отклонено оффлайн). POS-терминал предпринял попытку отправить онлайн-запрос, которая закончилась неудачно по причине отсутствия связи. В оффлайне транзакция отклонена.
Y1 — OFFLINE APPROVED (Одобрено оффлайн). Транзакция одобрена без онлайн-обращения к эмитенту. Справедливо для терминалов, поддерживающих оффлайн-транзакции.
Y3 — NO ONLINE, APPROVED (Нет связи, одобрено оффлайн). POS-терминал предпринял попытку отправить онлайн-запрос, которая закончилась неудачно по причине отсутствия связи. В оффлайне транзакция была одобрена. Справедливо для терминалов, поддерживающих оффлайн-транзакции.
SMS-информирование
Достаточно популярная ныне услуга SMS-информирования используется многими держателями карт. Помимо очевидного удобства, являясь в ряде случаев причиной споров, а иногда и скандалов между мерчантом и кардхолдером. Рассмотрим наиболее типичный случай:
- Клиент расплачивается картой.
- Получает SMS о списании суммы услуги/покупки.
- Терминал не печатает чек/зависает/перезагружается.
- Мерчант не имеет на руках успешного чека по операции.
- Клиент утверждает, что операция успешна, при этом ссылается на SMS.
Дальнейший сценарий развития событий зависит от опытности персонала ТСП и многих других факторов.
Первое и самое важное, что следует принимать во внимание в такой ситуации: критерием успешности операции по карте является чек (либо, если речь идет об одобренных ПС терминалах, не оснащенных чековым принтером — его электронный эквивалент), содержащий успешный код ответа и/или его расшифровку. Никакие SMS, полученные клиентом, критерием успешности операции не являются. Ни один диспутный цикл ни по одной претензии не будет рассматривать полученное кардхолдером SMS в качестве аргумента. Основная причина состоит в том, что такая услуга как SMS-информирование никак не специфицирована со стороны ПС. То есть, технические инструменты, в том числе и протоколы/формат обмена, которыми она достигается, зависят от каждого конкретного эмитента. В том числе, может быть реализована и с помощью различных самописных решений. В общем случае, некий условный «SMS-сервер» анализирует запросы к карточному контракту и фиксирует изменения его доступного остатка. Помимо этого, в большинстве случаев могут анализироваться поля 41 (Идентификатор Терминала (Terminal ID)), 42 (Идентификатор Мерчанта (Merchant ID)) и 43 (Имя и местонахождение мерчанта (Card Acceptor Name/Location)) из входящего запроса от эквайрера. Затем эти данные вносятся в «тело» SMS-сообщения и отправляются на номер телефона, который кардхолдер указал при выпуске карты. На выходе получается SMS-сообщение примерно такого формата: «КАРТА, ДАТА/ВРЕМЯ, Тип операции, Сумма, НАИМЕНОВАНИЕ ТСП, ДОСТУПНЫЙ ОСТАТОК».
Подчеркнем ряд важных моментов: фактически, принцип функционирования SMS-сервера базируется на срабатывании триггеров. При этом он может быть настроен на срабатывание при выполнении операции Оплата, но не срабатывать на операцию Отмена оплаты; далее, SMS-сервер ничего «не знает» про состояние каналов связи в момент выполнения операции. Соответственно, не способен «понять», был ли ответ на авторизацию успешно доставлен на POS-терминал. Сумма и комбинации всех этих факторов, а также отсутствие регламентов со стороны ПС, делают SMS-инфо крайне ненадежным источником. Этот факт необходимо учитывать как мерчантам, так и кардхолдерам. Безусловно, качество предоставления такой услуги, как SMS-информирование в последние годы существенно возросло. Однако это не отменяет сказанного выше.
Не указывается базовая единица измерения
Во время создания карточки товара обязательно нужно указывать базовую единицу измерения. Она является основной единицей измерения и используется во всех техкартах и документах.
Если за единицу измерения товара применяются не килограммы, а, например, штуки, то нужно дополнительно указать вес одной базовой единицы. Это делается в поле “Суммарный фактический выход на 1 норму закладки (вес 1 единицы измерения)”. По умолчанию это поле имеет нулевое значение, а если его не изменить, вхождение этого товара в техкартах по весу брутто будет оставаться нулевым.
Незаполненный вес одной единицы не считается ошибкой, когда товар при списании не должен добавлять вес блюду. Например, бумажный стаканчик для кофе.
Ошибки при заведении приходных накладных
При заведении приходной накладной товар можно указывать как в базовых единицах измерения, так и с помощью фасовок, указанных на товаре.
Часто сотрудники меняют в накладных единицу измерения и начинаются расхождения, так как они не обращают внимание на уже указанные значения.
Например, ресторан получил 2 банки маслин по 720 грамм. Фактический вес в базовых единицах измерения — 1,1 кг. Себестоимость одной банки — 816 рублей. Сотрудник во время приемки решил, что будет лучше заводить товар в килограммах, изменил фасовку, но не изменил вес товара. В итоге в систему поступило 2 кг маслин, вместо 1,1 кг. В итоге уменьшилась себестоимость товара, а в будущем склад выявит недостачу. Неправильно рассчитанная себестоимость снизит прибыль, так как наценка будет рассчитана по ошибочным значениям себестоимости.
Для профилактики ошибки советуем регулярно проводить инвентаризацию остатков на складе и следить за отчетом об изменении себестоимости. При выявлении ошибок в накладных необходимо производить корректировку документа.
Ошибки при составлении технологических карт
В технико-технологической карте (ТТК) задается состав блюда, технология приготовления, норма закладки и фиксируется акт его проработки. На основании указанных значений норм закладки будет происходить списание ингредиентов на приготовление блюда.
По умолчанию в техкарте значение нормы закладки равно 1, то есть расчеты производятся для одной базовой единицы измерения. Если указанное количество ингредиентов рассчитано для большего количества порций, необходимо изменить значение нормы закладки.
Часто про норму закладки вообще забывают, и в итоге списывается неправильное количество ингредиентов. Это приводит к недостачам и излишкам на складе и увеличению себестоимости.
Чтобы не допускать такую ошибку, необходимо всегда проверять норму закладки, если техкарта составлена не на один килограмм или порцию.
Не указывается процент потерь в техкартах
Потери продуктов при обработке тоже учитываются и отображаются в техкартах. Причем указываются потери по каждому ингредиенту с учетом вида обработки (жарка, варка, разморозка и т.д.)
В техкартах все ингредиенты указываются неочищенными и без обработки (брутто). Потери указываются для холодной и горячей обработки отдельно. Они нужны, чтобы понимать среднее значение потерь на кухне, для расчета выхода продукта (точный вес заготовки или блюда), а также для получения точного расчета калорийности.
Калорийность рассчитывается на вкладке Пищевая ценность. Для ее расчета нужно указать потери при горячей и холодной обработке и способ приготовления.
Неправильно указан метод списания ингредиентов в ТТК
Свои техкарты есть у блюд, заготовок и модификаторов. По нормам закладки, указанным в ТТК, списываются ингредиенты со склада.
Виды списаний:
- списание ингредиентов: ингредиенты, использованные при приготовлении блюда, спишутся только после его продажи. При этом методе списания количество блюд и заготовок не учитывается, а вся аналитика по количеству проданных блюд будет доступна только после продажи.
- списание готового блюда: используется, если нужен учет готовых блюд или изделий. В этом случае ингредиенты списываются со склада для приготовления, а затем готовое блюдо поступает на склад и списывается после продажи.
При использовании второго варианта списания часто забывают создать акт приготовления. В итоге блюдо приготовлено, ингредиенты списаны, а остаток у готового блюда не увеличился, что приводит к появлению минусовых остатков.
Чтобы избежать возникновение такой ситуации, нужно правильно указывать способ списания и не забывать создавать акты приготовления, если нужен учет готовых блюд.
Ошибки при инвентаризации
Во время инвентаризации часто возникают ошибки с фасовками. В документ инвентаризации можно заводить продукт в базовых единицах или в фасовках.
Например, маслины учитываются в кг, и в документ инвентаризации нужно заводить остатки в кг.
В зависимости от того, как маслины хранятся на складе, их могли завести в документ в штуках. Ошибка возникает, если вес в фасовке установили (например, 1 шт. равна 720 гр.), но не изменили значения в базовых единицах. В результате расхождения возникают уже сразу после проведения инвентаризации.
Если в документе инвентаризации нужно указать товар в штуках, а базовая единица отличается (например, килограммы или граммы), то нужно обязательно указывать количество штук в графе Тара. Это нужно для того, чтобы программа сама пересчитала вес в базовых единицах.
Чтобы не допустить такую ошибку, важно следить за тем, что принято за базовую единицу для продукта, и в каких единицах товар заносится в документ.
Не ведется списание брака и испортившихся продуктов
Во время приемки товара не всегда получается отследить качество продуктов. На дне ящика могут оказаться подгнившие овощи или зелень уже начинает увядать. Весь брак нужно не принимать и возвращать поставщику.
Такие товары будут находиться на остатках, но отпускать их в производство нельзя. Их нужно списывать, чтобы учет был более точным.
Акты списания помогают понять причины потерь и усилить контроль за проблемными зонами. Нужно учитывать всю порчу в торговой точке и вовремя ее списывать, чтобы она не попала в производство. Неправильные остатки также повлияют на заказ у поставщика, из-за чего возрастает вероятность, что каких-то продуктов не хватит.
Мы рассмотрели популярные ошибки складского учета в iiko. Если вы сомневаетесь в правильности ведения учета в вашем заведении, оставляйте заявку. Специалисты ДЕНВИК проведут бесплатный аудит складского учета, который вы ведете в iiko, и подготовят рекомендации по улучшению.
Нужен аудит
Описываю информацию:
Есть сервер с БД, на нем же и работают в iikoOffice.
На кассе стоит iikoFront и к ней подключены: терминал оплаты (альфа) + фискальный регистратор (АТОЛ FPrint-22ПТК).
Версия iiko: 6.2.2015.0
Касса одна.
[2022-10-24 18:17:00,180] INFO [53] [MessageService:Add:108] — Message: Dual Connector: операция не выполнена. Причина: «Операция обмена завершилась с ошибкой!
Код ошибки: 13
Описание: Connection error. «, Sender: Dual Connector, Type: Error, ReceiveTime: 10/24/2022 18:17:00, ExpireTime: 10/25/2022 06:17:00
[2022-10-25 16:30:16,272] ERROR [65] [PaymentScreenController:PaymentOperationFailed:202 7] — Payment operation failedResto.Framework.Common.RestoException: Операция не выполнена:
Код ошибки:OperationIsInterrupted
Описание: ПРЕРВАНО
Подробно: ОПЕРАЦИЯ ПРЕРВАНА —> Resto.Front.Api.V5.Exceptions.PaymentActionFailedE xception: Операция не выполнена:
Код ошибки:OperationIsInterrupted
Описание: ПРЕРВАНО
Подробно: ОПЕРАЦИЯ ПРЕРВАНА
Server stack trace:
в Resto.Front.Api.PaymentSystem.DualConnector.DualCo nnectorOperationHelper.CheckOperationResult(Operat ionData operationData) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.Front.Api.Paymen tSystem.DualConnectorDualConnectorOperationHelper .cs:строка 43
в Resto.Front.Api.PaymentSystem.DualConnector.DualCo nnectorPlugin.CompleteOperation(Pair`2 result, IReceiptPrinter printer, IUser cashier) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.Front.Api.Paymen tSystem.DualConnectorDualConnectorPlugin.cs:ст� �ока 170
в Resto.Front.Api.PaymentSystem.DualConnector.DualCo nnectorPlugin.Pay(Decimal sum, Nullable`1 orderId, Guid paymentTypeId, Guid transactionId, IPointOfSale pointOfSale, IUser cashier, IReceiptPrinter printer, IViewManager viewManager, IPaymentDataContext context, IProgressBar progressBar) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.Front.Api.Paymen tSystem.DualConnectorDualConnectorPlugin.cs:ст� �ока 136
в System.Runtime.Remoting.Messaging.StackBuilderSink ._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
в System.Runtime.Remoting.Messaging.StackBuilderSink .SyncProcessMessage(IMessage msg)
Exception rethrown at [0]:
в System.Runtime.Remoting.Proxies.RealProxy.HandleRe turnMessage(IMessage reqMsg, IMessage retMsg)
в System.Runtime.Remoting.Proxies.RealProxy.PrivateI nvoke(MessageData& msgData, Int32 type)
в Resto.Front.Api.V5.IExternalPaymentProcessor.Pay(D ecimal sum, Nullable`1 orderId, Guid paymentTypeId, Guid transactionId, IPointOfSale pointOfSale, IUser cashier, IReceiptPrinter printer, IViewManager viewManager, IPaymentDataContext context, IProgressBar progressBar)
в Resto.Front.Api.V5.Payment.PaymentProcessorWrapper .Pay(Decimal sum, Nullable`1 orderId, Guid paymentTypeId, Guid transactionId, IPointOfSale pointOfSale, IUser cashier, IPluginPrinter printManager, PluginViewManager viewManager, IPluginPaymentDataContext paymentContext, IPluginProgressBar progressBar) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.Front.ApiV5Pay mentPaymentProcessorWrapper.cs:строка 50
в Resto.Front.Api.ApiExtensionsService.PerformPaymen tAction(IExternalPaymentItem item, String key, Decimal sum, Nullable`1 orderId, Guid transactionId, ICashRegister cashRegister, IUser cashier, ActionType type, Action`1 changeProgressBarMessage) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.Front.ApiApiExt ensionsService.cs:строка 116
— Конец трассировки внутреннего стека исключений —
в Resto.Front.Api.ApiExtensionsService.PerformPaymen tAction(IExternalPaymentItem item, String key, Decimal sum, Nullable`1 orderId, Guid transactionId, ICashRegister cashRegister, IUser cashier, ActionType type, Action`1 changeProgressBarMessage) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.Front.ApiApiExt ensionsService.cs:строка 155
в Resto.Front.Api.ApiExtensionsService.Pay(IExternal PaymentItem item, String key, Decimal sum, Nullable`1 orderId, Guid transactionId, ICashRegister cashRegister, IUser cashier, Action`1 changeProgressBarMessage) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.Front.ApiApiExt ensionsService.cs:строка 62
в Resto.CashServer.PaymentSystem.ExternalPaymentItem .PerformTransaction(IBaseOrderBuilder orderBuilder, ILockedObjectsToken token, ICafeSession cafeSession, IUser cashier, Action`1 changeProgressBarMessage) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.CashServerPayme ntSystemExternalPaymentItem.cs:строка 34
в Resto.CashServer.PaymentSystem.CardPaymentItem`1.E xecuteProcessingOperation(IBaseOrderBuilder orderBuilder, ILockedObjectsToken token, ICafeSession cafeSession, IUser cashier, Action`1 changeProgressBarMessage) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.CashServerPayme ntSystemCardPaymentItem.cs:строка 167
в Resto.CashServer.PaymentSystem.PaymentItem.Process (IBaseOrderBuilder orderBuilder, ILockedObjectsToken token, ICafeSession cafeSession, IUser cashier, Action`1 changeProgressBarMessage) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.CashServerPayme ntSystemPaymentItem.cs:строка 227
в Resto.CashServer.Services.OrderService.ProcessPaym entsItems(IBaseOrderBuilder orderBuilder, IUser cashier, ILockedObjectsToken token, ICafeSession cafeSession, Action`1 changeProgressBarMessage) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.CashServerServi cesOrderService.cs:строка 1271
в Resto.CashServer.Services.OrderService.ProcessOrde rClose(IBaseOrderBuilder orderBuilder, ICafeSession cafeSession, IOrderCloseParameters closeParameters, ILockedObjectsToken token, Action`1 changeProgressBarMessage) в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.CashServerServi cesOrderService.cs:строка 503
в Resto.Front.Controllers.PaymentScreenController.<> c__DisplayClass75_0.<CloseOrder>b__3() в I:BuildAgentworkrelease-installerdeviikoFront.NetResto.Front.Controller sPaymentScreenController.cs:строка 1510
в System.Threading.Tasks.Task.InnerInvoke()
в System.Threading.Tasks.Task.Execute()
Для ФастФуда
Как правило такой вариант работает только в форматах быстрого обслуживания.
Пример использования iikoCheckOut
Лицом к клиенту стоит банковский терминал. Кассир на терминале системы автоматизации указывает, что оплата производится банковской картой.
Банковский терминал активируется и предлагает клиенту провести процедуру оплаты.
Клиент сам вставляет карту, вводит ПИН-код, дожидается ответа о выполнении операции и забирает свою карту.
Заказ в системе автоматизации автоматически закрывается и оплачивается.
Сотрудники банка настраивают эквайринг терминал на вашем кассовом терминале для работы по одному из протоколов (указанных ниже) и предоставляет нам параметры для его подключения. После чего наши специалисты настраивают связку эквайринга и iiko.
Необходимо, что бы обмен эквайринга с iiko был организован по одному из протоколов:
- INPAS SmartSale — соответсвует текущим требованиям PCI DSS
- TRPOS — соответсвует текущим требованиям PCI DSS
- Сбербанк (sbrf) соответсвует текущим требованиям PCI DSS
- Аркус (arcus)
- INPAS DualConnector
- UcsPaymentSystem (протокол EFTPOS)
Для Ресторана
Во всех трех примерах ниже, операция оплаты сначала проводится на банковском терминале, а затем в системе автоматизации с указанием типа оплаты банковская карта. В таком случае терминал и система автоматизации — не связанны между собой.
Дополнительных лицензий не требуется.
- Гость сидя за столиком ресторана получает счет, подкладывает в счет свою банковскую карту. Папку со счетом забирает официант, передает кассиру и кассир выполняет оплату.
- Гость сидя за столиком ресторана получает счет, сообщает официанту, что оплата картой, официант приносит переносной банковский терминал, вставляет карту гостя в него, гость подтверждает оплату вводом ПИН-кода. После этого официант забирает все чеки, передает их кассиру и кассир закрывает стол в системе автоматизации.
- Гость передает карту кассиру, кассир проводит оплату, клиент подтверждает оплату вводом ПИН-кода на специальном пин-паде лежащем рядом с ним.[/qodef_unordered_list]