Принимайте платежи через платежные шлюзы в WhatsApp | Документация для разработчиков

Получайте платежи через платежные шлюзы в WhatsApp

Обновлено: 12 декабря 2025 г

Ваш бизнес может предоставить клиентам возможность оплачивать заказы через платежные шлюзы наших партнеров, не покидая WhatsApp. Компании могут отправлять клиентам сообщения с указанием деталей заказа, а затем получать уведомления об обновлении статуса платежа через веб-хуки.

Обзор

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

В настоящее время наше платежное решение поддерживается сторонними платежными сервисами BillDesk, Razorpay, PayU и Zaakpay. Для получения платежей через WhatsApp вам необходимо иметь учетную запись BillDesk, Razorpay, PayU или Zaakpay.

Мы ожидаем, что в будущем будет добавлено больше платежных систем.

Как это работает

Сначала компания составляет и отправляет order_details . order_details — это новый тип интерактивного сообщения, которое всегда содержит одни и те же 4 основных компонента: заголовок, тело, нижний колонтитули действие. В действия компания указывает всю информацию, необходимую клиенту для завершения платежа.

Каждое order_details содержит уникальный идентификатор reference_id, предоставленный компанией, и этот уникальный идентификатор используется на протяжении всего процесса для отслеживания заказа.

После отправки сообщения компания ожидает обновления статуса платежа через веб-хуки. Компании получают уведомления об изменении статуса платежа, но не должны полагаться исключительно на эти уведомления через веб-хуки по соображениям безопасности. WhatsApp также предоставляет API для поиска платежей, который можно использовать для получения статуса платежа напрямую в любое время.

Процесс покупки в приложении

В мессенджере WhatsApp процесс покупки состоит из следующих этапов:

Клиенты отправляют заказ с выбранными товарами в компанию либо с помощью простых текстовых сообщений, либо используя другие интерактивные сообщения, такие как «Сообщение об одном товаре», «Сообщение о нескольких товарах» и «Подробная информация о товаре».

После получения заказа компания отправляет order_details пользователю сообщение «Просмотреть и оплатить», он увидит подробную информацию о заказе и общую сумму к оплате.

Нажав «Продолжить» , пользователь может выбрать оплату через WhatsApp или любое другое приложение UPI.

Оплата через WhatsApp Pay:

[Изображение удалено — слишком большое для импорта]

Оформите заказ в других приложениях UPI:

[Изображение удалено — слишком большое для импорта]

После подтверждения платежа платежным шлюзом или поставщиком платежных услуг компания может приступить к обработке заказа.

Затем компании могут отправить order_status, информирующее его о статусе заказа. Каждое сообщение приведет к появлению всплывающего окна (как показано ниже), которое будет ссылаться на исходное сообщение с подробной информацией о заказе, а также обновлять статус, отображаемый на странице с подробной информацией о заказе.

Привяжите свой платежный аккаунт

Для приема платежей в WhatsApp необходимо добавить конфигурацию платежей в соответствующий бизнес-аккаунт WhatsApp. Конфигурация платежей позволяет связать учетную запись платежного шлюза с WhatsApp. Каждая конфигурация платежей связана с уникальным именем. В order_details вы можете указать конфигурацию платежей, которая будет использоваться для конкретного оформления заказа. Затем WhatsApp сгенерирует процесс оформления заказа, используя связанную учетную запись платежного шлюза.

[Изображение удалено — слишком большое для импорта]

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

Шаги по отмене привязки настроек платежей

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

Этапы интеграции

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

Диаграмма последовательности

На следующей диаграмме показана типичная последовательность интеграции для Payments API. Шаги, выделенные зеленым цветом, являются ключевыми этапами интеграции.

[Изображение удалено — слишком большое для импорта]

Шаг 1: Отправьте интерактивное сообщение с подробной информацией о заказе

Для отправки order_details предприятиям необходимо собрать интерактивный объект типа order_details , состоящий из следующих компонентов:

Объект	Описание
`тип` объект	Необходимый. Должно быть «order_details».
`заголовок` объект	Необязательный. Содержимое заголовка отображается поверх сообщения. Если заголовок не указан, API использует изображение первого доступного продукта в качестве заголовка
`тело` объект	Необходимый. Объект, содержащий тело сообщения. Объект содержит следующее поле: `текстовая` строка Обязательно, если `тело` сообщения. Содержимое сообщения. Поддерживаются эмодзи и разметка Markdown. Максимальная длина — 1024 символа.
`нижний колонтитул` объект	Необязательный. Объект, содержащий нижнюю часть сообщения. Объект содержит следующие поля: `текстовая` строка Обязателен, если `нижний колонтитул` . Содержимое нижнего колонтитула. Поддерживаются эмодзи, разметка Markdown и ссылки. Максимальная длина — 60 символов.
`действие` объект	Необходимый. Объект действия, который пользователь должен выполнить после прочтения сообщения. Этот объект действия содержит следующие поля: `имени` строка Обязательно. Должно быть «review_and_pay». `параметров` объект См. объект «Параметры» для получения дополнительной информации.

