Developers

API and connection documentation

Типичные сценарии интеграции

Ниже указаны несколько типичных сценариев интеграции магазина с PayBoxом. Этот список не исчерпывающий, а лишь показывает наиболее часто встречающиеся потребности и способы их реализации.

Пожертвования

Задача.

Магазин хочет принимать пожертвования на произвольные суммы. Никакие услуги в ответ не оказываются.

Решение.

На сайте магазина размещается кнопка для внесения пожертвований и поле для ввода суммы пожертвования. Кнопка ведет на PayBox, где покупатель выбирает платежную систему и вносит деньги. Собранные деньги периодически пересылаются магазину.

pg_order_id Не используется
Check URL Не реализуется
Result URL Не реализуется

Простейший магазин

Задача.

Магазин имеет в своем ассортименте небольшой набор позиций, и все заказы обрабатываются вручную, запас товаров/услуг не ограничен. Магазину не нужно в режиме online узнавать о том, что платеж состоялся.

Решение.

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

pg_order_id Не используется
Check URL Не реализуется
Result URL Не реализуется

Обычный магазин

Задача.

Магазин имеет в своем ассортименте большой набор позиций, цена формируется динамически, возможен заказ нескольких позиций в одной корзине, все заказы обрабатываются (полу)автоматически, запас товаров/услуг ограничен. Магазину нужно в режиме online узнавать о том, что платеж состоялся.

Решение.

Магазин формирует окончательную цену корзины, присваивает заказу уникальный (в своей системе) идентификатор и предлагает покупателю нажать динамически созданную кнопку, чтобы оплатить товар через PayBox. После перехода на PayBox покупатель выбирает платежную систему и оплачивает заказ. В ходе оплаты совершается проверка возможности совершения платежа (вызов Check URL), а после приема денег магазин уведомляется о совершении платежа (вызов Result URL). После платежа покупатель пересылается на Success URL или Failure URL на сайте магазина, где получает актуальную информацию о статусе своего платежа и дальнейших действиях для получения оплаченного заказа. В случае если в момент прихода покупателя на Success URL магазину не известен статус транзакции, магазин запрашивает эту информацию у PayBoxа.

pg_order_id Используется
Check URL Не реализуется
Result URL Не реализуется
Проверка статуса Не реализуется
Отмена платежа Не реализуется

Особенный магазин

Задача.

Также как в предыдущем случае, но магазин желает кастомизировать страницу оплаты для покупателя, держать ее на своем сайте и хочет, чтобы покупатель как можно больше взаимодействовал с сайтом магазина и, по возможности, не замечал, что для оплаты используется PayBox.

Решение.

В этом случае, в дополнение к сценарию «обычного магазина» магазину необходимо реализовать запрос списка платежных систем, предоставить выбор платежных систем покупателю на своем сайте и валидировать ввод. В качестве метода возврата с PayBoxа на сайт магазина необходимо установить AUTOGET или AUTOPOST.

Запрос списка платежных систем реализуется
pg_order_id Используется
Check URL Не реализуется
Result URL Не реализуется
Проверка статуса Не реализуется
Отмена платежа Не реализуется

Реестры платежей

Задача.

В параметрах магазина есть возможность задать e-mail, на который каждый день будет высылаться реестр платежей по предыдущему дню. Реестр формируется в 0:10 по московскому времени. Заголовки письма содержат следующую информацию: X-Merchant-ID: Merchant ID, выданный магазину (пример: 14) X-Registry-Date: Дата, на которую составлен реестр, в формате ГГГГ-ММ-ДД (пример: 2009-12-02) Поле «От» письма содержит info@paybox.money Тема письма: PayBox report for merchant # [ГГГГ-ММ-ДД] Реестр высылается в теле письма или во вложении, в зависимости от настроек в личном кабинете, представляет собой набор данных с разделителями «табуляция». Первая строка содержит названия полей. Если поле не определено, две табуляции следуют подряд. Реестр высылается, даже если за прошедший день не было ни одной транзакции. В этом случае в теле письма присутствует только строка заголовка.

Структура реестра операций
Запрос списка платежных систем реализуется
pg_order_id Используется
Check URL Не реализуется
Result URL Не реализуется
Проверка статуса Не реализуется
Отмена платежа Не реализуется

Need a consultation?

Send an enquiry and our managers will contact you in 15 minutes.