Comments 35
Когда стоит ожидать обновление API выплат в таком же стиле?
Вы планируете сделать сквозное решение с арендой накопителя, так чтобы никакую кассу не видеть никогда и об интеграции с ней тоже не думать? :)
«На Вашем старом аккаунте ошибка, которую мы не можем исправить. Просто заведите новый» — официальный ответ от техподдержки.
Не юникод символы в запросах на колбеки и прочее. В итоге старая версия работает с кучей костылей, но работает! И желания проверять стабильность новой нет.
Вот данные из емейла, может помогут идентифицировать запрос
13669927
CRM004517057
В итоге я зарегестрировал новый ящик и в нем магазин (shopId 191834), но не могу скачать свой договор. Скачивается пустой архив
Подскажите, как в новой версии API передать return_url для ситуации, когда платеж отменили? Сейчас только 1 url можно передать и он будет на ссылке "в магазин" и до оплаты, и после.
Вот здесь даны подробные рекомендации по реализации returl_url.
Да, вот ссылка на решение.
В старой версии API есть куча интересных данных, вроде части номера карты и эффективной комиссии платежа, которых просто нет в новой. Так бы действительно стоило перейти.
Насчет эффективной комиссии платежа – знаем, работаем над этим:)
Спасибо, это очень здорово.
Есть ещё большая проблема, почему новое API не так лучше старого. Сразу скажу что у меня есть проекты, где внедрено и старое, и новое API, и есть множество внедрений Stripe, PayPal и других, так что есть с чем сравнивать, и у меня было такое впечатление что новое API подаёт себя под тем соусом что больше не нужно слушать события, что больше нет этого неудобства номер один в старом API, когда интеграционное тестирование с использованием какого-то временного домена просто невозможно. Создаётся впечатление что новым API должно быть также удобно пользоваться как, например, API Stripe или PayPal (где вообще нет проблем с интеграционным тестированием). Выглядит оно очень похоже, и если бы это было так, это просто прекрасно.
Однако это не так, в новом API тоже необходимо слушать запросы. Например, человек оплачивает с карты, но данные для чека указаны какие-то не такие из-за человеческой ошибки, и чек не создаётся. Но человеку на сайте Яндекс.Кассы показывается сообщение что его платеж принят, и человек не возвращается на сайт, чтобы сайт мог перепроверить факт оплаты, и в итоге и заказ не оплачен, и человек не знает об этом. Никто не рад этому.
Выход из этой ситуации есть: использовать те самые уведомления для проведения платежей. Получается так что полноценное интеграционное тестирование, end-to-end, с новым API тоже невозможно, так как события уходят на фиксированный адрес (что логично само по себе). И получается так что новое API удобно разве что тем, что не нужно сертификаты раз в год заменять. В остальном те же самые грабли. Если вы считаете что здесь есть какая-то мотивация переходить на новое, то, уверяю вас, эта вся ситуация не создаёт ровным счётом никакой мотивации для нас, разработчиков, агитировать или призывать владельцев магазинов переходить на новое API. Мы, наоборот, будет отсоветовать. Старое едва ли хуже.
Однако это не так, в новом API тоже необходимо слушать запросы. Например, человек оплачивает с карты, но данные для чека указаны какие-то не такие из-за человеческой ошибки, и чек не создаётся. Но человеку на сайте Яндекс.Кассы показывается сообщение что его платеж принят, и человек не возвращается на сайт, чтобы сайт мог перепроверить факт оплаты, и в итоге и заказ не оплачен, и человек не знает об этом. Никто не рад этому.Вот эта часть не очень понятна. Почему пользователь не возвращается на сайт, если платеж принят? Хотелось бы посмотреть на реальные кейсы… Можно написать в нашу поддержку, и ребята из шопмастеров могли бы здесь помочь разобраться.
Выход из этой ситуации есть: использовать те самые уведомления для проведения платежей. Получается так что полноценное интеграционное тестирование, end-to-end, с новым API тоже невозможно, так как события уходят на фиксированный адрес (что логично само по себе).Здесь, конечно, все корректно, но это особенности асинхронного процесса. Оно точно так же работает и у Stripe, и у PayPal.
После оплаты человек видит что-то такое:
Это не я придумал такое, это из документации: https://kassa.yandex.ru/pay_by_yandex/
Какая у человека должна быть мотивация возвращаться на сайт с такого экрана? Да никакой, вот люди и не возвращаются. Думают, что оплата прошла, все сделано. Не идут по ссылке обратно на сайт магазина. В итоге интеграторы оказываются вынуждены настраивать прием и обработку уведомлений для корректного учета всех платежей.
Вы спрашиваете почему интеграторы не рекомендуют переходить на новое API если уже есть интеграция через старое. Именно потому что это обмен шила на мыло, тут и там прием платежей через уведомления. Так понятно?
Для интеграции платежей через Stripe и PayPal не нужно настраивать прием их уведомлений. Вообще не нужно. В случае Stripe и PayPal процесс оплаты завершается строго после обратного перехода на сайт магазина. Вот если бы с новым API была такая же процедура, это было бы совсем другое дело.
В России Яндекс.Касса — это номер один, но не потому что она какая-то особо хорошая или удобная, а потому что все остальное гораздо хуже. К сожалению.
С этого экрана всегда можно вернуться в магазин.
Для интеграции платежей через Stripe и PayPal не нужно настраивать прием их уведомлений. Вообще не нужно. В случае Stripe и PayPal процесс оплаты завершается строго после обратного перехода на сайт магазина. Вот если бы с новым API была такая же процедура, это было бы совсем другое дело.
В текущей версии так делать можно, но есть нюанс. Пользователь может закрыть страницу после оплаты, у него может отвалиться интернет или выключить электричество. Именно поэтому для надежности мы рекомендуем подписаться на уведомления.
Более того, для всех редиректных сценариев Stripe настойчиво рекомендует делать то же самое: stripe.com/docs/payments/ideal#submit-payment
См: «Use a method such as webhooks to handle order fulfillment, instead of relying on your customer to return to the payment status page»
Или, например, аналог нашего редиректного сценария: stripe.com/docs/payments/checkout/one-time
В старом протоколе от доставки уведомлений зависило прохождение платежей. В новом API уведомления носят чисто информационный характер. Если уведомление не доставилось – платеж все-равно пройдет. Плюс ваша система всегда можно получать актуальные статусы используя GET-запросы.
То есть, вы говорите, если нужно, чтобы всё было гладко, без уведомлений, как у Stripe и PayPal, то нужно использовать не-редиректный сценарий? Это который, для которого надо дорогую сертификацию по PCI DSS проходить?..
Это, конечно, очень здорового, но это не то, что можно серьёзно предлагать малому бизнесу. Получается у нас патовая ситуация: использовать то, что работало бы чётко и гладко, нельзя, потому что дорого, а использовать то, что работает строго с уведомлениями, не имеет смысла потому что старое работает точно так же. Понимаете о чём я?
В России большинство платежей проходят с 3D-Secure, поэтому мы рекомендуем подписываться на уведомления для надежности.
Если уведомления для вас реализовать проблематично по той или иной причине вы можете запрашивать статус транзакции с определенной переодичностью, используя GET-запрос
Уведомления реализовать не проблематично, проблематично тестировать всё это. Приходится делать много жестов руками, опрашивать статус транзакции, и всё это.
Давайте вернёмся к тому скриншоту, где написано что платеж прошел. У него есть две проблемы, одна из них — что человек не возвращается обратно на сайт. Другая проблема в том, что сообщение, которое передаёт эта страница, вводит в заблуждение. На момент, когда человек видит это сообщение, в большинстве случае платеж ещё не прошел.
Рассмотрим практическую ситуацию. Менеджер магазина ввёл в карточке товара какие-то не такие данные, на работу с которыми настроена касса. Или ввёл просто не те данные. Так или иначе, чек сделать удаётся. Но клиент видит что платеж прошел, и начинает переживать. Надо ли говорить что это ни разу не прекрасно. Собираетесь ли вы делать что-то с этой проблемой, если уж не с первой?
Например, можно всё-таки поменять текст на менее категоричный, и более настойчиво отправить человека на сайт. А уж на сайте магазина можно и про ошибку написать, и статус платежа опросить. Угодить уважаемому клиенту. Как вы считаете?
Понятно, что люди привыкли к такой странице, но как насчёт того, чтобы сделать настройку для магазинов, которая говорила бы хочет ли магазин, чтобы люди скорей возвращались обратно, или магазину это не так важно. Чтобы был выбор. Понимаете?
Уведомления реализовать не проблематично, проблематично тестировать всё это. Приходится делать много жестов руками, опрашивать статус транзакции, и всё это.
У нас есть настройка авторедиректа на сайт. По запросу через менеджера можем включать и пользователь сразу будет возвращаться на сайт без промежуточного экрана
Спасибо, это отличная новость!
Может быть вы ещё порадуете: в целях интеграционного тестирования было бы здорово в тестовом магазине при оформлении платежа иметь возможность указать, куда должны уходить уведомления об этом конкретном платеже.
Например, если тестовые версии разворачиваются на хосте staging.adc83b19e.example.com, где adc... случайный набор цифр, то в текущей схеме получать уведомления с тестового магазина без, опять же, большого количества действий, с настройкой прокси, который будет знать какие именно хосты сейчас используются, не получается. Если бы можно было указать куда должны уходить уведомления для конкретного тестового платежа, то проблема уведомлений была бы решена.
Для настоящих платежей такое, конечно, не требуется.
Спасибо, это отличная новость!Надеемся, это поможет вам в вашей работе))
Может быть вы ещё порадуете: в целях интеграционного тестирования было бы здорово в тестовом магазине при оформлении платежа иметь возможность указать, куда должны уходить уведомления об этом конкретном платеже.Пока обещать по этому поводу ничего не можем, но в целом — да, смотрим в сторону упрощения интеграции по уведомлениям.
Восемь причин перейти на новый API Яндекс.Кассы