Объект параметров

Объект	Описание
`reference_id` нить	Необходимый. Уникальный идентификатор заказа или счета-фактуры, предоставленный компанией. Он чувствителен к регистру, не может быть пустой строкой и может содержать только английские буквы, цифры, подчеркивания, дефисы или точки, а также не должен превышать 35 символов. Идентификатор ссылки (reference_id) должен быть уникальным для каждого сообщения order_details для данного заказа. Если необходимо отправить несколько сообщений order_details для одного и того же заказа, рекомендуется включить в reference_id порядковый номер (например, «BM345A-12») для обеспечения уникальности reference_id.
`тип` объект	Необходимый. Тип товаров, оплачиваемых в этом заказе. В настоящее время поддерживаются варианты `цифровых товаров` и `физических товаров`.
`бенефициары` множество	Требуется для отгружаемых физических товаров. Список получателей данного заказа. Получатель — это предполагаемый получатель физических товаров, указанных в заказе. Список содержит следующие поля: Примечание: Информация о получателях не отображается пользователям, но необходима по юридическим причинам и в целях соблюдения нормативных требований. `имени` строка Обязательно. Имя физического лица или организации, получающей физический товар. Не более 200 символов. `адрес_строка1` строка Обязательно. Адрес доставки (номер дома/башни, название улицы и т. д.). Не более 100 символов. `адрес_строка2` строка Необязательно. Адрес доставки (ориентир, район и т. д.). Не должен превышать 100 символов. `городская` струна Обязательно. Название города. `состояния` строка Обязательно. Название штата. `кантри` струна Обязательно. Должно быть «Индия». `почтового индекса` строка Обязательно. 6-значный почтовый индекс адреса доставки.
`валюта`	Необходимый. Валюта для этого заказа. В настоящее время поддерживается только валюта `INR`.
`Общая сумма` объект	Необходимый. Объект `total_amount` содержит следующие поля: `смещение` целое число Обязательно. должна составлять `100` индийских `рупий`. `значение` целое число Обязательно. Положительное целое число, представляющее значение суммы, умноженное на смещение. Например, 12,34 рупии имеют значение 1234. `Значение total_amount.value` должно быть равно `order.subtotal.value` + `order.tax.value` + `order.shipping.value` - `order.discount.value`. Сумма транзакций через UPI ограничена 500 000 рупий. Для более крупных сумм установите `параметр enabled_payment_options` в значение `["web"]`. См. раздел «Ограничение доступных способов оплаты».
`настройки оплаты` объект	Необходимый. см. в объекте «Настройки платежей» Дополнительную информацию
`заказ` объект	Необходимый. см. объект заказа .

Объект настроек платежей

Объект Описание

Объект	Описание
`тип` нить	Необходимый. Необходимо установить значение "payment_gateway".
`платежный шлюз` объект	Необходимый. Объект, описывающий информацию о платежном счете: `тип` строка Обязательно. Уникальный идентификатор товара в заказе. Необходимо установить значение «billdesk» , «razorpay» , «payu» или zaakpay, если вы подключили платежный шлюз BillDesk, Razorpay, PayU или Zaakpay для приема платежей. `имени_конфигурации` строка Обязательно. Название предварительно настроенной конфигурации оплаты, используемой для этого заказа, не должно превышать 60 символов. Это значение должно совпадать с конфигурацией оплаты, настроенной в WhatsApp Business Manager. Если `параметр configuration_name` недействителен, клиент не сможет оплатить свой заказ. Мы настоятельно рекомендуем компаниям провести тщательное тестирование этой настройки на этапе интеграции. `объект billdesk/razorpay/payu/` zaakpay Необязательно. Для продавцов/партнеров, желающих использовать поля additional_info1/7 (для BillDesk), примечания и квитанцию (для Razorpay), поля UDF (для PayU) и extra1/2 (для Zaakpay), теперь можно передавать эти значения в сообщении «Подробности заказа», и мы будем использовать их для создания транзакции/заказа в соответствующих группах обработки платежей. обратитесь к объекту UDF, специфичному для платежного шлюза .

тип

нить

Необходимый.

Необходимо установить значение "payment_gateway".

платежный шлюз

объект

Необходимый.

Объект, описывающий информацию о платежном счете:

тип строка

Обязательно. Уникальный идентификатор товара в заказе. Необходимо установить значение «billdesk» , «razorpay» , «payu» или zaakpay, если вы подключили платежный шлюз BillDesk, Razorpay, PayU или Zaakpay для приема платежей.

имени_конфигурации строка

