Александр, спасибо за комментарий) Интересный у вас кейс) Но здесь, кажется, важно разделить время жизни самого заказа и время жизни платёжной операции.
Условно, если покупатель только перешёл к оплате, но ничего не оплатил, то операция остаётся в статусе «Создана». Дальше уже сама платформа может решить, сколько такой заказ считать актуальным: 5, 10 или 15 минут, а затем отменить его и вернуть билеты в продажу. Для СБП, аналогично, можно ещё и ограничить срок действия QR-кода, чтобы он перестал дейстовать через несколько минут.
С холдированием тоже можно управлять этим процессом, но уже после успешной авторизации платежа. Сумма резервируется на карте, а дальше можно сразу задать срок автоматического снятия холда, либо позже принять решение по статусу заказа: списать деньги или расхолдировать их. Так что здесь всё зависит от вашей модели работы.
А отдельный эквайринг у каждого организатора или агента — это уже вопрос архитектуры. У такого подхода, конечно, есть и свои плюсы, но появляется и жёсткая привязка конкретного организатора к конкретному эквайеру, и если у него проблемы, то переключить поток на другого провайдера не получится. Как альтернатива — единый платёжный слой с несколькими эквайерами и маршрутизацией между ними.
Кажется, с повсеместным использованием ИИ мы незаметно пришли к странному выводу: аккуратно отредактированный текст теперь сам по себе считается признаком генерации.
Всё ещё существуют хорошо прописанные редакционные политики, копирайтеры, редакторы и корректоры. Людям буквально платят за то, чтобы в текстах были единообразные кавычки ("английские" или «французские»), тире (—) вместо дефиса (-), «ё», структура и нормальные речевые конструкции.
Если длинное тире теперь считается уликой или моветоном, видимо, следующий шаг — заменять его дефисом, ломать структуру и специально оставлять пару ошибок в статье, чтобы доказать в комментариях, что текст писал человек.
Но особенно впечатляет точность диагностики: по тире, смайлу и структуре определить не только использование ИИ, но ещё конкретную модель и web-версию. Тут нам крыть нечем 🙂
Было бы красиво ответить, что у нас платежи проходят как-то особенно правильно, но нет 😄По базовой механике инструменты плюс-минус решают одну и ту же задачу, а где-то решение конкурента действительно может быть выгоднее. Мериться размером компании с таким айти-гигантом в виде Яндекса мы тоже не будем, у нас пока нет своего подразделения для умных колонок 😁 Но самозанятому, к счастью, и не нужно нанимать платежный сервис целиком. Нужен понятный сценарий: зарегистрировался, настроил, принимаешь деньги и выводишь их. Поэтому здесь скучный, но полезный совет — сравнивать комиссии и условия конкретно для своего способа работы)
Спасибо! Да, вы точно подметили про связку статуса заказа и платежа. На практике там часто проблема не в самом API, а в том, что у магазина и у платёжной системы получаются две отдельные «машины состояний», которые в какой-то момент начинают жить своей жизнью.
Например, заказ уже отменили, а холд не сняли; или товар отгрузили, но событие не сработало; или магазин не обработал изменение статуса после асинхронного ответа. Отсюда и появляются ситуации, когда в CMS'ке одно, а по платежу — совсем другое.
Так что мысль про отдельный разбор ошибок интеграции хорошая. Там действительно есть что собрать в полноценный материал — спасибо за идею 😊
Александр, спасибо за комментарий) Интересный у вас кейс) Но здесь, кажется, важно разделить время жизни самого заказа и время жизни платёжной операции.
Условно, если покупатель только перешёл к оплате, но ничего не оплатил, то операция остаётся в статусе «Создана». Дальше уже сама платформа может решить, сколько такой заказ считать актуальным: 5, 10 или 15 минут, а затем отменить его и вернуть билеты в продажу. Для СБП, аналогично, можно ещё и ограничить срок действия QR-кода, чтобы он перестал дейстовать через несколько минут.
С холдированием тоже можно управлять этим процессом, но уже после успешной авторизации платежа. Сумма резервируется на карте, а дальше можно сразу задать срок автоматического снятия холда, либо позже принять решение по статусу заказа: списать деньги или расхолдировать их. Так что здесь всё зависит от вашей модели работы.
А отдельный эквайринг у каждого организатора или агента — это уже вопрос архитектуры. У такого подхода, конечно, есть и свои плюсы, но появляется и жёсткая привязка конкретного организатора к конкретному эквайеру, и если у него проблемы, то переключить поток на другого провайдера не получится. Как альтернатива — единый платёжный слой с несколькими эквайерами и маршрутизацией между ними.
Кажется, с повсеместным использованием ИИ мы незаметно пришли к странному выводу: аккуратно отредактированный текст теперь сам по себе считается признаком генерации.
Всё ещё существуют хорошо прописанные редакционные политики, копирайтеры, редакторы и корректоры. Людям буквально платят за то, чтобы в текстах были единообразные кавычки ("английские" или «французские»), тире (—) вместо дефиса (-), «ё», структура и нормальные речевые конструкции.
Если длинное тире теперь считается уликой или моветоном, видимо, следующий шаг — заменять его дефисом, ломать структуру и специально оставлять пару ошибок в статье, чтобы доказать в комментариях, что текст писал человек.
Но особенно впечатляет точность диагностики: по тире, смайлу и структуре определить не только использование ИИ, но ещё конкретную модель и web-версию. Тут нам крыть нечем 🙂
Было бы красиво ответить, что у нас платежи проходят как-то особенно правильно, но нет 😄По базовой механике инструменты плюс-минус решают одну и ту же задачу, а где-то решение конкурента действительно может быть выгоднее. Мериться размером компании с таким айти-гигантом в виде Яндекса мы тоже не будем, у нас пока нет своего подразделения для умных колонок 😁 Но самозанятому, к счастью, и не нужно нанимать платежный сервис целиком. Нужен понятный сценарий: зарегистрировался, настроил, принимаешь деньги и выводишь их. Поэтому здесь скучный, но полезный совет — сравнивать комиссии и условия конкретно для своего способа работы)
Спасибо! Да, вы точно подметили про связку статуса заказа и платежа. На практике там часто проблема не в самом API, а в том, что у магазина и у платёжной системы получаются две отдельные «машины состояний», которые в какой-то момент начинают жить своей жизнью.
Например, заказ уже отменили, а холд не сняли; или товар отгрузили, но событие не сработало; или магазин не обработал изменение статуса после асинхронного ответа. Отсюда и появляются ситуации, когда в CMS'ке одно, а по платежу — совсем другое.
Так что мысль про отдельный разбор ошибок интеграции хорошая. Там действительно есть что собрать в полноценный материал — спасибо за идею 😊