Загадка "проталкивания оплаты": совпадение, заговор или техническая особенность?

Question

[Kudoz90]

Здравствуйте, коллеги!

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

Суть проблемы
Мы заметили, что в течение дня иногда возникают "окна", когда оплаты на сайте останавливаются на час-два. Сначала мы списывали это на естественные причины: обед у пользователей, сезонные колебания активности, плохой день для продаж и т.д. Однако через некоторое время выявили странную закономерность:

Если в такое "окно" мы сами совершаем покупку (оплачиваем собственный товар), то следующие оплаты начинают проходить с прежней скоростью. Мы даже придумали термин для этого явления — "протолкнуть оплату" .

Что мы знаем:

• Проблема наблюдается уже несколько месяцев.
  
• После "проталкивания" череда покупок возобновляется стабильно.
  
• Мы связывались с последними оплатившими до "окна" и первыми после него — никаких проблем со стороны пользователей не выявлено.
  
• Сайт и магазин разрабатывали сторонние подрядчики. Мы начали подозревать, что это может быть связано с их работой (возможно, где-то заложена зависимость, которую мы не видим, проект громадный и разрабатывался добрые 10 лет).
  

Гипотезы

Совпадение : Может быть, это просто случайность, и наша интерпретация событий ошибочна. Но стабильность эффекта заставляет сомневаться в этой версии.
Технические ограничения : Возможно, где-то в системе есть узкое место, которое блокируется или замедляется при определенных условиях. Например:

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

Но обзвон клиентов до окна и после показал что оплаты происходят минута в минуту и проблем при оплате они не испытывают.
Заговор подрядчиков : Мы начали думать, что разработчики могли внедрить какую-то скрытую логику, которая искусственно замедляет процесс и реагирует на наши действия. Это, конечно, звучит как паранойя, но отбросить эту версию пока не можем.

UPD: Будем рады услышать ваши гипотезы и предложения. Особенно интересуют примеры из практики, когда казалось, что система ведет себя "таинственно", но в итоге все объяснялось простыми причинами.

Comments

[Adamos]

Только учти. Честно говоря, там было два следа. Про второй след я не успел рассказать. Второй след был на потолке, в точности над первым

Узкое место в предложенной схеме - это то место, откуда потенциальные покупатели приходят, например.

[Алексей Уколов]

система ведет себя "таинственно", но в итоге все объяснялось простыми причинами

Примеры обратного как раз найти сложно. Почти всегда расследование выводит на самого себя или что-то элементарное, даже если в начале казалось, что это проделки сатаны.

[Refguser]

Kudoz90, с таким построением вопроса твой вопрос с высокой долей вероятности снесут. Читай правила и исправляй вопрос (подсказка - тут нельзя спрашивать "мнений", а тем более гипотез и пр фантазий. это не форум)

[Михаил Ливач]

оплаты происходят минута в минуту и проблем при оплате они не испытывают.

из описания неясно 2 момента:
1) как вы видите историю оплат,
2) насколько эта информация адекватна.

Поясню на примере:
пришли 3 покупателя, сделали оплаты с интервалом в 5 минут: B1,B2,B3. Вы оплат не видите, делаете "проталкивание" N1 . Какой после этого Вы видите результат? Такой:
13:00 B1
13:05 B2
13:10 B3
13:30 N1

или такой:
13:31 B1, B2, B3, N1

Если первый - то баг именно в получении данных от шлюза. Я бы предположил какой-нибудь кэш, который "заклинивает" по какой-то причине.
Если второй - то либо данные со шлюза извлекаются неверно ( вместо времени оплаты прописывается время обращения за данными к шлюзу), либо со шлюзом какая-то проблема.

[rPman]

как клиенты приходят к вам для оплаты?
много ли у вас постоянных клиентов?

покажите график оплат (количество оплат на интервале, например 10мин) , в идеале csv-шник - дата, сумма, пометьте где ваши проталкивающие оплаты

[Сергей Соколов]