Обязательно. Название предварительно настроенной конфигурации оплаты, используемой для этого заказа, не должно превышать 60 символов. Это значение должно совпадать с конфигурацией оплаты, настроенной в WhatsApp Business Manager.

Если параметр configuration_name недействителен, клиент не сможет оплатить свой заказ. Мы настоятельно рекомендуем компаниям провести тщательное тестирование этой настройки на этапе интеграции.

объект billdesk/razorpay/payu/ zaakpay

Необязательно. Для продавцов/партнеров, желающих использовать поля additional_info1/7 (для BillDesk), примечания и квитанцию (для Razorpay), поля UDF (для PayU) и extra1/2 (для Zaakpay), теперь можно передавать эти значения в сообщении «Подробности заказа», и мы будем использовать их для создания транзакции/заказа в соответствующих группах обработки платежей.

обратитесь к объекту UDF, специфичному для платежного шлюза .

Поля BillDesk, RazorPay, PayU и Zaakpay

Теперь партнеры и продавцы могут передавать "Примечания", "Квитанция" и пользовательские функции в сообщениях "Подробности заказа" и получать эти данные обратно в платежных сигналах. Здесь мы рассмотрим, как продавцы могут передавать additional_info для BillDesk, поля "Примечания" и "Квитанция" для Razorpay, пользовательские функции для PayU и extra для Zaakpay PGs.

Объект	Описание
`примечания` объект	Необязательный. Поддерживается только для платежного шлюза Razorpay Объект может представлять собой пары ключ-значение, максимум 15 ключей, при этом каждое значение ограничено 256 символами.
`квитанция` Нить	Необязательный. Поддерживается только для платежного шлюза Razorpay Номер чека, соответствующий данному заказу, предназначен для внутреннего использования. Максимальная поддерживаемая длина — 40 символов, минимальная — более 0 символов.
`udf1-4` Нить	Необязательный. Поддерживается только для платежного шлюза PayU Пользовательские поля (UDF) используются для хранения любой информации, соответствующей конкретному заказу. Максимальное количество символов в каждом поле UDF составляет 255.
`экстра1-2` Нить	Необязательный. Поддерживается только для платежного шлюза Zaakpay Пользовательские поля (дополнительные) используются для хранения любой информации, соответствующей конкретному заказу. Максимальное количество символов в каждом дополнительном поле — 180.
`дополнительная_информация1-7` Нить	Необязательный. Поддерживается только для платежного шлюза BillDesk Пользовательские поля (дополнительные) используются для хранения любой информации, соответствующей конкретному заказу. Максимальное количество символов в каждом дополнительном поле — 120.

Объект заказа

Объект	Описание
`статус` нить	Необходимый. только допустимое значение `order_details` находится `в состоянии ожидания`. В `order_status` сообщении `статус` может быть следующим: `pending`, `captured`или `failed`.
`тип` строка	Необязательный. Поддерживается только значение `quick_pay`. При передаче этого поля кнопка «Просмотреть и оплатить» скрывается, и в окне с подробной информацией о заказе отображается только кнопка «Оплатить сейчас».
`предметы` объект	Необходимый. Объект со списком товаров для данного заказа, содержащий следующие поля: `retailer_id` string Необязательно. Идентификатор товара в заказе из вашего каталога. `имени` строка Обязательно. Название товара, которое будет отображаться пользователю. Не может превышать 60 символов. `изображения` объект Необязательно. Пользовательское изображение для элемента, отображаемого пользователю. См. объект изображения элемента для получения дополнительной информации. Использование этого поля изображения ограничит массив товаров максимум 10 элементами, и его нельзя использовать с `retailer_id` или `catalog_id`. `суммы` со значением и смещением — см. поле «Итоговая сумма» выше. Обязательно. Цена за единицу товара. `sale_amount` amount object Необязательно. Цена со скидкой за единицу товара. Она должна быть меньше первоначальной суммы. Если поле указано, оно используется для расчета промежуточной суммы. `количество` целое число Обязательно. Количество товаров в этом заказе; это поле не может быть десятичным числом, должно быть целым числом. `country_of_origin` строка Обязательно, если `catalog_id` отсутствует. Страна происхождения продукта. `importer_name` string Обязательно, если `catalog_id` отсутствует. Название компании-импортера. `importer_adress` string Обязательно, если `catalog_id` отсутствует. Адрес компании-импортера.
`промежуточная сумма` объект	Необходимый. Значение должно быть равно сумме `order.amount.value` * `order.amount.quantity`см. `total_amount.` Для пояснения `offset` и `value` полей Следующие поля являются частью `«Промежуточный итог»` : `смещение` целое число Обязательно. должна составлять `100` Сумма `индийских рупий.` `значение` целое число Обязательно. Положительное целое число, представляющее значение суммы, умноженное на смещение. Например, 12,34 рупии имеют значение 1234.
`налог` объект	Необходимый. Налоговая информация по данному заказу содержит следующие поля: `смещение` целое число Обязательно. должна составлять `100` Сумма `индийских рупий.` `значение` целое число Обязательно. Положительное целое число, представляющее значение суммы, умноженное на смещение. Например, 12,34 рупии имеют значение 1234. `описания` строка Необязательно. Максимальное количество символов — 60.
`перевозки` объект	Необязательный. Стоимость доставки заказа. Объект содержит следующие поля: `смещение` целое число Обязательно. должна составлять `100` Сумма `индийских рупий.` `значение` целое число Обязательно. Положительное целое число, представляющее значение суммы, умноженное на смещение. Например, 12,34 рупии имеют значение 1234. `описания` строка Необязательно. Максимальное количество символов — 60.
`скидка` объект	Необязательный. Скидка на заказ. Объект содержит следующие поля: `смещение` целое число Обязательно. должна составлять `100` Сумма `индийских рупий.` `значение` целое число Обязательно. Положительное целое число, представляющее значение суммы, умноженное на смещение. Например, 12,34 рупии имеют значение 1234. `описания` строка Необязательно. Максимальное количество символов — 60. `discount_program_name` string Необязательный текст. Используется для обозначения заказов с бонусами. Если заказ является заказом с бонусами, продавец должен указать эту информацию. Максимальное количество символов — 60.
`catalog_id` объект	Необязательный. Уникальный идентификатор каталога Facebook, используемого компанией. Если вы не укажете это поле, вам необходимо указать следующие поля в объекте items: `country_of_origin`, `importer_name`и `importer_address.`
`срок действия` объект	Необязательный. Срок действия данного заказа. Бизнес-процесс должен определить следующие поля внутри этого объекта: `с меткой времени` – UTC-метка времени в секундах, когда должен истечь срок действия ордера. Минимальный порог – 300 секунд. `Описание` – Текстовое пояснение к сроку действия. Максимальное количество символов – 120.

