Восемь причин перейти на новый API Яндекс.Кассы

    В октябре 2017 года у Яндекс.Кассы появились новый платёжный протокол и третья версия API. Мы уже рассказывали о том, как и почему к этому пришли, а сейчас напомним ключевые причины перейти на него для тех, кто этого ещё не сделал.

    1. Подключение платежей стало реально быстрым


    На новом API оно происходит в 5-10 раз быстрее, чем раньше, и теперь среднестатистический разработчик может подключить платежи к своему (ну, или не совсем) сайту или приложению за один рабочий день, а не за пять, как было раньше. Речь, конечно, о той части работы, когда всё согласовано, заявки одобрены и ключи доступа получены. Но на это тоже достаточно дня.

    А для тех, кто продаёт в соцсетях, работает выставление счетов на почту, смской или просто ссылкой, которую можно отправить в личные сообщения.

    2. Экономятся силы разработчиков и админов


    Для сопровождения старой версии нужно позаботиться о разных мелких вещах — выделить под работу с API статический IP-адрес, раз в год менять сертификаты. А ещё в старой версии нет поддержки SNI-режима HTTPS, который сейчас бесплатно (или почти бесплатно) входит в услугу «хостинг с HTTPS» у многих хостинг-провайдеров

    Для возвратов, подтверждения, отмены или повтора платежей картой используется протокол MWS (Merchant Web Services). С помощью MWS магазин может совершать возвраты, подтверждать и отменять отложенные платежи, а также повторять платежи банковской картой (если плательщик на это согласился). В старой версии API для работы с MWS магазину нужно было получить от удостоверяющего центра Яндекс.Денег сертификат X.509, с помощью которого магазин формировал запросы к Яндекс.Кассе. Сейчас всё это идет из коробки — вы просто получаете ключи доступа и внедряете нужные платёжные методы.

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

    3. Только REST и ничего лишнего


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

    Давайте для сравнения посмотрим на старый и новый методы возврата платежа.

    Раньше нужно было сформировать документ-распоряжение на исполнение операции по стандарту XML 1.0, сформировать криптопакет формата PKCS#7 с цифровой подписью, но без цепочек сертификации, компрессии данных и шифрования. После этого формировался POST-запрос по HTTP/1.1 с телом криптопакета или во вложении через MIME-тип application/pkcs-mime. Дальше дело за малым — передать восемь входных параметров и, в принципе, всё готово.

    Итого, HTTP-запрос:
    POST /webservice/mws/api/returnPayment HTTP/1.1
    Content-Type: application/pkcs7-mime
    Content-Length: 906
    
    ——-BEGIN PKCS7——-
    MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCA
    JIAEgbE8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0KPG1h
    a2VEZXBvc2l0aW9uUmVzcG9uc2UgY2xpZW50T3JkZXJJZD0iMTI5MTExNjIzNDUy
    OCIgc3RhdHVzPSIwIi6789Jvcj0iMCIgcHJvY2Vzc2VkRFQ9IjIwMTAtMTEtMzBU
    MTE6MjM6NTQuNjI0WiIgYmFsYW5jZT0iNTQxNDYuNzMiIC8+DQoAAAAAAAAxggF8
    MIIBeAIBATB3MGoxCzAJBgNVBAYTAlJVMQ8wDQYDVQQIEwZSdXNzaWExFjAUBgNV
    BAcTDVN0LlBldGVyc2J1cmcxITAfBgNVBAoTGEludGVybmV0IFdpZGdpdHMgUHR5
    IEx0ZDEPMA0GA1UEAxMGc2VydmVyAgkAy2xbdQckXjIwCQYFKw4DAhoFAKBdMBgG
    CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEzMDEx
    MjM1NVowIwYJKoZIhvcNAQkEMRYEFEYNh8glwqIXGR/n6oYrApa8DaO5MA0GCSqG
    SIb3DQEBAQUABIGAHlgGsYK30RXWBvuQao0V73KIPQE1A6BCg7Y6Iag/xlmZ3rBB
    kFpszF/O2fB+t84pCHfV15ErZQEkAqIotkEYEgA3hAddEW5+RWUzp+3npHpW5OY7
    h3niP5Pj+r0P8EDgHe2j0Zb3dzj2mbwOshZD+FP1IcR8AmiTV3u35C6KAEsAAAAA
    AAA=
    ——-END PKCS7——-


    И сам запрос на возврат платежа:
    <returnPaymentRequest
    clientOrderId="46890"
    requestDT="2011-07-02T20:38:00.000Z"
    invoiceId="2000000433"
    shopId="6689"
    amount="10.00"
    currency="643"
    cause="Пользователь отказался принять заказ"
    />

    В новой версии API возврат платежа на Python выглядит так:
    refund = Refund.create({
        "amount": {
            "value": "2.00",
            "currency": "RUB"
        },
        "payment_id": "21741269-000d-50be-b000-0486ffbf45b0"
    })
    

    Вернётся понятный JSON, который можно разобрать чем угодно за минимальное время:
    {
        "id": "216742f7-0016-50be-b000-078a43a63ae4",
        "status": "succeeded",
        "amount": {
          "value": "2.00",
          "currency": "RUB"
        },
        "created_at": "2017-10-04T19:27:51.407Z",
        "payment_id": "21746789-000f-50be-b000-0486ffbf45b0"
      }

    Красота.

    4. Поддержка разных языков и технологий


    Ещё у нового API есть SDK для мобильных устройств, PHP, Python и Node.js. Чем бы ни занимались ваши бэкенд-ребята (ну, кроме совсем уж экзотических случаев), платежи через Кассу подключаются быстро. Если человек активно пишет на Python дольше пары месяцев — он справится с интеграцией.

    В прошлом году мы выпустили библиотеку для мобильных приложений на iOS и Android. С её помощью платёжные формы встраиваются в приложение и выглядят как его часть (и никаких WebView). Пользователи смогут оплатить заказ банковской картой, из кошелька в Яндекс.Деньгах, через Google Pay, Apple Pay или Сбербанк Онлайн.

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

    5. Регулярные платежи без шаманства


    Сразу после установки и настройки заработают платежи картой с предавторизацией средств — они встроены в API по умолчанию.
    Рекуррентные платежи (и картой, и из кошелька) тоже есть: нужно согласовать их со службой безопасности, но так было и в старом протоколе. Если при рекуррентном платеже используется карта с обязательным 3D-Secure, то новый API сначала вернёт ссылку на него.
    В общем, всё стало проще — здесь тоже не нужно выполнять длинные ритуалы с MWS, получением сертификатов и всеми остальными криптоужасами.

    6. Автоматические уведомления о смене статуса платежа


    Раньше приходилось вручную проверять статус каждого платежа, а теперь, если он изменился, разработчику автоматически упадёт уведомление.
    В API v3 встроены четыре вида автоматических уведомлений о статусе платежей:
    1. «Ожидает подтверждения мерчантом после оплаты»,
    2. «Оплачен»,
    3. «Отменён или произошла ошибка при платеже»,
    4. «Платеж возвращен».

    На старом протоколе для этого приходилось писать сложный MWS-метод listOrders, который показывал перечень и свойства заказов. 12 параметров, сложная логика отправки запроса и интригующая возможность получить ответ в формате CSV:

    status=0;error=0;processedDT=2011-08-02T14:46:58.096+03:00;orderCount=2
    shopId;shopName;articleId;articleName;invoiceId;orderNumber;paymentSystemOrderNumber;customerNumber;createdDatetime;paid;orderSumAmount;
    orderSumCurrencyPaycash;orderSumBankPaycash;paidSumAmount;paidSumCurrencyPaycash;paidSumBankPaycash;receivedSumAmount;receivedSumCurrencyPaycash;
    receivedSumBankPaycash;shopSumAmount;shopSumCurrencyPaycash;shopSumBankPaycash;paymentDatetime;paymentAuthorizationTime;payerCode;payerAddress;payeeCode;
    paymentSystemDatetime;avisoReceivedDatetime;avisoStatus;paymentType;agentId;uniLabel;environment
    1;"Ваш магазин";2;"Шапка-ушанка";2000024717776;"2011.08.02 09:07:32";483512879684006008;97881;2011-08-02T08:07:59.148+03:00;true;10.15;643;1003;10.15;643;
    1003;10.15;643;1003;10.15;643;1003;2011-08-02T08:07:59.684+03:00;483512879684006008;41003476047679;192.168.1.127;41003131475668;2011-08-02T08:07:59.684+03:00;
    2011-08-02T08:07:59.660+03:00;1000;AC;200002;1cd12967-0001-5000-8000-000000034fd8;Live
    1;"Ваш магазин";2;"Шапка-ушанка";2000024717780;2000024717780;483512937773006008;770367;2011-08-02T08:08:57.175+03:00;true;10.00;643;1003;10.00;643;
    1003;10.00;643;1003;10.00;643;1003;2011-08-02T08:08:57.773+03:00;483512937773006008;41003494819180;192.168.1.127;41003131475668;2011-08-02T08:08:57.773+03:00;
    2011-08-02T08:08:57.730+03:00;1000;AC;200002;1cd129a4-0001-5000-8000-000000034fe1;Live

    В новой версии так. Запрос:
    curl https://payment.yandex.net/api/v3/payments/{payment_id} \ -u <Идентификатор магазина>:<Секретный ключ>
    Ответ: 
    {
      "id": "22312f66-000f-5100-8000-18db351245c7",
      "status": "waiting_for_capture",
      "paid": true,
      "amount": {
        "value": "2.00",
        "currency": "RUB"
      },
      "created_at": "2018-07-18T10:51:18.139Z",
      "description": "Заказ №72",
      "expires_at": "2018-07-25T10:52:00.233Z",
      "metadata": {},
      "payment_method": {
        "type": "bank_card",
        "id": "22ebbf66-000f-5000-8000-18db351245c7",
        "saved": false,
        "card": {
          "first6": "555555",
          "last4": "4444",
          "card_type": "MasterCard"
        },
        "title": "Bank card *4444"
      },
      "test": false
    }

    7. Сразу понятно, в какой момент возникла ошибка


    Если платеж не прошел, то вместо «что-то пошло не так» новый API в явном виде даст понять, почему так вышло — например, на карте кончились деньги или пользователь хотел расплатиться через Сбербанк Онлайн, но он не подключен.
    Изредка могут возникать кратковременные «что-то пошло не так» — мы, конечно, с ними боремся (лид-редактор Наташа в этом месте кивает мне и показывает большой палец), но предсказать различия в маппинге ошибок у разных банков или неожиданное поведение софта иногда невозможно. Даже нам.
    В общем, если платёж отменен, то из ответа API сразу будет понятно, из-за чего:
    {
      "id": "22379b7b-000f-5000-9030-1a603a795739",
      "status": "canceled",
      "paid": false,
      "amount": {
        "value": "2.00",
        "currency": "RUB"
      },
      "created_at": "2018-05-23T15:24:43.812Z",
      "metadata": {},
      "payment_method": {
        "type": "bank_card",
        "id": "22977a7b-000f-5000-9000-1a603a795129",
        "saved": false
      },
      "recipient": {
        "account_id": "100001",
        "gateway_id": "1000001"
      },
      "test": false,
      "cancellation_details": {
        "party": "payment_network",
        "reason": "payment_method_restricted"
      }
    }

    8. Всё можно проверить, прежде чем начать


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

    Когда мы еще не запустили эту возможность, было доступно тестовое окружение, в котором можно попробовать API v3 с помощью REST-клиента Insomnia. Там представлены примеры для оплаты банковской картой, при этом наглядно показано какой запрос отправляется, какой ответ возвращается и что происходит на всех этапах процесса обмена данными.



    Для всех этапов интеграции и сопровождения у нас есть пошаговое руководство на русском и английском языках, а ещё подробнейший справочник по API.

    В общем, переходите на новый API, если ещё не, или подключайтесь к Яндекс.Кассе — там всё уже готово к вашему визиту.
    Яндекс.Деньги
    Как мы делаем Деньги

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

      0
      А чудо интерфейс исправили? В котором не видно часть платежей, которые видны из апи и менеджеры руками разводят.
        0
        Добрый день. Уточнил у техников, все созданные и оплаченные тестовые платежи видны в личном кабинете Яндекс.Кассы.
        +1
        Там %, сям %. А потом «А почему у вас за наличку дешевле?»
          0
          Действительно, почему?))) а если клиент заказал в подарок? а если получать будет не он? а если наличные у человека раз в неделю бывают (а таких человек много!). Потенциально все эти клиенты пошли в другой магазин, где есть онлайн-оплата, потому что им так в данном случае удобней. И это только самые очевидные случаи, конечно
            +1
            Вас никто не заставляет использовать это решение, вроде бы. Как бы, не хотите «там %, сям %» — продавайте сами, вручную :)
              0
              Так так и есть уже. Многие не крупные предприниматели, которым года 3 назад еще было особо без разницы что «по безналу», что за «нал» принимать за товар/услуги, сейчас с большей охотой берут «нал». И доходит до того, что открытым текстом говорят — хочешь дешевле, оплачивай наличкой. Хотя казалось бы по идее шли к «наоборот». Это следствие что «там процентик, сям процентик». Экваринг %, онлайн касса %, банк % и т.д. и т.д. Слишком аппетиты большие у посредников.
            +2
            Очень понравился новый API, хотя на практике и не получилось пока воспользоваться, но в дальнейшем планирую.

            Когда стоит ожидать обновление API выплат в таком же стиле?

              +1
              А зачем вы возитесь со всякими там улучшениями API вместо того, чтобы полностью реализовать у себя всю цепочку с онлайн-кассой? Никому не хочется разбираться в зоопарке ваших партнеров и тратить время на интеграцию с теми и с этими.

              Вы планируете сделать сквозное решение с арендой накопителя, так чтобы никакую кассу не видеть никогда и об интеграции с ней тоже не думать? :)
                0
                YaMoneyHelp, раз уж вы тут отвечаете, прокомментируйте пожалуйста разработку собственного решения для полностью «облачных» онлайн-касс.
                0
                Яндекс касса самый кривой продукт яндекса с которым сталкивался.

                «На Вашем старом аккаунте ошибка, которую мы не можем исправить. Просто заведите новый» — официальный ответ от техподдержки.

                Не юникод символы в запросах на колбеки и прочее. В итоге старая версия работает с кучей костылей, но работает! И желания проверять стабильность новой нет.
                  0
                  Здравствуйте, проверим этот ответ поддержки, пожалуйста, подскажите ваш shopID в Яндекс.Кассе.
                    0
                    Добрый вечер. Проблема была в том, что я в принципе не мог создать магазин. 500 ошибка при нажатии на кнопку подключить кассу.

                    Вот данные из емейла, может помогут идентифицировать запрос
                    13669927
                    CRM004517057

                    В итоге я зарегестрировал новый ящик и в нем магазин (shopId 191834), но не могу скачать свой договор. Скачивается пустой архив
                      0
                      Здравствуйте, может быть вопрос по другому юрлицу? К сожалению, по этим данным не видим никаких подобных обращений. Сейчас магазин работает.
                  0

                  Подскажите, как в новой версии API передать return_url для ситуации, когда платеж отменили? Сейчас только 1 url можно передать и он будет на ссылке "в магазин" и до оплаты, и после.

                    0
                    Добрый день!
                    Вот здесь даны подробные рекомендации по реализации returl_url.
                    0
                    Уже существет решение под WordPress/WooCommerce или имеет смысл его самому написать?
                      0
                      Добрый день!
                      Да, вот ссылка на решение.
                        0
                        А разве этот плагин не под вторую версию API? И не тестировался с 5й версией WordPress.
                          0
                          Плагин работает с API v3, его разрабатывали под 4 версию Wordpress, на совместимость с пятой версией он не тестировался.
                            0
                            Коллеги подсказали, что и с Wordpress 5 тоже работает.
                              0
                              Отлично! Спасибо
                        0
                        Это SDK работает с третьей верией API?
                          0
                          Да, именно с ней и работает.
                          0

                          В старой версии API есть куча интересных данных, вроде части номера карты и эффективной комиссии платежа, которых просто нет в новой. Так бы действительно стоило перейти.

                            0
                            На самом деле, номер карты уже давно есть: kassa.yandex.ru/developers/api#payment_object_payment_method_bank_card_card_first6

                            Насчет эффективной комиссии платежа – знаем, работаем над этим:)
                              0

                              Спасибо, это очень здорово.


                              Есть ещё большая проблема, почему новое API не так лучше старого. Сразу скажу что у меня есть проекты, где внедрено и старое, и новое API, и есть множество внедрений Stripe, PayPal и других, так что есть с чем сравнивать, и у меня было такое впечатление что новое API подаёт себя под тем соусом что больше не нужно слушать события, что больше нет этого неудобства номер один в старом API, когда интеграционное тестирование с использованием какого-то временного домена просто невозможно. Создаётся впечатление что новым API должно быть также удобно пользоваться как, например, API Stripe или PayPal (где вообще нет проблем с интеграционным тестированием). Выглядит оно очень похоже, и если бы это было так, это просто прекрасно.


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


                              Выход из этой ситуации есть: использовать те самые уведомления для проведения платежей. Получается так что полноценное интеграционное тестирование, end-to-end, с новым API тоже невозможно, так как события уходят на фиксированный адрес (что логично само по себе). И получается так что новое API удобно разве что тем, что не нужно сертификаты раз в год заменять. В остальном те же самые грабли. Если вы считаете что здесь есть какая-то мотивация переходить на новое, то, уверяю вас, эта вся ситуация не создаёт ровным счётом никакой мотивации для нас, разработчиков, агитировать или призывать владельцев магазинов переходить на новое API. Мы, наоборот, будет отсоветовать. Старое едва ли хуже.

                                0
                                Однако это не так, в новом API тоже необходимо слушать запросы. Например, человек оплачивает с карты, но данные для чека указаны какие-то не такие из-за человеческой ошибки, и чек не создаётся. Но человеку на сайте Яндекс.Кассы показывается сообщение что его платеж принят, и человек не возвращается на сайт, чтобы сайт мог перепроверить факт оплаты, и в итоге и заказ не оплачен, и человек не знает об этом. Никто не рад этому.
                                Вот эта часть не очень понятна. Почему пользователь не возвращается на сайт, если платеж принят? Хотелось бы посмотреть на реальные кейсы… Можно написать в нашу поддержку, и ребята из шопмастеров могли бы здесь помочь разобраться.

                                Выход из этой ситуации есть: использовать те самые уведомления для проведения платежей. Получается так что полноценное интеграционное тестирование, end-to-end, с новым API тоже невозможно, так как события уходят на фиксированный адрес (что логично само по себе).
                                Здесь, конечно, все корректно, но это особенности асинхронного процесса. Оно точно так же работает и у Stripe, и у PayPal.
                                  0

                                  После оплаты человек видит что-то такое:



                                  Это не я придумал такое, это из документации: https://kassa.yandex.ru/pay_by_yandex/


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


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


                                  Для интеграции платежей через Stripe и PayPal не нужно настраивать прием их уведомлений. Вообще не нужно. В случае Stripe и PayPal процесс оплаты завершается строго после обратного перехода на сайт магазина. Вот если бы с новым API была такая же процедура, это было бы совсем другое дело.


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

                                    0
                                    На самом деле, скриншот некорректный, после платежа пользователь видит:
                                    image
                                    С этого экрана всегда можно вернуться в магазин.

                                    Для интеграции платежей через 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-запросы.
                                      +1

                                      То есть, вы говорите, если нужно, чтобы всё было гладко, без уведомлений, как у Stripe и PayPal, то нужно использовать не-редиректный сценарий? Это который, для которого надо дорогую сертификацию по PCI DSS проходить?..


                                      Это, конечно, очень здорового, но это не то, что можно серьёзно предлагать малому бизнесу. Получается у нас патовая ситуация: использовать то, что работало бы чётко и гладко, нельзя, потому что дорого, а использовать то, что работает строго с уведомлениями, не имеет смысла потому что старое работает точно так же. Понимаете о чём я?

                                        0
                                        Нет. Но в США есть своя специфика – они не используют 3D-Secure, а значит и большинство сценариев являются без-редиректными.

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

                                        Если уведомления для вас реализовать проблематично по той или иной причине вы можете запрашивать статус транзакции с определенной переодичностью, используя GET-запрос
                                          0

                                          Уведомления реализовать не проблематично, проблематично тестировать всё это. Приходится делать много жестов руками, опрашивать статус транзакции, и всё это.


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


                                          Рассмотрим практическую ситуацию. Менеджер магазина ввёл в карточке товара какие-то не такие данные, на работу с которыми настроена касса. Или ввёл просто не те данные. Так или иначе, чек сделать удаётся. Но клиент видит что платеж прошел, и начинает переживать. Надо ли говорить что это ни разу не прекрасно. Собираетесь ли вы делать что-то с этой проблемой, если уж не с первой?


                                          Например, можно всё-таки поменять текст на менее категоричный, и более настойчиво отправить человека на сайт. А уж на сайте магазина можно и про ошибку написать, и статус платежа опросить. Угодить уважаемому клиенту. Как вы считаете?


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

                                            +1
                                            Уведомления реализовать не проблематично, проблематично тестировать всё это. Приходится делать много жестов руками, опрашивать статус транзакции, и всё это.

                                            У нас есть настройка авторедиректа на сайт. По запросу через менеджера можем включать и пользователь сразу будет возвращаться на сайт без промежуточного экрана
                                              0

                                              Спасибо, это отличная новость!


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


                                              Например, если тестовые версии разворачиваются на хосте staging.adc83b19e.example.com, где adc... случайный набор цифр, то в текущей схеме получать уведомления с тестового магазина без, опять же, большого количества действий, с настройкой прокси, который будет знать какие именно хосты сейчас используются, не получается. Если бы можно было указать куда должны уходить уведомления для конкретного тестового платежа, то проблема уведомлений была бы решена.


                                              Для настоящих платежей такое, конечно, не требуется.

                                                0
                                                Спасибо, это отличная новость!
                                                Надеемся, это поможет вам в вашей работе))
                                                Может быть вы ещё порадуете: в целях интеграционного тестирования было бы здорово в тестовом магазине при оформлении платежа иметь возможность указать, куда должны уходить уведомления об этом конкретном платеже.
                                                Пока обещать по этому поводу ничего не можем, но в целом — да, смотрим в сторону упрощения интеграции по уведомлениям.

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

                          Самое читаемое