Поиск по ключевым словам
/

1.9.11

Новые возможности

  1. Добавлен новый метод API /paymentTest.do для тестовой маршрутизации того или иного способа оплаты. Выполняет маршрутизацию оплаты по заданным исходным условиям и сообщает, в какой банк будет направлена реальная оплата при тех же самых условиях.

    Особенности метода:

    • Заказ перед вызовом данного метода должен быть зарегистрирован в Платежном сервисе.
    • Реальной оплаты не происходит.
    • Все банки Партнера по умолчанию считаются активными (доступными). Для имитации деактивации одного или нескольких банков это необходимо явно указать с помощью параметра disableGateways.

1.9.10

Новые возможности

  1. Добавлен новый способ оплаты SberPay на платежной странице Платежного сервиса (SBERPAY). Оплата SberPay по новому способу выполняется в платежном виджете Сбербанка. Существующий способ оплаты SBRF_SBOL не следует использовать в новых интеграциях. Он будет поддерживаться до тех пор, пока Партнеры не изменят свою интеграцию на новый способ оплаты, а затем будет удален.
  2. Добавлен новый способ оплаты через сервис Плати частями в Сбербанк (SBRF_BNPL). Для подключения нового способа оплаты обратитесь в службу поддержки.
  3. При приеме оплат по СБП через мобильные устройства (iOS, Android) на платежной странице добавлена возможность выбора банка Клиентом. Платежный сервис Роутер может маршрутизировать оплату в зависимости от банка клиента. В общем случае можно явно задать, из каких банков клиента в какие банки Партнера направлять оплату по СБП. В частности, имеется возможность задать маршрутизацию US-on-US для случаев, когда банк клиента входит в список банков Партнера.
  4. Добавлена возможность оплаты СБП по данным подписки НСПК — новые опциональные параметры sbpMemberId и sbpSubscriptionToken в вызове /paymentOrder.do. Если Партнер ранее не использовал сервис Роутер и имеет собственную базу данных СБП подписок, он может использовать эти данные для оплаты с помощью метода paymentOrder.do. Имеется возможность маршрутизации таких оплат в выбранный банк Партнера в зависимости от sbpMemberId (банка клиента).

  5. После оплаты СБП с созданием подписки Партнеру предоставляются НСПК-идентификаторы подписки (поля sbpMemberId и sbpSubscriptionToken):

    Эти данные могут быть впоследствии использованы в вызове /paymentOrder.do для оплаты подписки (вместо bindingId в /paymentOrderBinding.do)

  6. Добавлена возможность создания связок при оплате Yandex Paybox и последующая оплата с их использованием.

Изменения

  1. Добавлены новые правила валидации корзины orderBundle при регистрации заказа /register.do или /registerPreAuth.do. В основном валидация касается формата и длины полей.

  2. Изменен алгоритм определения IP-адреса, который возвращается в ответе getOrderStatusExtended.do. IP адрес берется из следующих источников (в порядке убывания приоритета):

    • адрес X-forwarder-for при получении запроса оплаты из платежной страницы сервиса Роутер;
    • значение поля ip, которое Партнер явно передал в запросе регистрации и/или оплаты;
    • адрес X-forwarder-for при получении API запроса регистрации и/или в оплаты.

1.9.9

Новые возможности

  1. Добавлена возможность оплаты по ссылке из Личного кабинета Платежного сервиса.
  2. Добавлен новый способ оплаты Yandex Paybox — более современная версия Яндекс Пэй с поддержкой Яндекс Сплит. Оплата происходит на веб-странице, предоставленной сервисами Яндекс. Получить платежную ссылку для перехода на эту веб-страницу возможно только через API Платежного сервиса. Переход к оплате c платежной страницы Платежного сервиса по соответствующей кнопке будет добавлен в следующих версиях.
  3. Добавлена возможность оплаты без ввода CVC-кода при использовании связки, если у Партнера есть соответствующее разрешение в банке, куда будет направлен платеж. Данная возможность доступна только на кастомизированных платежных страницах Партнеров. Для подключения обратитесь в службу поддержки.
  4. Добавлена возможность конвертации исходной валюты заказа в рубли при оплате по СБП, SberPay, AlfaPay, TPay и т.п. Может использоваться при оплате клиентами из РФ, если магазин Партнера предлагает оплату не в рублевой валюте, но Партнер имеет возможность работать с банками РФ. Для подключения обратитесь в службу поддержки.