Объект изображения элемента

Объект Описание

Объект	Описание
`ссылки` строка	Обязательно. Ссылка на изображение, которое будет показано пользователю. Должен быть файлом `image/jpeg` или `image/png` и иметь 8-битную кодировку, формат RGB или RGBA. Соответствует тем же требованиям, что и изображение в медиафайлах.

ссылки строка

Обязательно. Ссылка на изображение, которое будет показано пользователю. Должен быть файлом image/jpeg или image/png и иметь 8-битную кодировку, формат RGB или RGBA. Соответствует тем же требованиям, что и изображение в медиафайлах.

параметра . представляет собой строковый JSON-объект

В итоге интерактивный объект для интеграции с каталогом BillDesk должен выглядеть примерно так:

параметра . представляет собой строковый JSON-объект

В итоге интерактивный объект для интеграции RazorPay с каталогом должен выглядеть примерно так:

параметра . представляет собой строковый JSON-объект

Для интеграции PayU, не основанной на каталоге, то есть когда catalog-id отсутствует, пример полезной нагрузки выглядит следующим образом:

Для интеграции Zaakpay без использования каталога, то есть когда catalog-id отсутствует, пример полезной нагрузки выглядит следующим образом:

Шаг 2: Добавьте общие параметры сообщения

После завершения создания интерактивного объекта добавьте остальные параметры, формирующие сообщение: recipient_type, toи type. Не забудьте установить тип как interactive.

Это параметры, общие для всех типов сообщений.

Шаг 3: Выполните POST-запрос к конечной точке Messages

Отправьте POST-запрос на /[PHONE_NUMBER_ID]/messages, используя JSON- объект. Если ваше сообщение будет отправлено успешно, вы получите следующий ответ:

Со всеми возможными ошибками и инструкциями по их обработке можно ознакомиться в разделе WhatsApp Cloud API, Коды ошибок.

Опыт использования продукта

Клиент получает с подробной информацией о заказе, похожее на приведенное ниже (слева). При нажатии на кнопку «Просмотреть и оплатить» открывается экран с подробной информацией о заказе, как показано ниже (посередине). Затем клиент может оплатить свой заказ, используя кнопку «Продолжить», которая открывает всплывающее окно с вариантами оплаты (справа).

[Изображение удалено — слишком большое для импорта]

Шаг 4: Получение веб-перехватчика о статусе транзакции

Компании получают обновления через веб-хуки сообщений при изменении статуса инициированной пользователем транзакции на статус типа «платеж». Он содержит следующие поля:

