Нужна, когда требуется простейшая интеграция, которая не предусматривает какого-то глубокого прямого взаимодействия iikoWaiter и системы лояльности.
Ограничение такого варианта интеграции:
- в момент чекина не делается проверка валидности карты. Она будет выполняться уже момент попытки на iikoFront, например, рассчитать по ней заказ и тогда может оказаться, что она заблокирована.
При такой интеграции, если номер карты не существует в базе гостей БРД, то гость с такой картой будет создан автоматически с названием в формате Карта № NNNNNNN.
Отсканированное значение кладется в externalData по ключу: "arbus.iikowaiter.checkinscannedvalue"
Content-Type | application/json |
---|---|
ExternalData key | iikowaiter5.paymentItems |
API Method | PluginContext.Operations.TryGetOrderExternalDataByKey(orderId, Key) |
Версия плагина iikoWaiter5 | 7.8.3+ |
Property | Type | Description |
---|---|---|
PaymentItems | List<PaymentItem> | Список всех добавленных к заказу PaymentItems. |
Property | Type | Description |
---|---|---|
PaymentType | PaymentType | Тип платёжной системы. |
Sum | decimal | Сумма платежа. |
Property | Type | Description |
---|---|---|
Id | Guid | Id платежной системы |
Kind | PaymentTypeKind (enum) | |
Name | string | Имя платёжной системы. |
Unknown = 0, Cash = 1, BankCard = 2, IikoCard5Bonus = 3, IikoCard5Deposit = 4, ExternalLoyaltyBonus = 5, ExternalLoyaltyDeposit = 6 |
Со стороны системы лояльности интеграция с iikoFronte реализуется в виде фронтового плагина. Основывается на возможностях iikoFrontAPI v5+. В заказе можно хранить произвольные внешние данные, там общий на весь заказ словарик ключ-значение. Обоим плагинам надо заранее договориться об имени ключа (строка) и формате значения (строка). Первый плагин записывает код подарка с помощью AddOrderExternalData, а второй считывает с помощью TryGetOrderExternalDataByKey. Тогда сценарий такой:
|