Хотелось бы обратить ваше внимание на то, что кроме варианта реализации платежей на нашем старом платежном протоколе, есть другой, более удобный, быстрый и дешевый в разработке: интеграция на нашем новом платежном протоколе. Наш новый API стартовал в октябре 2017 и сейчас на нем работает порядка 40% наших контрагентов.
Практика показывает, что интеграция платежей на старом протоколе требует больше времени, чем на новом API (примерно в 5-10 раз). Интеграция на старом протоколе сложнее, как на этапе разработки, так и при дальнейшем сопровождении (замена сертификатов раз в год, нет штатной возможности уточнять статус по платежу, отсутствие мапинга карточных ошибок и т.д., - все эти вопросы решены в новом API).
- Привычное REST взаимодействие. Понятная архитектура и предсказуемость поведения. Старый протокол в этом плане был "белой вороной", где все по своему, где реализация не похожа на другие платежные платформы. Каждый отдельный метод платежа - это отдельный, не связанный с предыдущим методом синтаксис, сценарий и процесс. По мнению программистов, которые реализовали современные платежные протоколы, наш новый протокол соответствует стандартам и наследует логику известных платежных решений.
- Возвраты платежей из коробки. Не нужно реализовывать MWS со всеми сложностями, например: обязательная упаковка запросов в PKCS7-пакет, открытие доступов по IP, ежегодная генерация сертификатов и т.п., в том числе сложный синтаксис самих запросов. В новом API этих сложностей нет.
- Холды (платежи с предавторизацией средств) из коробки. Тоже не надо ничего дополнительно реализовывать, в новом API холды по-умолчанию.
- Рекурренты картами проще, без необходимости MWS. Требуется только согласование с СБ как и раньше. При рекурренте картой, требующей 3DS, вместо ошибки, теперь вы получаете ссылку на 3DS, которую отдаете плательщику и он сможет оплатить, введя код из sms. Никакого повторого ввода номера карты.
- Рекурренты кошельком, а не только картой. Холды на кошелечных платежах.
- СМС инвойсинг Сбербанка из коробки (с номера 900 приходит код и плательщик выполняет подтверждение отправкой кода по смс).
- Возможность запрашивать статус по платежу или листинг платежей из коробки. На старом протоколе надо было реализовывать сложный метод listOrders MWS.
- На текущий момент четыре вида автоматический уведомлений о платеже): 1) платеж ожидает подтверждения мерчантом после оплаты 2) платеж оплачен 3) платеж отменен или произошла ошибка при платеже 4) платеж возвращен. Количество таких колбеков будет больше. Для информационной системы контрагента это важно, чтобы не ходить за статусом каждого, а получать уведомление, если что-то по конкретному платежу изменилось. Рассматриваются планы по уведомления о чаржбек операциях.
- Мобильный SDK для IOS и Android.
- SDK для PHP, Python, Node.js
- Есть поддержка ApplePay и GooglePay в mSDK. Есть поддержка веб-режима для GooglePay и ApplePay.
- Мапинг ошибок платежа. Теперь, если платеж не прошел, то по API вы получаете информацию о причинах (см. п.8). Например, недостаточно средств на карте или плательщику не подключен Сбербанк.Онлайн. И т.д.
- Виджет (форма оплаты на вашем сайте, при оплате плательщик остается на вашем сайте на всех этапах оплаты; например, при оплате картой, номер карты плательщик будет вводить у вас на сайте и ни на какие другие сайты и сторонние страницы переходить не надо; считается, что если плательщик остается на сайте, это повышает конверсию в успешные платежи на 5-10%), т.н. безредиректный способ оплаты.
https://yookassa.ru/developers
- URL для уведомлений https://goo.gl/EWyjNn
- Return_url. https://goo.gl/MZGaEk
Чтобы попробовать новое API https://goo.gl/UTxiRc с помощью REST-клиента Insomnia.