Объект	Описание
`идентификатор` нить	Необходимый. Идентификатор веб-перехватчика для уведомления.
`recipient_id` нить	Необходимый. WhatsApp ID клиента.
`тип` нить	Необходимый. Для вебхуков обновления статуса платежа используйте тип «payment».
`статус` нить	Необходимый. `подтверждено`/`ожидается`: `подтверждено` — когда платеж успешно завершен, `ожидается —` когда пользователь попытался совершить платеж, но еще не получил сигнал об успешной транзакции.
`оплата` объект	Необходимый. Содержит следующее поле: `reference_id` строка Уникальный идентификатор заказа, отправленный в `order_details` . `amount` Объект Содержит поля «Значение» и «Смещение», соответствующие общей сумме, уплаченной пользователем. `Валюта:` строка. Валюта всегда INR. `транзакции` . Попытка совершения транзакции для данного платежа. Объект транзакции содержит следующие поля: `id` string Обязательно. Буквенно-цифровой идентификатор заказа платежного шлюза. `pg_transaction_id` string Необязательный параметр. Буквенно-цифровой идентификатор платежного шлюза. `Тип` строки . Обязательный параметр. оплаты для данной транзакции. `Billdesk` , `Razorpay` или `Payu` Zaakpay `Тип` Поддерживаются `статуса` Строка . Обязательный параметр. Статус транзакции. Может быть одним из следующих: `ожидание` , `успех` или `неудача`. `created_timestamp —` целое число . Обязательный Время создания транзакции в секундах эпохи. `updated_timestamp —` целочисленное значение . Время последнего обновления транзакции в секундах эпохи. `метода` ОбъектНеобязательно. Информация о способе оплаты может быть недоступна для неудачных платежей) `Тип` строки . Обязательный параметр. Описывает тип способа оплаты, используемого потребителем для оплаты заказа. Может быть одним из следующих вариантов: `UPI` , `карта` , `электронный кошелек` или `интернет-банкинг`. `ошибки` ОбъектНеобязательно. Подробная информация об ошибке платежа может быть недоступна для всех попыток оплаты)`code` string . Он описывает причину сбоя платежа, сгенерированную платежным шлюзом, и Meta возвращает эту информацию партнерам. `reason` string Обязательно. В этом поле в текстовом виде описывается причина сбоя платежа, генерируемая платежным шлюзом, и Meta возвращает эту информацию партнерам. `additional_info1-7` string Необязательно. Отправляется для платежного шлюза Billdesk только в том случае, если значение передается в сообщении с подробностями заказа. Каждый из ключей additional_info1-4 содержит строковые значения. `notes` Объект (необязательно). Отправляется только для платежного шлюза Razorpay, если значение передается в сообщении с подробностями заказа. Содержит пары ключ-значение, как указано в сообщении с подробностями заказа. `квитанции` Строка . Необязательно. Отправляется для платежного шлюза Razorpay только в том случае, если значение указано в сообщении с подробностями заказа. `udf1-4` string Необязательно. Отправляется для платежного шлюза Payu только в том случае, если значение указано в сообщении с подробностями заказа. Каждый из ключей udf1-4 содержит строковые значения. `extra1-2` string Optional. Отправляется для платежного шлюза Zaakpay только в том случае, если значение указано в сообщении с подробностями заказа. Каждый из ключей extra1-2 содержит строковые значения. `refunds` Массив необязательно). Список возвратов по данному заказу. Каждый объект возврата содержит следующие поля: `id` string Обязательно. Буквенно-цифровой идентификатор возврата средств.`amount` Объект . Обязательное поле. Общая сумма возврата.`speed_processed —` строка . Обязательный параметр. Скорость обработки возврата средств. Может быть `мгновенной` или `обычной`.`статуса` Строка . Обязательный параметр. Статус возврата средств. Может быть одним из `ожидание`, `успех` или `неудача`.`created_timestamp —` целое число . Обязательный Время создания возврата средств в секундах эпохи.`updated_timestamp —` целое число . Обязательный параметр. Время последнего обновления данных о возврате средств в секундах эпохи.
`метка времени` нить	Необходимый. Временная метка для веб-перехватчика.

Вот пример веб-хука статуса типа «платеж»:

Для получения дополнительной информации о других статусах см. раздел «Веб-перехватчики сообщений».

Шаг 5: Подтверждение платежа

После получения веб-хука о статусе платежа, или в любое другое время, компания может проверить статус платежа по заказу. Для этого компаниям необходимо выполнить GET-запрос к конечной точке платежей, как показано здесь:

GET <PHONE_NUMBER_ID>payments<PAYMENT_CONFIGURATION><REFERENCE_ID>///

где payment_configuration и reference_id совпадают с данными, указанными в order_details .

Предприятиям следует ожидать ответа в той же HTTP-сессии (а не в уведомлении веб-перехватчика), содержащего следующие поля:

