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

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

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

Что ломается первым:
— идемпотентность: повторный запрос создаёт дубль, если merchant order ID не жёстко контролируется;
— вебхуки: статус «paid» прилетает раньше, чем вы успели сохранить заказ;
— подписи: одна криво собранная строка, и ваш мерчант забанен без объяснения причин;
— холды и возвраты: у локальных методов своя логика сеттлмента, и она часто не совпадает с вашей ERP.

Главная ошибка — пытаться встраивать WeChat Pay как универсальный шлюз. Нет. Это отдельный поток: отдельные сценарии оплаты, отдельные таймауты, отдельные требования к возвратам и reconciliation. Костыль на костыле и финтехом погоняет, если вы не разводите маршруты по типу оплаты, стране, валюте и каналу вызова.

Нужны три вещи: жёсткий state machine по заказу, нормальный retry с дедупликацией, и маппинг всех статусов в один внутренний словарь. Иначе у вас будет классика жанра: деньги списались, заказ не оплачен, поддержка молчит, а интеграция «почти готова» уже третий месяц.