Быстрый старт
Введение
Эта инструкция — о том, как организовать приём платежей через Payment Page. С тем, чтобы платёжная форма вызывалась из веб-сервиса и возвращала пользователей к нему. И чтобы при этом можно было использовать проверенные быстрые решения — с чёткими инструкциями, библиотеками и примерами кода И с использованием внутри программных решений на одном из трёх популярных языков программирования — PHP, Python или JavaScript.
Если вам актуально что-то другое, можно сориентироваться в вариантах.
На этом с вводными всё. Можно переходить к делу.
Краткая теория
Проекты и ключи
Работу с платёжной платформой ecommpay можно сравнить с использованием услуг гостиницы. Так, для заселения в гостиницу обычно необходимо получить номер и ключ от него, а для начала работы с платформой надо получить... проект и ключ от него. И как с номерами в гостиницах, в платформе может предоставляться разное количество проектов для одного клиента — под разные цели и задачи — при этом для каждого проекта (как и для каждого гостиничного номера) необходим свой ключ.
Как правило, для работы достаточно одного тестового и одного рабочего проектов. Это типичный случай, и в рамках быстрого старта мы исходим из него. Если вам по какой-либо причине необходимо больше проектов, это стоит обсудить с курирующим менеджером, но начать всё также можно с одного тестового проекта.
Если у вас уже есть идентификатор тестового проекта (project_id
) и секретный ключ для него (secret_key
), можно приготовиться к их использованию и переходить дальше. Если же вы ещё не бронировали тестовый проект, самое время сделать это через заявку на основном сайте компании и вернуться сюда.
Для начала работы с платформой следует получить проект и ключ от него. Если у вас уже есть идентификатор (project_id
) и ключ (secret_key
) тестового проекта, можно приготовиться к их использованию и переходить дальше. Если же вы ещё не оформляли тестовый проект, самое время это сделать через заявку на основном сайте компании и вернуться сюда.
Схема работы
Чтобы корректно вызывать Payment Page, надо настроить сбор параметров, их подписывание и вызов формы. При этом подписывание данных (для которого необходим секретный ключ) важно выполнять в серверной части веб-сервиса, а вызов формы — в клиентской. Также для оперативного контроля результатов полезно настроить в серверной части приём оповещений от платёжной платформы.
В целом это выглядит так.
В клиентской части веб‑сервиса | В серверной части веб‑сервиса | В платёжной платформе | |
---|---|---|---|
1 | Формируем заказ. Фиксируем параметры платежа и передаём их в серверную часть (чтобы подписать) | – | – |
2 | – | Дополняем (если это актуально) и подписываем параметры платежа, после чего передаём информацию в клиентскую часть | – |
3 | Формируем и отправляем в платёжную платформу запрос на открытие Payment Page | – | – |
4 | – | – | Принимаем запрос, готовим и открываем форму пользователю, обрабатываем его действия и проводим платёж, после чего отправляем оповещение о результате платежа и возвращаем пользователя к веб-сервису |
5 | – | Принимаем оповещение о результате платежа и обновляем статус заказа | – |
6 | Отображаем пользователю информацию об оплате заказа и дальнейших действиях (если они необходимы, например для доставки товара) | – | – |
Реализовывать эту схему в клиентской и серверной частях веб-сервиса в общем случае можно самыми разными способами. Здесь, в рамках быстрого старта, для удобства и скорости запуска все необходимые процедуры описываются с максимальным использованием уже готовых компонентов (таких как SDK) и примеров кода. Но вы всегда можете варьировать наши готовые компоненты со своими решениями.
Параметры вызова формы
Чтобы открыть пользователю платёжную форму, в простейшем случае достаточно определиться с суммой и валютой платежа и добавить к этим двум параметрам три идентификатора: проекта, платежа и пользователя. Таким образом, обязательных параметров всего пять. (И технически к ним ещё обязательна подпись.)
Параметр | Описание |
---|---|
|
Идентификатор проекта. Его вместе с ключом выдаёт ecommpay и его важно точно указывать даже в тестовых запросах. Иначе… стоит ждать реакцию, как при попытке зайти в чужой гостиничный номер, от платёжной платформы. |
|
Идентификатор платежа. Он может быть произвольным, но каждый раз должен быть уникальным в рамках используемого проекта. Иначе стоит ждать ошибку вызова, от веб-сервиса. |
|
Сумма платежа. В тестовых запросах может быть произвольной, а в реальных должна точно соответствовать сумме заказа. Приводится, в дробных единицах валюты. |
|
Код валюты платежа. Приводится, в трёхбуквенном формате ISO 4217 alpha-3. В тестовых запросах могут использоваться любые из действующих кодов, а в реальных каждый раз должен использоваться код той валюты, в которой инициируется платёж. Для сверки можно использовать справочник валют. |
|
Идентификатор пользователя. Может быть произвольным и повторяемым в разных запросах, но для каждого реального пользователя должен быть однозначно сопоставляемым с его учётной записью в веб-сервисе и уникальным в рамках проекта. Иначе возможны различные коллизии, в том числе с отображением сохранённых данных платёжных инструментов одного пользователя другому. |
Как именно собирать эти параметры (и в том числе, какие из них задавать в клиентской части, а какие в серверной) — решать вам (с оглядкой на архитектуру вашего веб-сервиса и иные факторы). При этом для первых тестовых вызовов сбор параметров можно не автоматизировать вовсе, если что, этим можно заняться и после первичного тестирования работы с формой. Здесь же остаётся сказать, что в дополнение к обязательным параметрам можно использовать и другие, для управления видом и поведением платёжной формы, но поскольку с этими параметрами лучше разбираться после того, как настроен базовый вызов Payment Page, предметный разговор о них дальше.
Базовая реализация
Варианты работы
Реализовывать функции веб-сервиса для работы с платёжной формой и оповещениями можно по-разному, в том числе за счёт создания своих программных решений и за счёт применения CMS-модулей. В рамках быстрого старта мы рассматриваем два варианта реализации функций веб-сервиса для работы с платёжной формой и оповещениями:
- с применением в серверной части веб-сервиса SDK от ecommpay;
- с использованием в серверной части веб-сервиса готового кода от ecommpay
Различия между этими вариантами можно считать вкусовыми. С SDK может быть чуть проще, а также доступнее при работе с другими языками программирования (полный набор материалов о работе с SDK представлен в отдельном разделе). С примерами кода же может быть чуть прозрачнее и гибче в плане встраивания в свои решения (в том числе при работе с подписыванием данных). Но оба варианта достаточно быстры и полноценны, и вы можете выбрать любой из них.
Вместе с тем, независимо от варианта реализации серверных функций, в клиентской части веб-сервиса в рамках быстрого старта мы рассматриваем разные варианты вызова платёжной формы, в том числе с использованием библиотек от ecommpay. И в целом задачи реализации сводятся к следующим.
В серверной части | В клиентской части |
---|---|
|
|
Сбор и дополнение параметров, как и было сказано в теоретическом обзоре, могут выполняться разными способами (для первичного тестирования допустимо и вручную) и остаются за вами. Остальные действия разобраны далее.
Работа с SDK
Подключаем и настраиваем.
Работа с кодом
Встраиваем и используем.
Действия в клиентской части
Открывать Payment Page в клиентской части веб-сервиса можно по-разному, и для наглядности можно попробовать несколько способов даже в рамках быстрого старта.
Самый простой способ — открывать платёжную форму в отдельной вкладке браузера.
Для использования других способов — с открытием платёжной формы в модальном окне и в элементе iframe — необходимо подключить две библиотеки: CSS для корректного отображения формы и JavaScript для вызова формы. Это делается через добавление ссылок на библиотеки в заголовочной части HTML-страницы.
Также для вызова платёжной формы с помощью JavaScript-библиотеки необходимо использовать подписанный набор параметров в виде JavaScript-объекта. Его можно формировать из ссылки, полученной при подписывании данных (в PHP для этого можно использовать функции parse_url
и parse_str
), или используя серверный код для формирования подписи (без составления ссылки) и добавляя подпись к остальным параметрам.
Подключив библиотеки и разобравшись с параметрами, можно пробовать.
Для начального знакомства этих способов вызова и открытия может быть вполне достаточно. Если же необходима более тонкая настройка, можно обращаться к документации и к нашим специалистам.
Тестирование
Когда мы открываем платёжную форму в рабочем режиме, с ней работает пользователь. А в тестовом режиме можно почувствовать себя на его месте и протестировать разные сценарии оплаты с его позиции. Главный вопрос при этом — какие реквизиты указывать?
При работе с тестовым проектом можно использовать два вида платёжных реквизитов: специальные тестовые, позволяющие тестировать заданные сценарии работы, и произвольные реалистичные, позволяющие дополнительно проверить работу формы в разных случаях.
В базовом случае можно использовать следующие тестовые номера платёжных карт (для проведения платежей по заданным кратчайшим сценариям, без эмулирования аутентификации 3‑D Secure):
4000 0000 0000 0077
— для проведения оплаты;4111 1111 1111 1111
— для отклонения оплаты.
Для более масштабного тестирования можно использовать расширенный набор тестовых данных для карточных (в том числе с аутентификацией 3‑D Secure) и различных альтернативных платежей, а также произвольные данные, включая реквизиты реальных карт, кошельков и других платёжных инструментов. Это безопасно, поскольку для всех данных в тестовой среде обеспечивается тот же уровень защиты, что и в рабочей, но реальные платежи при этом не проводятся.
По итогам тестирования, убедившись в корректной работе с формой, можно считать реализованными базовые функции по проведению оплат и при желании переходить дальше — к различным дополнениям, которые могут быть полезны уже на первых порах работы с платёжной платформой, и к запуску решения в работу.
Дополнения
Контроль проведения платежей
После проведения нескольких тестовых платежей можно разобраться с тем, как контролировать общую ситуацию по платежам. Для этого следует открыть Dashboard и ознакомиться там с реестром и карточками платежей.
При возникновении вопросов по работе с этим интерфейсом, как и в иных случаях, можно обращаться к документации и к нашим специалистам.
Возврат средств
Если по какой-либо проведённой оплате необходимо выполнить возврат, для этого также можно использовать Dashboard. При тестировании работы с платёжной платформой можно попробовать выполнить полные и частичные возвраты из карточек платежей.
Для более глубокого освоения работы с возвратами, в том числе с массовыми, можно использовать отдельную статью. Кроме того, полезно иметь в виду возвраты через Gate.
Возможности управления формой
При работе с Payment Page можно оперировать различными возможностями, чтобы управлять видом и поведением формы, например, задавая подходящий язык, фильтруя методы оплаты или управляя способами возвращения пользователя к веб-сервису. Некоторые из таких возможностей требуют подключения через специалистов ecommpay, иные можно использовать без обращений к кому-либо, просто настроив их через Dashboard или передавая дополнительные параметры в запросах на открытие Payment Page.
При тестировании работы с Payment Page мы рекомендуем попробовать следующее:
- Настроить оформление платёжной формы с помощью конструктора.
Для этого следует перейти в раздел Проекты интерфейса Dashboard и воспользоваться инструментами вкладки Payment Page Designer (подробнее — в статье Индивидуальное оформление).
- Попробовать вызов платёжной формы на разных языках.
Чтобы открыть Payment Page на определённом языке, его код (в двухбуквенном формате ISO 639-1 alpha-2) следует передать в значении соответствующего параметра:
language_code
. Список поддерживаемых ecommpay языков можно найти здесь. - Возвращать пользователя к веб-сервису после проведения платежей.
После проведения платежей в зависимости от их результатов можно перенаправлять пользователей к разным страницам веб-сервиса. Адреса таких страниц можно задать в разделе Проекты интерфейса Dashboard (во вкладке Ссылки для перенаправления), либо передавать их в конкретных запросах в значении параметров
merchant_success_url
иmerchant_fail_url
. - И далее на ваш вкус.
Информацию о разных возможностях можно найти в общем обзоре и в специализированном разделе, а полный перечень параметров вызова — в отдельной статье. С вопросами же, как обычно, можно обращаться к нашим специалистам.
Запуск
После реализации базовых функций, тестирования разных возможностей и определения необходимых вам сценариев работы можно переходить к запуску рабочего проекта. Важно, чтобы к этому моменту были решены организационные вопросы. В таком случае вопросы технические сводятся к настройке свойств проекта на стороне платёжной платформы и к началу использования идентификатора и ключа рабочего проекта.
Успехов!