Изменения

  1. Изменен код ошибки при запросе getBindings.do. Вместе с данными (список связок) вместо кода ошибки 99 возвращаются новые коды ошибок:
    • BD-102 — список связок может быть неполным, так как возникли ошибки при получении связок у одного или нескольких банков.
    • BD-103 — список связок полный (данные успешно получены от всех банков), но поля bankName и paymentSystem в связках могут отсутствовать или быть пустыми, так как возникла ошибка вспомогательного сервиса, определяющего принадлежность карты к банку и платежной системе.
    • BD-104 — комбинация "BD-102" и "BD-103", т.е. и список связок может быть неполным, и поля bankName, paymentSystem могут отсутствовать или быть пустыми.

1.9.8

В данной версии были произведены общие исправления и улучшения.

1.9.7

Новые возможности

  1. Добавлена возможность деактивации СБП подписок с помощью метода sbp_c2b/unBind.do.
  2. Добавлена возможность получения текущих настроек маршрутизации в виде JSON документа: settings/getRouterParams.do.
  3. Добавлена возможность маршрутизации заказов по значениям дополнительных параметров (jsonParams), передаваемых Партнером при регистрации или оплате заказа. Названия и значения параметров для маршрутизации необходимо предварительно согласовать со службой поддержки.

Изменения

  1. В успешные ответы методов decline.do, reverse.do, refund.do, deposit.do добавлено поле errorMessage со значением "Success".

1.9.6

Новые функции

  1. Добавлена возможность подписи API запросов в Платежный сервис. Загрузка сертификатов для проверки подписи выполняется Партнером через обращение в службу поддержки. В дальнейшем планируется предоставить Партнерам возможность загружать сертификаты самостоятельно в Личном кабинете Платежного сервиса.
  2. Добавлен новый API вызов /sbp_c2b/getBindings.do для получения связок СБП. Если Партнер направляет СБП-платежи в несколько банков, связки клиента будут получены из всех доступных банков.
  3. Добавлена возможность явного указания Партнером целевого банка для оплаты заказа. Новый параметр gwId при регистрации заказа /register.do или /registerPreAuth.do указывает, в какой банк необходимо будет направить оплату. В случае недоступности указанного банка платеж не будет никуда перенаправлен и завершится ошибкой.

1.9.5

Новые функции

  1. Добавлена возможность деактивации связок Клиентом на платежной странице Платежного сервиса. Для включения опции обратитесь в службу поддержки.
  2. Добавлена возможность указания комиссии Партнера при конвертации валюты (при направлении оплаты в зарубежный банк). Чтобы воспользоваться этой функцией, обратитесь в службу поддержки.

Изменения

  1. Усовершенствован механизм оплаты карточными данными из связки в другой банк. Теперь поддерживается автоматическое определение и передача в процессинг банка признака tii (transaction initiator indicator) — инициация оплаты клиентом или Партнером.

1.9.4

Внутренние доработки и исправление незначительных ошибок.

1.9.3

Новые функции

  1. Добавлена возможность маршрутизации оплат по СБП между несколькими Банками (по сумме заказа, по процентному соотношению между Банками). Для использования этой возможности Партнер должен заключить договор эквайринга с теми Банками, в которые планирует направлять платежи.
  2. В ответ getOrderStatusExtended.do добавлен идентификатор заказа в проприетарном шлюзе Сбербанка: transactionAttributes.externalOrderId. Данный параметр предназначен для Партнеров, направляющих платежи в Сбербанк.