Поле	Описание
`reference_id` нить	Необходимый. Идентификатор, отправленный компанией в `order_details.` сообщении
`статус` нить	Необходимый. Статус оплаты заказа. Может быть либо « `ожидает подтверждения` , либо `«завершено».` Для получения информации о значении этих статусов обратитесь к таблице ниже.
`валюта` нить	Необходимый. Валюта для этого платежа. В настоящее время поддерживается только валюта `INR`.
`количество` объект	Необходимый. Сумма платежа. Она содержит следующие поля: `смещение` целое число Обязательно. Должно быть 100. `значение` целое число Обязательно. Положительное целое число, представляющее значение суммы, умноженное на смещение. Например, 12,34 рупии имеют значение 1234.
`транзакции` множество	Необязательный. Список транзакций для данного платежа. Это поле присутствует только в том случае, если была совершена хотя бы одна попытка оплаты. Если статус платежа `«ожидание»` и попыток оплаты не было, это поле не будет возвращено. Каждый объект транзакции содержит следующие поля: `идентификатора` строка Обязательно. Буквенно-цифровой идентификатор заказа платежного шлюза. `pg_transaction_id` строка Обязательно. Буквенно-цифровой идентификатор платежного шлюза. `тип` строка Обязательно. Тип оплаты для данной транзакции. `Billdesk` , `Razorpay` , `Payu` или `Zaakpay` Поддерживаются `статуса` строка Обязательно. Статус транзакции. Может быть одним из следующих: `ожидание` , `успешное завершение` или `неудача`. В лучшем случае только одна транзакция может иметь `успешно"` . `created_timestamp` целое число Обязательно. Время создания транзакции в секундах эпохи. `обновленная_временная_метка_целое` число Обязательно. Время последнего обновления транзакции в секундах эпохи. `метода` объект Необязательно. Информация о способе оплаты может быть недоступна в случае неудачной оплаты. `Тип` строки . Обязательный параметр. Описывает тип способа оплаты, используемого потребителем для оплаты заказа. Может быть одним из следующих вариантов: `UPI` , `карта` , `электронный кошелек` или `интернет-банкинг`. `ошибки` объект (Необязательно) Информация об ошибке платежа может быть недоступна для всех попыток оплаты. `code` string . Он описывает причину сбоя платежа, сгенерированную платежным шлюзом, и Meta возвращает эту информацию партнерам.`reason` string (Обязательно.) Описывает причину сбоя платежа в виде обычного текста, который генерируется платежным шлюзом, и Meta возвращает эту информацию партнерам. `возвратов` массив Необязательно. Список возвратов по данному заказу. Каждый объект возврата содержит следующие поля: `id` string Обязательно. Буквенно-цифровой идентификатор возврата средств.`amount` Объект . Обязательное поле. Общая сумма возврата.`speed_processed —` строка . Обязательный параметр. Скорость обработки возврата средств. Может быть `мгновенной` или `обычной`.`статуса` Строка . Обязательный параметр. Статус возврата средств. Может быть одним из `ожидание`, `успех` или `неудача`.`created_timestamp —` целое число . Обязательный Время создания возврата средств в секундах эпохи.`updated_timestamp —` целое число . Обязательный параметр. Время последнего обновления данных о возврате средств в секундах эпохи.
`дополнительная_информация1-7` нить	Необязательный. Поддерживается только для BillDesk PG и содержит строковые значения, отправляемые в составе сообщения «Подробности заказа».
`квитанция` нить	Необязательный. Поддерживается только для Razorpay PG. Содержит значение чека, отправленное в сообщении «Подробности заказа».
`примечания` объект	Необязательный. Поддерживается только для Razorpay PG и содержит пары ключ-значение, отправляемые в сообщении с подробной информацией о заказе.
`udf1-4` нить	Необязательный. Поддерживается только для PayU PG и содержит строковые значения, отправляемые в сообщении «Детали заказа».
`экстра1-2` нить	Необязательный. Поддерживается только для Zaakpay PG и содержит строковые значения, отправляемые в сообщении с подробной информацией о заказе.

Статус платежа

Статус Описание

Статус	Описание
`в ожидании`	Заказ создан, но оплата еще не списана. Этот статус охватывает два сценария: Пока не было попыток оплаты: не `массив транзакций` будет присутствовать в ответе.Попытка оплаты не удалась: массив `транзакций` будет содержать одну или несколько записей со `статусом` «неудачная `»`.
`захвачен`	Платеж успешно обработан. `транзакций` будет содержать запись со `статусом` «успешно `»`.

в ожидании

Заказ создан, но оплата еще не списана. Этот статус охватывает два сценария:

Пока не было попыток оплаты: не массив транзакций будет присутствовать в ответе.Попытка оплаты не удалась: массив транзакций будет содержать одну или несколько записей со статусом «неудачная ».

захвачен

Платеж успешно обработан. транзакций будет содержать запись со статусом «успешно ».

Пример успешного ответа выглядит следующим образом:

Здесь показан пример типичной ошибки:

Ответ на этапе оплаты

Содержимое ответного сообщения варьируется в зависимости от этапа оплаты. Ниже приведены примеры для каждого этапа.

