Мы написали и поддерживаем платформу для проведения международной конференции по образованию. Конференция проходит в смешанном формате, на онлайн трансляцию билеты покупают из разных стран. В этом кейсе рассказ о том, как мы обеспечили техническую возможность продажи билетов на проекте в 2022 году для всех стран, включая РФ.
Проект работает на собственном «движке» на PHP, но подобное решение можно использовать на любых других проектах, от платформы оно зависит мало. Подробнее про создание проекта мы писали тут.
Выбор подходящего платёжного решения
Изначально на проекте был подключен эквайринг от Альфа-банка, в 2022 году пользоваться им за пределами РФ стало невозможно. Юрлица для приёма платежей у нашего клиента имелись и в России и в Казахстане, это облегчило задачу с юридической точки зрения, но нужно было решить и её техническую часть.
Мы понимали, что, скорее всего, на сайт придётся подключать второй эквайринг для приёма платежей за пределами РФ. Начали общаться с банками в Казахстане, но часть из них соглашались работать только с проектом из Казахстана (обязательный домен в зоне .kz и обязательное подтверждение казахстанских корней проекта).
Второй проблемой было длительное рассмотрение заявок — вплоть до 2-3-х месяцев. Мы же на подключение платёжного решения имели максимум 30 дней, включая все юридические моменты и согласования.
Следующим шагом обратились в платёжные сервисы из РФ, у которых есть представительства в Казахстане. Плотно общались с Qiwi и Робокассой и остановились на филиале Робокассы в Казахстане. Все проверки осуществляет московский офис, но юридически платежи идут через Казахстанское юрлицо Робокассы, что позволяет принимать платежи по всему миру. Но договор также должен быть заключён с юрлицом клиента в Казахстане.
Робокасса выигрывала по скорости подключения проекта, обещали сделать это за неделю. Проект одобрили быстро и без проблем.
Особенности реализации
Изначально покупка билетов на платформе шла по стандартному для любого онлайн-магазина пути, причём оплата производилась только в рублях, а в случае оплаты заказа из-за рубежа, конвертацию валют брал на себя банк:
Первой задачей стало внедрение мультивалютности. Наш проект мультиязычен, но привязывать валюту к языку оказалось плохой идеей. Русским языком пользуются как граждане Казахстана, так и многие наши соотечественники, живущие не в России.
Мы добавили переключатель валюты в интерфейсе покупки билетов и в корзине, а также внедрили мультивалютность во всех административных интерфейсах и отчётах, связанных с покупкой и финансовой аналитикой.
Для удобства пользователей при первом входе определяем страну по IP и устанавливаем рубли для РФ, тенге для Казахстана и доллары для остальных стран. При этом пользователь может переключить валюту самостоятельно и сайт запоминает выбор пользователя.
Следующим шагом разделили процесс покупки на две ветки, в зависимости от выбранной пользователем валюты:
В Робокассе настроили передачу данных для онлайн-чеков, требования к ним в РФ и Казахстане очень похожи. Добавили необходимую информацию на сайт, протестировали оплату на тестовом платёжном шлюзе и получили разрешение от менеджеров Робокассы на использование платёжного шлюза в «боевом» режиме.
Подводные камни
С подключением непосредственно второго платёжного шлюза проблем практически не возникло, а вот мультивалютность подкинула нам пару сюрпризов.
На платформе используется достаточно сложная и гибкая система промокодов. Промокод применяется в интерфейсе корзины, но в этом же интерфейсе мы оставили возможность переключения валюты.
Если пользователь выбирал валюту, а затем применял промокод, проблемы не возникало. Но ряд пользователей пошли по другому пути: сначала применяли промокод, затем меняли валюту, чего мы не предусмотрели на старте.
Чтобы корзина работала и в таком случае, пришлось пересчитывать скидку по промокоду и при смене валюты.
Вторым моментом, о котором мы забыли на старте, стало выставление счёта за заказ для юрлиц. На платформе можно выставить счёт как компании в России, так и в Казахстане, но ряд компаний пытались выставить счёт не в валюте своей страны, что приводило к формированию счетов, которые было невозможно оплатить.
Пришлось добавить проверку при выставлении счёта и, если валюта заказа не соответствует валюте страны юрлица, показываем предупреждение и возвращаем пользователя в корзину для корректировки валюты.
Данные юрлица при этом сохраняются, так что при возврате на последний шаг пользователю не приходится вводить их заново.
Эффект от проведенных работ
В итоге, после первоначальной отладки, мультивалютная система оплаты заработала без существенных проблем. Количество продаж за два месяца поделилось между двумя платёжными системами примерно поровну. С точки зрения пользователя процесс покупки и оплаты остался таким же удобным, как и в версии с одной платёжной системой.