Исправление ошибок

  1. Исправлен дефект с отображением логотипа Банка и стилизации при вводе карты или выборе связки.

1.9.2

Новые функции

  1. В методе instantPayment.do добавлена поддержка оплаты по связке — для этого вместо данных карты или токена нужно передать в метод параметр bindingId. Поддерживаются все функции как при обычной оплате eCom-связкой (paymentOrderBinding.do).

  2. При регистрации заказа register.do/registerPreAuth.do можно указать связку клиента одним из следующих способов:

    • bindingId — на платежной странице Платежного сервиса клиент сможет оплатить заказ только этой связкой.
    • defaultBindingId — связка будет выбрана на платежной странице Платежного сервиса как платежное средство по умолчанию. Клиент сможет выбрать другое платежное средство, если при регистрации были разрешены другие способы оплаты.

    На оплату по API эти параметры не влияют.

  3. В правилах маршрутизации появилась возможность явного отклонения оплат в Платежном сервисе по критериям (например, иностранный эмитент, попадание карты в определенный диапазон и т.п.). Запросы в банк-эквайер при этом не отправляются. Чтобы настроить критерии, обратитесь в службу поддержки.

1.9.1

Новые функции

  1. Новые методы для получения публичных ключей:

    • Добавлен метод /se/keys.do. Метод возвращает те же самые ключи RSA-2048, что и /keys.do, но к содержимому ключа добавлены маркеры начала и конца ключа (-----BEGIN PUBLIC KEY----- и -----END PUBLIC KEY-----).
    • Добавлена поддержка алгоритма шифрования RSA-4096: RSA/NONE/OAEPWithSHA-512AndMGF1Padding. Публичные ключи RSA-4096 отдаются по запросу /se/keys2.do. Для MGF необходимо использовать хэш SHA-512.
    • Метод /keys.do помечен как deprecated. При использовании интеграции с передачей зашифрованных карточных данных рекомендуется перейти на алгоритм RSA-4096 или, как минимум, на получение ключей RSA-2048 через /se/keys.do.

  2. Если в запросе /register.do указывается dynamicCallbackUrl, то при получении обратного вызова (при изменении статуса заказа в банке) в параметрах запроса среди прочего добавляется параметр gwId, по которому можно будет понять, какой именно банк выполнил обратный вызов.

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

  3. Поля paymentSystem и bankName в методе /getBindings.do заполняются из альтернативного источника данных, если сам банк их не указал.

  4. Добавлена поддержка значения features: ["FORCE_CREATE_BINDING"] при регистрации заказа /register.do. При использовании этого значения флажок "Сохранить карту" отображается на платежной странице, включен, и заблокирован для отключения.

  5. В статус заказа getOrderStatusExtended.do добавлен блок информации secureAuthInfo (информация о выполненной 3DS авторизации владельца).

    В будущих релизах в данный блок будут добавлены также поля aResTransStatus, rReqTransStatus, threeDsProtocolVersion. На момент текущего релиза банк не предоставляет этих данных.

  6. Добавлена поддержка оплаты QR кодом T-Pay (только в Т-Банк) на платежной странице и через API.

