WeChat Pay не интегрируется «как обычный метод» — он ломает вашу схему на первом же холде

WeChat Pay не интегрируется «как обычный метод» — он ломает вашу схему на первом же холде

Локальные методы оплаты почти всегда продают как «добавим еще один кнопочный платеж». На практике вы получаете зоопарк: отдельные требования к клиентскому идентификатору, свои статусы, кривые callback-тайминги и логику, где возврат — это не возврат, а отдельный сценарий с собственными ошибками. Идемпотентность или смерть.

Если встраиваете WeChat Pay, проверьте не UI, а архитектуру:
— кто генерирует order_id и переживает ретраи;
— как матчится платеж, если webhook пришел раньше ответа API;
— где хранится связка local transaction_id ↔ merchant order;
— что делаете при частичной оплате, отмене и истекшей сессии.

Главный ад начинается на стыке фронта, сервера и провайдера. Фронт уже показывает «успех», бэкенд еще не получил подтверждение, webhook потерялся в очереди, а саппорт видит только «платеж не найден». Документация — это ложь, логи — истина. Без нормальной корреляции событий вы будете чинить не интеграцию, а фантазии команды поддержки.

Еще одна любимая мина — конверсия и 3DS-подобные проверки внутри локальной экосистемы. Пользователь ушел в нативный кошелек, вернулся не туда, сессия умерла, а вы не предусмотрели повторный вход в flow. В итоге у вас не «альтернативный метод оплаты», а костыль на костыле и финтехом погоняет.

Делайте один универсальный платежный оркестратор, а не набор отдельных зоопарков. Иначе очередной «убийца Stripe», который не умеет в рекурренты и нормальные вебхуки, быстро превращается в ручной пожарный кран.