ТИПЫ ИНТЕРФЕЙСОВ
Назначение, использование, особенности
ТИПЫ ИНТЕРФЕЙСОВ
Назначение, использование, особенности
ОБЗОР ТИПОВ ИНТЕРФЕЙСОВ
ВЫБОР ТИПА ИНТЕРФЕЙСА
ИСПОЛЬЗОВАНИЕ
ДОСТАВКА БИЛЕТОВ
ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ
Изначально, в платформе BIL24 существовали два базовых типа интерфейсов - «Браузер» и «Билетная система». Типы интерфейсов, «Android» и «IOS» являются незначительно измененными вариантами интерфейса «Браузер»
и на сегодняшний день устарели. Тип интерфейса «Новая касса» создан на основе типа «Билетная система» для продажи билетов в традиционных кассах. В июле 2023 года в платформе появился новый тип интерфейса
«Билетный агент», сочетающий в себе свойства обоих базовых типов, и удобный для решения определенного круга задач.
Типы интерфейсов различаются подходом к реализации следующих задач:
1. Использование интернет-эквайринга.
2. Использование процессинга.
3. Авторизация покупателей билетов.
4. Выдача чеков и билетов покупателям.
Интерфейс типа «Браузер» использует все возможности платформы BIL24: полную авторизацию покупателей билетов, подключенный в платформе интернет-эквайринг агента (организатора), процессинг платформы,
выдача чеков и билетов по email. С помощью этого типа интерфейса пользователь платформы использует для продажи билетов, товаров и услуг весь её функционал.
Интерфейс типа «Билетная система» подразумевает наличие у пользователя BIL24 собственной полнофункциональной билетной системы (внешней по отношению к BIL24) , с собственным процессингом,
интернет-эквайрингом, с функционалом авторизации пользователей, с системой выдачи чеков и билетов. Об устройстве этой системы BIL24 ничего не известно. Таким образом, покупателей по большей части обслуживает
собственная система пользователя, а BIL24 является источником «товара»: мест, билетов, товаров и услуг.
Интерфейс типа «Билетный агент» сочетает возможности типов «Браузер» и «Билетная система». Также как и тип «Браузер», этот интерфейс использует процессинг и интернет-эквайринг из BIL24, а авторизация покупателей,
выдача им чеков и билетов происходит в собственной системе пользователя. Например, если у пользователя платформы BIL24 на собственном сайте есть своя система учета покупателей, с авторизацией и личным кабинетом,
но при этом у него нет собственного процессинга с подключенным к нему интернет-эквайрингом, то такому пользователю идеально подходить тип «Билетный агент».
Интерфейс типа «Новая касса» используется для продажи билетов в традиционных кассах за наличные деньги или через POS-терминал. Покупатели в кассах не нуждаются в авторизации, тогда как для кассира необходим
учет смен и выручки.
Решить, какой тип интерфейса использовать, необходимо на старте проекта интеграции с BIL24, еще до начала реализации API платформы. Выбор типа интерфейса зависит, прежде всего от того, где будет использоваться интернет-эквайринг: в платформе BIL24 или в собственной билетной системе пользователя. Затем необходимо учесть, в какой системе будут авторизоваться пользователи. Выбор типа интерфейса проиллюстрирован на рис.1:
рис.1
При выборе типа интерфейса стоит учитывать, что BIL24 представляет собой конструктор, который позволяет организовать интеграцию и продажу билетов различными способами.
Базовый порядок использования команд API для покупки билетов отличается для интерфейсов разных типов.
Порядок для интерфейса типа «Билетная система»:
1. Если покупатель новый (его данных нет в собственной системе пользователя), то необходимо выполнить команду CREATE_USER и сохранить в собственной системе
параметры userId и sessionId (приходят в ответе). Если данные пользователя уже есть в системе, то можно переходить к п.2.
2. Выполнение команды RESERVATION для бронирования мест.
3. Выполнение команды CREATE_ORDER_EXT для создания заказа.
4. Выполнение команды PAY_ORDER для информирования BIL24 о том, что заказ оплачен внутри собственной системы пользователя.
Порядок для интерфейса типа «Браузер»:
1. Для покупки билетов через интерфейс типа «Браузер» пользователя необходимо авторизовать. В платформе реализованы две версии авторизации – версия 1.0 и версия 2.0.
Авторизация по версии 1.0 подразумевает использование команд AUTH, BIND_EMAIL,
CONFIRM_EMAIL и является устаревшей. Рекомендуется использовать авторизацию 2.0.
2. Выполнение команды RESERVATION для бронирования мест.
3. Выполнение команды CREATE_ORDER для создания заказа с билетами. В ответе команды будет параметр formUrl - ссылка на страницу оплаты в интернет-эквайринге банка. Необходимо направить покупателя по этой ссылке, где он сможет ввести данные своей карты и оплатить заказ. В параметрах команды присутствуют две ссылки для редиректа покупателя после попытки оплаты заказа: successUrl - после успешной оплаты, failUrl – после НЕуспешной оплаты. Банк самостоятельно выполнит редирект в соответствии с результатом операции.
Порядок для интерфейса типа «Билетный агент»:
1. Если покупатель новый (его данных нет в собственной системе пользователя), то необходимо выполнить команду CREATE_USER и
сохранить в собственной системе параметры userId и sessionId (приходят в ответе). Если данные покупателя уже есть в системе, то можно переходить к п.2.
2. Выполнение команды RESERVATION для бронирования мест.
3. Выполнение команды CREATE_ORDER для создания заказа с билетами. В ответе команды будет параметр formUrl -
ссылка на страницу оплаты в интернет-эквайринге банка. Необходимо направить покупателя по этой ссылке, где он сможет ввести данные своей карты и оплатить заказ.
В параметрах команды присутствуют две ссылки для редиректа покупателя после попытки оплаты заказа: successUrl - после успешной оплаты, failUrl – после НЕуспешной оплаты.
Банк самостоятельно выполнит редирект в соответствии с результатом операции.
В настоящий момент платформа BIL24 доставляет билеты на email покупателя. В разработке сервис доставки билетов через Whatsapp и Telegram. Доставка билетов «по
умолчанию» действует только для интерфейсов типа «Браузер». У покупателей, созданных через интерфейсы «Билетная система» и «Билетный агент», подтвержденных адресов
email в платформе BIL24 нет, и доставкой билетов должна заниматься собственная система пользователя. То есть при применении интерфейсов «Билетная система» и
«Билетный агент», билеты НЕ отправляются на адрес покупателя, даже если он указан в поле email команды CREATE_ORDER_EXT.
Тем не менее, у Агента, использующего интерфейс этого типа, есть возможности отправить билеты покупателю с помощью команды SEND_TICKETS_TO_EMAIL
и/или создать файл с билетами командой PRINT_TICKETS.
Адреса email хранятся в платформе в двух объектах: Пользователь и Заказ. В объекте Пользователь хранится подтвержденный email покупателя (только для покупателей, прошедших авторизацию
через интерфейс типа «Браузер»). Этот email используется при оформлении заказа с билетами, и сохраняется в объекте Заказ. В отличие от email в объекте Пользователь , адрес email в Заказе
может быть изменен, например, при пересылке заказа на другой email в приложении Отчеты (Reporter).
Множество клиентов BIL24 используют различные способы интеграции с платформой. В данном разделе приведены несколько примеров практического использования разных типов интерфейсов.
Пример 1: интеграция банковского приложения с BIL24, где партнер банка продает билеты клиентам внутри экосистемы банка.
Очевидно, в экосистеме банка все пользователи авторизованные и есть собственные средства доставки билетов, например, личный кабинет пользователя в приложении. Соответственно, авторизация
пользователей в BIL24 не нужна, она производится на стороне банка. Кроме того, банк предоставляет партнеру, который продает билеты, свое интегрированное решение: эквайринг
+ ОФД + онлайн-касса. В этом случае, оптимально использовать интерфейс типа «Билетный агент». В системе банка для покупателей билетов сохраняется соответствие «Банк ID» и userId + sessionId
из BIL24. Покупатели оплачивают заказы через интернет-эквайринг банка, добавленный а платформу BIL24. Кассовые чеки покупатели получают на email, указанный при покупке. Билеты покупатель видит
в приложении банка и предъявляет их на входном контроле с экрана мобильного устройства.
Пример 2: сайт-афиша для города или региона.
Как правило, у сайтов с событиями в каком-либо городе или регионе нет авторизации посетителей. Для владельца сайта экономически нецелесообразно создавать и поддерживать развитый бэкенд с базой
данных. Гораздо выгоднее просто и без лишних усилий продавать билеты через свой эквайринг. Для этого случая идеально подходит интерфейс типа «Браузер». Покупатели билетов авторизуются в BIL24
и покупают билеты через эквайринг владельца сайта с автоматической доставкой билетов и чеков на email. С таким типом интерфейса работают Виджеты платформы,
Решения для интеграции с Wordpress, бесплатный сайт проекта Sold-out.
Пример 3: интеграция билетного оператора с BIL24
Билетные операторы используют BIL24 чтобы по одному API получать события из десятков внешних билетных систем, куда эти события загружают организаторы. У билетного оператора в собственной системе
есть все – процессинг, эквайринг, авторизация покупателей, система доставки билетов. Для этого случая подходит тип интерфейса «Билетная система». Покупатели на сайте оператора обслуживаются
его билетной системой, а платформа BIL24 служит источником информации о залах, местах, ценах на билеты и сопутствующие товары/услуги.