Изменения

  1. HTTP-код ответа Платежного сервиса при вызовах платежных методов изменен с HTTP 502 на HTTP 200 при получении от ПЦ следующих кодов операции (actionCode), связанных с картой владельца:

    • -2023: Аутентификация не может быть выполнена эмитентом карты (U в ARes)
    • 5: Карта была отклонена по неизвестной причине (Отказ сети проводить транзакцию)
    • 82: Некорректный CVC/CVV код
    • 116: На карте недостаточно средств для завершения покупки
    • 120: Эмитент карты отклонил платеж
    • 125: Попытка возврата на сумму, больше холда, попытка возврата нулевой суммы
    • 208: Эмитент карты считает карту утерянной
    • 209: Клиент превысил доступный баланс, кредитный лимит или лимит суммы транзакции на карте
    • 555: Ограничение по карте (эмитент запретил интернет транзакции по карте)
    • 902: Ограничение по карте (владелец карты пытается выполнить транзакцию, которая для него не разрешена)
    • 903: Предпринята попытка выполнить транзакцию на сумму, превышающую лимит, заданный банком-эмитентом
    • 1111: Отклонение по причине превышения количества попыток оплаты по карте
    • 71015: Указаны неправильные данные карты (CVC/CVV, Expiry, Cardholder)

    Формат и содержание тела ответа не изменились (errorCode + errorMessage)

  2. HTTP-код ответа Платежного сервиса изменен с HTTP 502 на HTTP 200 при запросе чека по несуществующему заказу. Формат и содержание тела ответа не изменились.

  3. HTTP-код ответа Платежного сервиса изменен с HTTP 502 на HTTP 429 при превышении лимита запросов (RPS) в банк. Формат и содержание тела ответа не изменились.

  4. Повторный вызов /instantPayment.do по одному и тому же номеру заказа возвращает ошибку (раньше допускался повтор instantPayment с тем же номером заказа, если первая попытка закончилась неудачей)

  5. Параметр backUrl в методе /instantPayment.do стал обязательным. Ранее был опциональным, но при его отсутствии возникала ошибка при оплате в Банк.

1.9.0

Новые функции

  1. Добавлена поддержка цифровых рублей при оплате через универсальный QR-код.
  2. Добавлена поддержка оплаты через Alfa Pay (только карты, без связок).
  3. Добавлен новый опциональный параметр externalRefundId при возвратах.
  4. Добавлена поддержка работы со связками v2:
    • добавлен новый API вызов installmentPayment.do — оплата (списание средств) по рассрочке;
    • добавлен новый необязательный доп. параметр installments при регистрации заказа в Платежном сервисе и при вызове instantPayment;
    • добавлен новый необязательный параметр bindingType в запросе getBindings.do — фильтр по типу возвращаемых связок;
    • добавлен новый необязательный параметр tii в запросы register.do, paymentOrder.do, paymentOrderBinding.do, instantPayment.do;
    • добавлены новые необязательные параметры originalPaymentNetRefNum, originalPaymentDate в запрос paymentOrder.do;
    • добавлен новый необязательный параметр paymentNetRefNum в ответе getOrderStatusExtended.do (для последующего его использования в качестве originalPaymentNetRefNum).

  5. Добавлено поле для указание email клиента на платежной странице (для получения фискального чека).

  6. Добавлена возможность конвертации валюты заказа внутри Платежного сервиса при маршрутизации оплаты в банк за пределами России.

  7. В вызовах paymentOrder.do, paymentOrderBinding.do, yandex/payment.do добавлен новый опциональный параметр threeDSVer2FinishUrl.

Изменения

  1. Изменен код HTTP ответа при попытке оплаты просроченного заказа. Возвращается HTTP код 400 (ранее возвращался код 500). Код ошибки errorCode=94 не изменился.

1.8.3

Новые функции

  1. При запросе статуса заказа в Платежном сервисе, в параметре orderId в качестве значения можно передавать идентификатор заказа в банке. Платежный сервис Роутер сам определяет, какому банку принадлежит данный заказ.
  2. При выборе сохраненной карты на платежной странице добавлена передача информации для отображения логотипа банка и платежной системы. Может использоваться в будущих релизах для отображения логотипа и стиля банка-эмитента при выборе связки на платежной странице
  3. При начале оплаты заказа через Платежный сервис Роутер блокируется повторный (параллельный) запрос оплаты того же самого заказа, пока первая попытка не завершится. Исправление дефекта двойных оплат, когда первая попытка оплаты через Платежный сервис Роутер уходит в таймаут в одном банке по причине сбоя в ПЦ банка, и не дожидаясь ответа Платежного сервиса, поступает вторая оплата того же заказа другим платежным средством, которая успешно маршрутизируется в другой банк.