Платеж не предпринимался — пользователь еще не пытался произвести оплату. Возвращаются только поля уровня заказа; транзакций отсутствует.

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

Платеж не удался — Пользователь попытался оплатить заказ, но попытка не удалась. Общий статус платежа остается «ожидание» (заказ все еще ожидает успешной оплаты), но транзакций содержит информацию о неудачной попытке с подробными сведениями об ошибке.

Шаг 6: Обновить статус заказа

Компаниям необходимо отправлять обновления по заказу, используя order_status, а не текстовые сообщения, поскольку последний статус заказа, отображаемый на странице сведений о заказе, основан только на order_status сообщениях

Для уведомления клиента об изменениях в заказе можно отправить интерактивное сообщение типа order_status как показано ниже.

В следующей таблице описаны поля order_status :

Объект	Описание
`тип` нить	Обязательно. Должно быть значение «order_status».
`тело` объект	Необходимый. Объект, содержащий тело сообщения. Объект содержит следующее поле: `текстовая` строка Обязательно, если `тело` сообщения. Содержимое сообщения. Поддерживаются эмодзи и разметка Markdown. Максимальная длина — 1024 символа.
`нижний колонтитул` объект	Необязательный. Объект, содержащий нижнюю часть сообщения. Объект содержит следующее поле: `текстовая` строка Обязателен, если `нижний колонтитул` . Содержимое нижнего колонтитула. Поддерживаются эмодзи, разметка Markdown и ссылки. Максимальная длина — 60 символов.
`действие` объект	Необходимый. Объект действия, который пользователь должен выполнить после прочтения сообщения. Этот объект действия содержит следующие поля: `имени` строка Обязательно. Должно быть «review_order». `параметров` объект См. объект «Параметры» для получения дополнительной информации.

Объект параметров

Объект параметров содержит следующие поля:

Ценить Описание

Ценить	Описание
`reference_id` нить	Необходимый. Идентификатор, отправленный компанией в `order_details` .
`заказ` объект	Обязательный параметр. Этот объект содержит следующие поля: `статуса` строка Обязательно. Новый `статус`. Должен быть одним из следующих: `обработка`, `частичная отгрузка`, `отгрузка`, `завершение`, `отмена`. `описания` строка Необязательный текст. Текст для передачи информации о статусе заказа в `поле «Детали заказа»`. Может быть полезен при отправке уведомления об отмене. Максимальное количество символов — 120.

reference_id

нить

Необходимый.

Идентификатор, отправленный компанией в order_details .

заказ

объект

Обязательный параметр. Этот объект содержит следующие поля:

статуса строка

Обязательно. Новый статус. Должен быть одним из следующих: обработка, частичная отгрузка, отгрузка, завершение, отмена.

описания строка

Необязательный текст. Текст для передачи информации о статусе заказа в поле «Детали заказа». Может быть полезен при отправке уведомления об отмене. Максимальное количество символов — 120.

order_status приводит к появлению двух новых ошибок, которые кратко описаны ниже.

Код ошибки	Описание
`2046` - Недействительный переход статуса	Переход статуса заказа не допускается.
`2047` - Отменить заказ невозможно	Отменить заказ невозможно, так как пользователь уже оплатил его.

Опыт использования продукта

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

[Изображение удалено — слишком большое для импорта]

Поддерживаемые статусы заказов и переходы

В настоящее время мы поддерживаем следующие значения статуса заказа:

Ценить	Описание
`в ожидании`	Пользователь еще не оплатил заказ успешно
`обработка`	Оплата пользователем авторизована, продавец/партнер выполняет заказ, оказывает услугу и т. д.
`частично отгружено`	Часть товаров из заказа уже отправлена продавцом
`отправленный`	Все товары в заказе были отправлены продавцом
`завершенный`	Заказ выполнен, и от пользователя или партнера/продавца дальнейших действий не требуется
`отменено`	Партнер/продавец хочет отменить `order_details` для заказа/счета. Обновление статуса не удастся, если `успешный` или `ожидающий` по этому `order_details` сообщению

Для обеспечения единообразия пользовательского опыта количество переходов между статусами заказа ограничено. Допустимые переходы между статусами приведены ниже:

Начальный статус заказа всегда «ожидание», он передается в order_details .«отменено» и «завершено» СтатусыСтатус «ожидает выполнения» может переходить в любой другой статус, включая «обрабатывается», «отправлено», «частично отгружено».«обработка», «отправлено» и «частично отправлено» эквивалентны и могут переходить друг в друга или в один из конечных статусов.

[Изображение удалено — слишком большое для импорта]

При отправке order_status с некорректным переходом вы получите веб-перехватчик ошибки с кодом 2046 и сообщением «Переход к новому статусу заказа был выполнен некорректно».

Отмена заказа