Чтобы дифференцировать «случайность / аномалия» хорошо бы посмотреть график оплат (его данные), как выше написал rPman

Покупка процесс много-шаговый: открыть страницу с файлом, нажать "Купить", уйти в платёжную систему (ПС), вернуться, получить подтверждение от ПС, отдать файл, дождаться полной загрузки файла покупателем.

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

[koder_1]

В техническую поддержку модуля оплаты уже обратились?

[Kudoz90]

Если честно нет, просто часть коллектива считает что это какой то бред) а часть верит в теорию заговора)) По экварингу вопросов вроде бы нет, платежи секунду в секунду прилетают

Answer 1

[Everything_is_bad]

Техническая проблема на вашей стороне, разбирайтесь, привлекайте сторонних специалистов, если текущие не могут внятно рассказать что за проблема или объяснить такое поведение (т.е отсутствие проблемы)

Comments

[Kudoz90]

узкое горлышко проблемы найти не можем. Поэтому и написал

Answer 2

[alexalexes]

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

Ну, так закажите аудит логов платежной части сайта, до входа в режим оплаты и есть ли возвраты на страницу сайта после оплаты.
Если до входа нет скриптов трекинга поведения пользователей в браузере, то пусть разработчики прикрутят их, тогда сможете получать логи до самого последнего шага перед оплатой.
Нет никакой мистики, вы просто не запрашиваете необходимый анализ при аномальных случаях, или не знаете в какой форме хотите получить отчет по логам сервера.
Но для этого нужно обеспечить необходимый уровень журналирования на сайте (логирование), чтобы проводить такой анализ. Это нужно обговаривать в ТЗ.

Comments

[Kudoz90]

А в теории можно ли такое быть что подрядчики каким то образом уводят оплаты на сторону?

[alexalexes]

Kudoz90, у вас были бы жалобы от покупателей "Оплата прошла, деньги списали, а заказ не оформился".

[Константин Б.]

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

Answer 3

[Саня Технадзор]

Пока у вас нет сквозного контроля с достоверностью отслеживания событий, я буду придерживаться теории заговора.

Я не до конца понял насколько вы не контролируете происходящее в техническом плане, поэтому пишу что вижу по максималке.

Аргументация

1. Вы не являетесь владельцами технической системы. Об этом я говорю много и долго: чем стабильнее бизнес и его рост, тем глубже вы оказываетесь в заложниках.
Реализация зависит от фантазии бородатых детей, которые взяли вас в заложники.

2. Явная фиксация внешних признаков провала по времени + ваши действия по "проталкиванию" платежей.

Это значит, что технически вполне возможно выявить всех аффилированных с вами юридических лиц и карт, чтобы отслеживать, что именно вы оплачиваете.

Также есть возможность маркировать трафик (это из мира ботов и скликивания), где вас можно отследить по цифровому слепку. В общем, профайлинг обычно творит чудеса, когда с ним сталкиваются.

И если у вас тут серьёзный финансовый поток, такая перестраховка для заметания следов вполне вероятна.

Так или иначе, это возможно, но без понимания, кто у вас там и на каком уровне, сложно строить такие наступательные стратегии.

Выводы:

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

И это лишь вопрос времени, когда у вас появится настоящая "крысиная нора" или проявится проблема, которую будет невозможно решить по аналогичным причинам (вы в заложниках).

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

P.S. Из практики: Поняв, что систему приводят в порядок, кто-то бежит к учредителям и говорит: "Либо доля в компании, либо исполнение вашего крупного проекта на платформе по обслуживанию серьёзного предприятия останавливается по неизвестным вам причинам".

Такие ситуации выправлялись, но для этого нужна воля.

Итого:

Жути я, может, и нагнал, но нужно иметь понимание в цифрах — это сквозная аналитика. Без доступа к коду, понимания его работы и отслеживания продаж в реальном времени можно только гадать.

Лучше предполагать худшее и готовиться к нему, хотя бы морально, чем вообще не думать об этом.

Желаю вам всяческих успехов в решении!