1.8.2

Новые функции

  1. Добавлен новый метод instantPayment.do
  2. При внезапном отключении процессинга банка (получение нескольких таймаутов процессинга за короткое время) Платежный сервис Роутер снимает трафик на некоторое время с этого банка и переключает в другой банк. Правила выбора другого банка задаются в настройках Партнера.

Изменения

  1. Установлено ограничение на длину orderNumber в запросах: 32 символа.

1.8.1

Новые функции

  1. Платежный сервис Роутер отклоняет оплату заказа, если заказ с таким же номером был зарегистрирован в целевом банке, минуя Платежный сервис Роутер (напрямую).

Изменения

  1. При регистрации в Платежном сервисе заказа с feature VERIFY платежная страница Платежного сервиса отображает форму сохранения карты, а не платежа. Форма сохранения карты не имеет обычных атрибутов платежа (сумма, номер заказа и др.).

    Партнер должен иметь права на использование VERIFY.

1.8.0

Новые функции

  1. Кэширование настроек роутинга и настроек некоторых способов оплаты. Обновление настроек роутинга фактически применяется с задержкой до 3-5 минут.
  2. Добавлен API метод decline.do для отмены неоплаченного заказа.

Изменения

  1. Добавлена возможность преднамеренно (планово) исключать определенный банк (банки) из маршрутизации по запросу Партнера или исключать банк из маршрутизации силами техподдержки при проведении плановых работ в этом банке.

    Также Платежный сервис Роутер с некоторой периодичностью (3-5 минут) выполняет health check банков, и в случае недоступности банка автоматически исключает его из маршрутизации.

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

  2. При технической ошибке регистрации заказа в банке (ответ с HTTP кодами 403 Forbidden, 502 Bad gateway, 504 Gateway timeout) Платежный сервис Роутер сразу выбирает альтернативный банк для регистрации и оплаты заказа. Выбор альтернативного банка основывается на правилах Партнера (если они были предоставлены), либо на внутренних правилах Платежного сервиса.

  3. API метод getBindings.do по умолчанию возвращает все связки клиента, без фильтрации. В ответе могут быть две связки с одни и тем же PAN карты, но из разных банков. Фильтрация связок в getBindings.do может быть включена по требованию Партнера. Ранее список связок всегда фильтровался, чтобы в ответе присутствовали только уникальные PAN.

    Если Партнер не включает фильтрацию связок, при наличии в ответе getBindings.do связок с одинаковым PAN Партнер должен выбирать связку самостоятельно, основываясь на своих критериях (из определенного банка, самую свежую, первую с данным PAN и т.д.)

  4. Изменены коды HTTP ответа Платежного сервиса при возникновении бизнес-ошибок (не технических).

    • Ответы Платежного сервиса с errorCode 8,9,11 теперь сопровождаются кодом HTTP 200 Ok независимо от HTTP кода ответа банка (ранее Платежный сервис Роутер возвращал HTTP 5xx).
    • Для остальных errorCode HTTP статус ответа Платежного сервиса остается HTTP 5xx.

1.7.6

Новые функции

  1. Добавлена поддержка оплаты SberPay по сценарию app2app. При регистрации заказа с параметром app2app возвращается deepLink на МП СБОЛ.
  2. Для Партнеров, ранее работающих с РБС без Платежного сервиса, в методы refund, deposit, getReceiptStatus, getOrderStatusExtended добавлена поддержка запросов в Платежный сервис Роутер с идентификатором заказа (mdOrder) банка. Запросы переадресуются в тот банк, с которым работал Партнер до перехода на Платежный сервис Роутер.

