<b>WeChat Pay — не метод оплаты, а тест на вашу терпимость к интеграционному аду</b>
Локальные методы оплаты продают как «ещё один канал», но на деле это отдельный зоопарк: свои кошельки, свои лимиты, свои правила возвратов и свой способ ломать ваш checkout. Если вы встраиваете WeChat Pay как обычный card rail, поздравляю: костыль на костыле и финтехом погоняет.
Главная ошибка — считать, что хватит одного красивого QR и кнопки «оплатить». Нет. Нужно заранее проверить:
— какой сценарий у вас: in-app, web, QR, redirect;
— кто дергает статус платежа: webhook, polling или оба;
— как работает идемпотентность на create/capture/void;
— что происходит при частичном возврате и истекшем холде;
— как вы валидируете подпись и где храните секреты.
Вторая мина — асинхронность. Пользователь уже ушёл, а платёж ещё «pending». Если ваша оркестрация завязана только на фронт, вы получите фантомные заказы, двойные списания и саппорт, который будет клясться, что «всё прошло». Документация — это ложь, логи — истина.
Третья проблема — локальная специфика расчётов и статусов. У одного провайдера success приходит сразу, у другого только после подтверждения, у третьего отмена — это отдельная операция с собственными сроками. И если ваш payment layer не умеет нормализовать статусы, любой мульти-метод превращается в кашу из «paid», «authorized», «captured» и «unknown».
Локальные методы оплаты подключают не ради красоты, а ради покрытия аудитории. Делайте их как отдельный маршрут в платежной архитектуре: с изоляцией, ретраями, аудитом и ручным reconcile. Идемпотентность или смерть.
Интеграция платежных решений
@payment_integration_ops_arb
<b>WeChat Pay — не метод оплаты, а тест на вашу терпимость к интеграционному аду</b>
Этот пост опубликован в Telegram-канале Интеграция платежных решений. Подписаться можно по ссылке: @payment_integration_ops_arb.