Платёжный API нужен не для красивой формы, а для надёжной связи заказа, платежа и статуса. В статье не приводятся endpoint, поля или SDK MulenPay: их можно брать только из официальной документации.
Событийная схема
create order
create payment
show checkout
receive webhook
verify event
update order status
Success page не источник истины
Клиент может закрыть страницу или вернуться раньше события. Источник истины — серверное подтверждение статуса.
Идемпотентность
Повторный клик не должен создавать два заказа. Храните ключ операции и проверяйте, был ли платёж уже создан.
Webhook reliability
| Событие | Что проверить | Действие |
|---|---|---|
| получен webhook | подпись и order ID | обновить заказ |
| повтор события | идемпотентность | не дублировать |
| неизвестный статус | журнал событий | эскалировать |
Типовые ошибки интеграции
| Ошибка | Как проявляется | Что делать |
|---|---|---|
| повторный платёж | клиент оплатил дважды по одному заказу | хранить ключ операции, проверять созданный платёж |
| потерянный webhook | заказ висит неоплаченным при списании | запрашивать статус по операции, а не ждать событие |
| неверная подпись | событие приходит, но не принимается | сверить секрет и алгоритм подписи с документацией |
| расхождение статусов | в системе одно, в кабинете другое | считать источником истины серверный статус операции |
Тестовый контур
Перед production проверьте успешный платёж, отказ, повтор и возврат через тестовый платёж. Обсудить интеграцию можно через контакты.
Если вам нужен платёжный API для сайта, приложения или CRM, посмотрите коммерческую страницу MulenPay: платёжный API.
FAQ
Зачем нужны webhooks?
Они помогают получить серверное событие о статусе платежа.
Что такое идемпотентность?
Защита от дублей при повторных запросах.
Почему success page недостаточна?
Она зависит от поведения клиента и не гарантирует финальный статус.
Можно ли использовать пример как документацию API?
Нет, это концепт; фактические параметры берутся из документации.