Изменения

  1. Реализовано отслеживание времени жизни заказа в Платежном сервисе. Если заказ не был оплачен за это время, Платежный сервис Роутер возвращает статус заказа 6 (DECLINED). Ранее Платежный сервис Роутер возвращал статус -1 (PREREGISTERED) неограниченное количество времени.
  2. Изменена логика формирования redirectUrl после оплаты заказа. При неудаче redirectUrl указывает либо на failUrl (если он был указан при регистрации), либо на returnUrl, если failUrl неизвестен. Финишная страница (finish.html) больше не используется.

1.7.5

Новые функции

  1. Добавлена поддержка родительско-дочерней схемы мерчантов. Новый параметр merchantLogin (логин дочернего мерчанта) в методах register и getBindings.
  2. Добавлены новые поля в ответ getOrderStatusExtended: approvalCode, actionCode, actionCodeDescription.
  3. При открытии платежной страницы запрошенные способы оплаты проверяются на наличие соответствующих прав и настроек. Если они отсутствуют, такой способ оплаты убирается из платежной страницы, даже если был запрошен при регистрации.

Изменения

  1. При вызове paymentOrderBinding с включенной настройкой "Разворачивать связку в карточные данные" платеж всегда происходил картой, независимо от целевого банка. Начиная с 1.7.5, если целевой банк совпадает с банком, который хранит связку, оплата туда будет выполнена по связке, а не по карте.
  2. При запросе связок (getBindings и связки на платежной странице) происходит фильтрация списка связок. Если одна и та же карта привязана в разных банках, возвращается только самая "свежая" связка (по дате создания). Ранее возвращались все связки для одной и той же карты.

1.7.0 - 1.7.4

Новые функции

  1. Добавлена поддержка двухстадийных платежей (методы registerPreAuth и deposit).

  2. Добавлен способ оплаты SberPay (с помощью платежной страницы и через API). Поддержка доп. параметра back2app=true при регистрации заказа.

  3. Добавлена маршрутизация (выбор банка) при оплате по связке. Новый параметр мерчанта expandBindingToCardData. Если установлен в true - при оплате связкой из нее восстанавливаются карточные данные, и платеж картой может быть направлен в другой банк, а не в тот, где хранится связка.

  4. Добавлена маршрутизация (выбор банка) по сумме заказа и по наличию feature заказа VERIFY (для привязки карты с нулевой суммой).

Исправление ошибок

  1. Исправление в ответе на запрос статуса getOrderStatusExtended. Поле orderId теперь содержит идентификатор заказа в Платежном сервисе, gwOrderId — идентификатор заказа в ПШ (было раньше: orderId и gwOrderId содержали идентификатор заказа в ПШ, идентификатор заказа в Платежном сервисе был в доп. параметрах заказа).

  2. Исправление в ответе на запрос рекуррентной оплаты recurrentPayment: формат ответа приведен к полному соответствию со статусом заказа getOrderStatusExtended (включая изменения в параметре orderId).

  3. Изменен сценарий привязки карт с использованием специального мерчанта.

До версии 1.7 привязка карт с использованием специального логина Партнера происходила через регистрацию заказа в Платежном сервисе и последующую авторизацию (холдирование средств) или списание. При этом Платежный сервис Роутер выбирал между холдированием или списанием на основании настроек Партнера.

Начиная с версии 1.7 появилась полноценная поддержка двухстадийной оплаты. Удалена настройка мерчанта, которая устанавливает, что происходит при привязке: списание или холдирование. Теперь при привязке карт с использованием специального мерчанта Партнер должен самостоятельно решать, будет ли он выполнять холдирование или списание. В зависимости от этого, при регистрации заказа для привязки карты необходимо использовать либо registerPreAuth, либо register.

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

Категории:
router API V1
Категории
Результаты поиска
Навигация
Перейти
Закрыть
Категории
Результаты поиска