Заказ можно отменить, отправив order_status со статусом «отменен». Клиент не может оплатить отмененный заказ. Клиент получает order_status , и страница с подробной информацией о заказе обновляется, показывая, что заказ отменен, а кнопка «Продолжить» удалена. Дополнительный текст, отображаемый под «Заказ отменен» на странице с подробной информацией о заказе, можно указать с помощью описания в order_status .

Отменить заказ можно только в том случае, если пользователь еще не оплатил его. Если пользователь оплатил заказ, а вы отправляете order_status со «отменен» , вы получите веб-хук с ошибкой 2047 и сообщением «Не удалось изменить статус заказа на 'отменен'».

Шаг 7: Сверка платежей

WhatsApp не поддерживает сверку платежей. Компаниям следует использовать свой аккаунт платежного шлюза для сверки платежей, используя reference_id, указанный в order_details , и идентификаторы транзакций, возвращаемые в рамках запроса на поиск платежа.

Предпочитаемый продавцом способ оплаты UPI

Теперь продавцы могут указать до одного приложения для оплаты через UPI, которое будет отображаться в процессе оформления заказа. Предпочтительное приложение для оплаты продавца будет отображаться вверху списка доступных приложений UPI на экране «Выбор способа оплаты». Для включения этой возможности партнерам необходимо указать внешний идентификатор приложения в сведениях о заказе или в сообщении счета-фактуры.

Примечание: Эта функция доступна в потребительских приложениях версии 2.24.21.0 и выше

Обновления в данных заказа и полезной нагрузке

Список поддерживаемых приложений:

Приложение UPI	Идентификатор приложения, который будет передан в полезной нагрузке «Детали заказа»
Google Pay	gpay
PhonePe	телефон
PayTm	Paytm
БХИМ	бхим
Amazon Pay	Amazon Pay
КРЕД	кредит
Мобиквик	мобиквик

Ограничить доступные способы оплаты

Продавцы могут указать, какие варианты оплаты отображать в процессе оформления заказа, выбрав между UPI и веб-версией. Это позволит продавцам разрешить прием платежей по счетам только через UPI или кредитную карту (любой доступный вариант PG).

Сумма транзакций через UPI ограничена 500 000 рупий. Для более крупных сумм установите параметр enabled_payment_options в значение ["web"] , чтобы использовать веб-форму оформления заказа вашего платежного шлюза. Платежи с включенным UPI, превышающие этот лимит, будут отклонены.

Примечание: Эта функция доступна в потребительских приложениях версии 2.24.22.4 и выше

Обновления в данных заказа и полезной нагрузке

Список способов оплаты

Включенная опция	Опыт работы с процессами оформления заказа
упи	В процессе оформления заказа отображаются только приложения UPI
веб	После загрузки веб-страницы платежного шлюза в процессе оформления заказа отобразятся настроенные варианты оплаты для учетной записи продавца в платежном шлюзе.

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

Проверка платежных систем Razorpay и PayU сторонними организациями

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

Для использования этой функции, находящейся на стадии альфа-тестирования, пожалуйста, свяжитесь с командой Meta Payments по адресу [email protected]

Обновления в данных заказа для поддержки TPV для продавцов Razorpay

Исходное значение до шифрования должно выглядеть примерно так:

Обновления в данных заказа: поддержка TPV для продавцов PayU

Исходное значение до шифрования должно выглядеть следующим образом:

{
"Подробная информация о бенефициаре" : {
"Номер счета получателя" : "account_number1|account_number2",
"ifscCode" : "ifsc1|ifsc2",
  }
}

Обратите внимание: пожалуйста, тесно сотрудничайте с командами Meta и платежных шлюзов (RazorPay или PayU), чтобы разблокировать эту функцию, поскольку мы все еще находимся на этапе альфа-тестирования.

Вопросы безопасности

Предприятиям следует соблюдать местные требования безопасности и регулирования в Индии. Им не следует полагаться исключительно на статус транзакции, указанный в веб-хуке, и необходимо использовать API для поиска платежей, чтобы получать статусы непосредственно из WhatsApp. Предприятия должны всегда проверять и подтверждать данные в ответах API или веб-хуках для защиты от SSRF-атак.

Контрольный список для интегрированных торговых площадок

Убедитесь, что order_status отправляется потребителю, информируя его об обновлениях заказа после получения обновлений транзакции по заказу.

Убедитесь, что продавец проверен, а контакт WABA отмечен галочкой «проверено».

Убедитесь, что WABA сопоставлен с соответствующим уровнем отправки сообщений, инициированных продавцом (1000, 10000 и 10000 сообщений в день)

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

Переместите "payment_type" и "payment_configuration" в раздел "payment_settings". Это рекомендуемый способ, предоставляющий доступ к таким функциям, как "notes" и "udf"-поля. В качестве примера см. приведенные выше данные.