Внутренняя билетная система

Технологическая часть

TimePad можно использовать как билетную систему на уже готовом заполненном контентом сайте, передавая информацию о событиях по API. Подробно обо всех возможностях написано на нашем портале для разработчиков в разделе API, ниже будет описан пример работы системы.

Немного о внутренней архитектуре TimePad. В системе каждое событие создается не от лица пользователя, а от лица организатора (организации). Это отдельная сущность, к которой привязывается личный кабинет, поддомен и договор. Пример такой организации - https://vvsp-edu.timepad.ru/.

У каждой организации может быть несколько пользователей-администраторов. Уникальным идентификатором пользователя в системе является адрес его электронной почты.

Таким образом, для создания события на стороне сайта должна быть информация:

  • О пользователе TimePad, с помощью API ключей которого будет создано событие
  • Об организации, от имени которой будет создано событие. При этом пользователь должен являться администратором этой организации
  • Корректная базовая информация о событии (название, дата, место проведения, стоимость участия)

Таким образом подключение билетной системы сводится к двум действиям - созданию пользователя на TimePad и созданию для него организации, от имени которой будут публиковаться события. Далее эти шаги будут рассмотрены более подробно.

Шаг 1. Авторизация пользователя

Авторизация пользователя происходит по протоколу oAuth2, при этом TimePad является сервером. Если у пользователя нет аккаунта на TimePad это не страшно - он может авторизоваться через ВКонтакте, при этом аккаунт на TimePad для него будет создан автоматически в рамках процесса авторизации. Даже в этом случае в конечном итоге он попадет на исходный сайт.

Подробное описание механизма

Так это выглядит в плагине для WordPress: после установки плагина пользователю предлагается подготовить сайт к продаже билетов, т.е. подключить аккаунт на TimePad и связать его со своим сайтом. Текст кнопки для авторизации может быть любой, но желательно объяснить пользователю зачем нужна авторизация и что его ждет дальше:

После нажатия на кнопку пользователь будет переброшен на стандартную страницу авторизации TimePad. Если у пользователя нет аккаунта на TimePad он может нажать на одну из кнопок соцсетей и привязать свой новый аккаунт к аккаунту из соцсети - для этого даже не нужно придумывать пароль и вводить свой вдрес электронной почты:

После создания аккаунта (либо, если аккаунт уже был), пользователю будет предложено дать доступ к своему аккаунту. После нажатия на кнопку “Авторизовать” он будет направлен на ReturnUrl, т.е. обратно в приложение:

Шаг 2. Получение списка организаций

Возможно, у пользователя уже есть свои организации на TimePad и он бы хотел публиковать события от имени одной из них. Для того, чтобы это выяснить, существует API метод получения списка организаций. Он возвращает все необходимые реквизиты для публикации событий на TimePad.

Не исключено, что при интеграции стоит пойти по другому пути и создавать новую сервисную организацию для пользователя даже в том случае, если у него уже есть свои. Это одновременно упростит интерфейс и user flow и позволит избавиться от лишних сущностей. О том, как создать организацию от имени пользователя - в следующем разделе.

Как это выглядит в плагине для WordPress: сразу после авторизации пользователя плагин опрашивает API по адресу /introspect, получает список организаций и предлагает пользователю выбрать, какую из них подключить к сайту (или, в случае интеграции, от имени какой из них будут публиковаться события). Этот выбор сохраняется в настройках приложения.

Шаг 3. Создание для пользователя организации, если ее еще нет

Если метод introspect не вернул ни одной организации, можно позаботиться о пользователе самим и подготовить для него сервисную органиазацию. Для этого нужно придумать для нее название (должно быть уникальным), адрес URL (должно быть уникальным), указать телефон пользователя и отправить все данные по API. Важный момент - ни в названии, ни в адресе не должны быть слова timepad, таймпад, таймпэд и производные. Если такие слова будут переданы, то организация создана не будет.

Как это выглядит в плагине для WordPress: при пустом списке организаций мы автоматически создаем на TimePad аккаунт с именем, равным имени блога и все события постим в эту организацию. То есть пользователю после регистрации не нужно ничего делать, все делается за него.

Важный момент. В момент создания организации пользователю на email придет приветственное письмо примерно такого вида:

Шаг 4. Автоматическое создание события

Дальше остается только автоматически добавлять события через API. Для этого нужно передавать название, дату, описание и цену события так, как это написано в документации. В ответ будет приходить JSON объект с полным описанием события и его параметрами.

В ответе особое внимание нужно обратить на поле widgets:code_html. В нем будет передан полный код вставки виджета регистрации, который нужно использовать для регистрации на событие. Мы настойчиво рекомендуем размещать форму регистрации / покупки билетов на своей стороне, а не просто ставить ссылку “Купить билет” на Таймпад. Это в разы повышает конверсию в покупку и является предпочтительным способом продажи билетов. Внешний вид и поведение виджета можно настроить под себя так, что он не будет отличим от стандартного элемента сайта. Как это сделать написано здесь: http://dev.timepad.ru/widget/what-widget-can/

Однако, важно знать, что даже при создании события через API пользователю будут приходить на email системные нотификации от TimePad (в том числе подтверждения создания событий, списки участников, нотификации о продажах билетов и другие). При этом все ссылки из писем будут вести на учетную запись организатора в домене timepad.ru

Общее описание схемы взаимодействия