Обновить

ЮKassa: деньги у клиента списаны, но заказ не оплачен, а поддержка не считает это ошибкой

Уровень сложностиПростой
Время на прочтение12 мин
Охват и читатели4.4K
Всего голосов 5: ↑4 и ↓1+6
Комментарии10

Комментарии 10

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

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

почему обработка банковской операции оказывается настолько зависимой от поведения пользователя в платёжной форме

С этим примерно понятно: покупатель боится данные карты говорить магазину; а банк хочет прямое подтверждение платежа от владельца карты. В итоге магазин, агрегатор, платёжная система и банк договариваются друг с другом в браузерной сессии пользователя.

Сам механизм понятен, как и то, почему данные карты обрабатываются платёжной системой, а не магазином. Тем более что для самостоятельной обработки и хранения карточных данных существуют требования PCI DSS, в том числе со стороны НСПК. Тут вопрос скорее в том, почему после того, как платёж уже инициирован и банк зарезервировал средства, сама форма не учитывает состояние операции и позволяет начать новую попытку в рамках того же платежа. Получается, что дальнейшая обработка транзакции зависит от действий пользователя в браузере. Как будто нормального механизма контроля состояния уже начатой операции просто не предусмотрено.

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

Не всё так просто. Платёжного агрегатора выбирает сам владелец бизнеса, исходя из условий обслуживания, комиссий и прочего.

Так добавим критерий "репутация". Сколько клиентов после такого аттракциона вокруг платежа навсегда запомнит бизнес как мошенников, которые хотели деньги украсть, что с бизнеса пришлось пришлось трясти деньги назад?

  1. Оплата заказа

  2. Деньги с банка "ушли"

  3. Магазин говорит, не пришли (это магазин врет, пришли, но украсть хотят)

  4. Деньги появляются на счете

  5. Ага! Это только после скандала магазин решил вернуть втихую деньги. А остальных обкрадывают.

  6. Об этом случае рассказывается на весь город.

Желаю удачи предпринимателю продолжающему использовать ЮКассу.

У меня тоже постоянно проблемы с ЮКассой, к счастью (относительному) она виснет ещё до начала платежа, но виснет ПЕРМАНЕНТНО, так что просто нет возможности совершить платеж, сколько не кликай. Но агрегатора выбираю не я, а продавец\сервис, увы.

Привет! На связи команда ЮKassa. Спасибо за детальный разбор — такие кейсы помогают нам видеть, где не хватает прозрачности в инструментах.

Если коротко по сути процесса: в платежах с внешним подтверждением участвуют несколько сторон — клиентское устройство, банк-эмитент, платежная система со своими регламентами и наш платежный шлюз. Когда банк резервирует сумму, финальное списание происходит только после подтверждения на каждом этапе. Если на стороне клиента обрывается сессия или теряется редирект, мы действуем строго по правилам платежной системы: не списываем деньги, а по установленному тайм-ауту переводим платеж в canceled и отправляем банку сигнал на снятие холда. Статус pending в этот период защищает магазин от ложных отмен, пока шлюз ждет финальный ответ от банка.

При этом согласны, что отсутствие промежуточных деталей в ЛК и формулировка поддержки «исправлений не ожидается» выглядят неудобно. Мы передали замечания по информативности ЛК и качеству ответов саппорта в команду.

С логикой pending и ожиданием окончательного ответа банка вопросов нет, я прекрасно понимаю, почему нельзя преждевременно отменять платёж.
Но основной вопрос статьи немного в другом. Поддержка неоднократно утверждала, что проблема возникает, когда клиент обновляет форму или начинает повторную попытку оплаты, не дождавшись результата предыдущей. Почему в таком случае уже инициированная операция, по которой банк зарезервировал средства, оказывается зависимой от дальнейших действий пользователя в форме?

Причём этот вопрос несколько раз задавался в чате поддержки и отдельно упомянут в статье, но ответа так и не получено. Почему не предусмотрен механизм блокировки повторных попыток, пока предыдущая операция находится в обработке? Или хотя бы проверка её текущего состояния перед запуском новой попытки? Ведь получается, что пользователь своими действиями может повлиять на уже инициированную операцию. Именно этот момент и хотелось бы понять, а не очередной раз услышать объяснение того, что означает pending.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации