1.9.11

New features

1. Added a new API endpoint /paymentTest.do for test routing of payments with particular payment way. The call routes payments based on specified initial conditions and returns the bank to which the actual payment shall be sent under the same conditions.

   The endpoint features:

   • The order must be registered in the Payment Service before calling this method.
   • No actual payment occurs.
   • All Partner's banks are considered active (available) by default. To simulate the deactivation of one or more banks, explicitly specify them in disableGateways array.

1.9.10

New features

1. Added a new payment method SberPay on the payment page of the Payment service (SBERPAY). SberPay payments using the new method are processed in the Sberbank payment widget. The existing payment method, SBRF_SBOL, is now deprecated, so do not use it in new integrations. It will be supported until Partners change their integration to the new payment method and then will be deleted.
2. A new payment method Pay in parts to Sberbank (SBRF_BNPL). To enable the new payment method, please contact technical support.
3. When accepting payments via the SBP from mobile devices (iOS, Android), the payment page now features the widget for client's bank selection. The AntiDDOS Router payment service can route payments based on the client's bank. Generally, you can explicitly specify from which client banks to which Partner banks to route SBP payments. Most importantly, US-on-US routing can be configured if the client's bank is among the Partner's banks.
4. Added the ability to make SBP payments using NSPK subscription data: new optional parameters sbpMemberId and sbpSubscriptionToken in the /paymentOrder.do method. If the Partner has not previously used the AntiDDOS Router service and has its own SBP subscription database, these data can be used for subscription payments via paymentOrder.do. It is possible to route such payments to the Partner's selected bank depending on the sbpMemberId (the client's bank).

5. After an SBP payment with subscription created, the Partner is provided with the NSPK subscription identifiers (the sbpMemberId and sbpSubscriptionToken fields):
   

   • in the response to getOrderStatusExtended.do, in the transactionAttributes block
   • in the response to sbp_c2b/getBindings.do

   This data can be subsequently used in the /paymentOrder.do call for subscription payment (instead of bindingId in /paymentOrderBinding.do)

6. Added the ability to create Yandex Paybox store credentials and to make payments using them.

Changes

1. Added new rules of orderBundle fields validation in the order registration requests /register.do and /registerPreAuth.do. Validation mainly concerns the format and length of fields.

2. The algorithm for determining the IP address returned in the response to getOrderStatusExtended.do has been changed. The IP address is taken from the following sources (in descending order of priority):

   • the X-forwarder-for address when receiving a payment request from the AntiDDOS Router service payment page;
   • the ip field value that the Partner explicitly passed in the registration and/or payment request;
   • the X-forwarder-for address when receiving the API registration and/or payment request.

1.9.9

New features

1. Added the pay by link function in the Merchant portal of the Payment service.
2. Added the new payment way Yandex Paybox. This is a more modern version of Yandex Pay with support for Yandex Split. Payment takes place on a webpage provided by Yandex. A payment link to this webpage can only be obtained through the Payment service API. The use of Yandex Paybox payment from the Payment service payment page via the corresponding button will be added in future versions.
3. Added the ability to pay without entering a CVC code when using stored credentials, provided the Partner has corresponding permission in the bank to which the payment will be routed. This feature is only available on Partners' customized payment pages. To enable this feature, please contact support.
4. Added the ability to convert the original order currency to rubles when paying via SBP, SberPay, AlfaPay, TPay, etc. This can be used by customers from the Russian Federation if the Partner's store does not offer payment in rubles, but the Partner is able to work with Russian banks. To enable this feature, please contact support.

Changes

1. Changed the error code that may be returned by getBindings.do. Instead of error code 99, new error codes are returned along with the data (list of stored credentials):
   
   • BD-102: the list of stored credentials may be incomplete, as errors occurred when receiving stored credentials from one or more banks
   • BD-103: the list of stored credentials is complete (data successfully received from all banks), but the bankName and paymentSystem fields may be missing or empty, as an error occurred in the auxiliary service that determines the card's affiliation with the bank and payment system.
   • BD-104: both BD-102 and BD-103 occurred, i.e. the list of stored credentials may be incomplete and the bankName and paymentSystem fields may be missing or empty.

1.9.8

This version includes general improvements and fixes.

1.9.7

New features

1. Added the ability to deactivate SBP subscriptions using the sbp_c2b/unBind.do method.
2. Added the ability to get current routing settings as a JSON document: settings/getRouterParams.do.
3. Added the ability to route orders based on the values ​​of additional order parameters (jsonParams) passed by the Partner in the order registration or payment request. The names and values ​​of the parameters for routing must be agreed upon in advance with the support service.

Changes

1. Added errorMessage field with value "Success" to successful responses of the following methods: decline.do, reverse.do, refund.do, deposit.do.

1.9.6

New features

1. Added the ability to sign API requests to the Payment Service. The Partner can upload certificates for signature verification by contacting the support service. In the future releases, the ability to upload certificates will be available in the Merchant portal of the Payment service.
2. Added the new API call /sbp_c2b/getBindings.do to fetch SBP stored credentials. If the Partner sends SBP payments to several banks, the client's stored credentials will be obtained from all available banks.
3. Added the ability for the Partner to explicitly specify the target bank for order payment. The new gwId parameter when registering an order via /register.do or /registerPreAuth.do indicates which bank the payment should be sent to. If the specified bank is unavailable, the payment will not be redirected anywhere and will end with an error.

1.9.5

New features

1. Added the ability for the client to deactivate stored credentials right on the payment page of the Payment service. Contact support to enable this feature.
2. Added the ability to specify the Partner's commission when converting currency (when sending a payment to a foreign bank). To use this function, contact the support service.

Changes

1. Improved the routing of payments to another bank using card data extracted from stored credentials. Now we support automatic detection and transmission of tii (transaction initiator indicator) to the bank's processing system to indicate if payment is initiated by the client or Partner.

1.9.4

Internal improvements and minor bug fixes.

1.9.3

New features

1. Added the ability to route SBP payments to several banks (by order amount, by percentage ratio between banks). To use this option, the Partner must enter into an acquiring agreement with the banks to which the payments will be routed.
2. In the response to getOrderStatusExtended.do request, added order identifier in Sberbank proprietary gateway: transactionAttributes.externalOrderId. This parameter is intended for Partners routing their payments to Sberbank.

Bug fixes

1. Fixed the display of the Bank logo and styling when entering card data or selecting stored credentials.

1.9.2

New features

1. Added support for payment with stored credential via the instantPayment.do method. To use this function, pass the bindingId parameter instead of card data or a token. The same functions are supported as with a regular payment via an eCom stored credential (paymentOrderBinding.do).

2. The client's stored credential can be passed when registering orders with register.do/registerPreAuth.do in one of the following ways:
   

   • bindingId: on the payment page of the Payment Service, the client will be able to pay for the order only with this stored credential.
   • defaultBindingId: the stored credential is selected on the payment page of the Payment Service as the default payment method. The client can select another payment method if any was allowed at registration.

   These parameters do not affect payment via the API.

3. The routing rules now allow explicit rejection of payments in the Payment Service based on some criteria (e.g. foreign issuer, card within a certain range, etc.). No requests are sent to an acquiring bank. Contact support to set up the criteria.

1.9.1

New Features

1. New methods for obtaining public keys:

   • Added method /se/keys.do. The method returns the same RSA-2048 keys as /keys.do, but markers indicating the start and end of the key (-----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY-----) have been added to the key content.
   • Added support for RSA-4096 encryption algorithm: RSA/NONE/OAEPWithSHA-512AndMGF1Padding. RSA-4096 public keys are provided upon request at /se/keys2.do. MGF requires using SHA-512 as a hash.
   • The method /keys.do is marked as deprecated. When integrating with encrypted card data transfer, it is recommended to switch to the RSA-4096 algorithm or, at least, obtain RSA-2048 keys through /se/keys.do.

2. If dynamicCallbackUrl is specified in the request /register.do, then upon receiving a callback (when the order status changes in the bank), the gwId parameter is added to the request parameters along with others, allowing identification of the bank that performed the callback.

   This is necessary in cases where, during the payment process, the client makes multiple attempts while changing the payment method (e.g., entering a different card). In such cases, the same order can appear in two different banks. Therefore, when using dynamicCallbackUrl, it is possible to receive callbacks for the same order from different banks.

3. The fields paymentSystem and bankName in the method /getBindings.do are populated from an alternative data source if the bank itself did not specify them.

4. Added support for the value features: ["FORCE_CREATE_BINDING"] when registering an order /register.do. When using this value, the "Save card" checkbox is displayed on the payment page, enabled, and locked for deactivation.

5. Added the secureAuthInfo block (information about completed 3DS authentication of the cardholder) to the order status getOrderStatusExtended.do.

   In future releases, this block will also include the fields aResTransStatus, rReqTransStatus, and threeDsProtocolVersion. At the time of this release, the bank does not provide this data.

6. Added support for payment via T-Pay QR code (in T-Bank only) on the payment page and via API.

Changes

1. The HTTP response code of the Payment Service for payment method calls has been changed from HTTP 502 to HTTP 200 when receiving the following operation codes (actionCode) related to the cardholder from the processing center:

   • -2023: Authentication cannot be performed by the card issuer (U in ARes)
   • 5: The card was declined for unknown reasons (network refusal to process the transaction)
   • 82: Incorrect CVC/CVV code
   • 116: Insufficient funds on the card to complete the purchase
   • 120: The card issuer declined the payment
   • 125: Attempted refund for an amount greater than the hold, or a zero-amount refund attempt
   • 208: The card issuer considers the card lost
   • 209: The client exceeded the available balance, credit limit, or transaction amount limit on the card
   • 555: Card restriction (issuer prohibited internet transactions with the card)
   • 902: Card restriction (the cardholder is attempting to perform a transaction not permitted for them)
   • 903: An attempt was made to perform a transaction exceeding the limit set by the issuing bank
   • 1111: Rejection due to exceeding the number of payment attempts with the card
   • 71015: Incorrect card data specified (CVC/CVV, Expiry, Cardholder)

   The response body format and content (errorCode + errorMessage) remain unchanged.

2. The HTTP response code of the Payment Service has been changed from HTTP 502 to HTTP 200 when querying a receipt for a nonexistent order. The response body format and content remain unchanged.

3. The HTTP response code of the Payment Service has been changed from HTTP 502 to HTTP 429 when exceeding request rate limit (RPS) to the bank. The response body format and content remain unchanged.

4. A repeated call to /instantPayment.do with the same order number now returns an error (previously, a repeated instantPayment with the same order number was allowed if the first attempt failed).

5. The backUrl parameter in the method /instantPayment.do is now mandatory. Previously optional, but its absence caused payment errors in the bank.

1.9.0

New Features

1. Added support for digital rubles when paying via a universal QR code.
2. Added support for Alfa Pay payments (cards only, without stored credentials).
3. Added new optional parameter externalRefundId for refunds.
4. Added support for working with v2 stored credentials:
   
   • added a new API call installmentPayment.do — payment (fund withdrawal) for installments;
   • added a new optional additional parameter installments when registering an order in the Payment Service and when calling instantPayment;
   • added a new optional parameter bindingType in the getBindings.do request — filter by the type of returned stored credentials;
   • added a new optional parameter tii in the requests register.do, paymentOrder.do, paymentOrderBinding.do, instantPayment.do;
   • added new optional parameters originalPaymentNetRefNum, originalPaymentDate in the paymentOrder.do request;
   • added a new optional parameter paymentNetRefNum in the getOrderStatusExtended.do response (for subsequent use as originalPaymentNetRefNum).

5. Added a field to specify the client's email on the payment page (to receive a fiscal receipt).

6. Added the ability to convert the order currency within the Payment Service when routing a payment to a bank outside of Russia.

7. Added a new optional parameter threeDSVer2FinishUrl to paymentOrder.do, paymentOrderBinding.do, yandex/payment.do calls.

Changes

1. Changed the HTTP response code when attempting to pay for an expired order. HTTP code 400 is now returned (previously code 500 was returned). The error code errorCode=94 remains unchanged.

1.8.3

New Features

1. When requesting the order status in the Payment Service, the orderId parameter can now accept the bank's order identifier as its value. The Payment Service AntiDDOS Router will independently determine which bank the order belongs to.
2. When selecting a saved card on the payment page, information transmission has been added to display the bank's and payment system's logos. This may be used in future releases to display the logo and style of the issuing bank when selecting a card link on the payment page.
3. When initiating payment for an order via the Payment Service AntiDDOS Router, a duplicate (parallel) payment request for the same order is blocked until the first attempt is completed. This resolves the defect of double payments, where the first payment attempt through the Payment Service AntiDDOS Router times out at one bank due to a failure in the bank's processing center, and without waiting for the Payment Service's response, a second payment for the same order is made using another payment method, successfully routed to a different bank.

1.8.2

New Features

1. Added a new method instantPayment.do
2. In case of sudden processing disconnection from a bank (receiving multiple processing timeouts in a short period), the Payment service AntiDDOS Router redirects the traffic away from this bank for some time and switches to another bank. The rules for selecting another bank are defined in the Partner's settings.

Changes

1. A restriction on the length of orderNumber in requests has been established: 32 characters.

1.8.1

New Features

1. The Payment Service AntiDDOS Router rejects the payment of an order if an order with the same number was registered in the target bank bypassing the Payment Service AntiDDOS Router (directly).

Changes

1. When registering an order with the feature VERIFY in the Payment Service, the Payment Service's payment page displays a card saving form instead of a payment form. The card saving form does not have the usual payment attributes (amount, order number, etc.).

   The partner must have rights to use VERIFY.

1.8.0

New Features

1. Caching of routing settings and some payment method settings. The update of routing settings is actually applied with a delay of up to 3-5 minutes.
2. Added API method decline.do for canceling an unpaid order.

Changes

1. Added the ability to intentionally (planned) exclude a specific bank (or banks) from routing upon Partner's request or exclude a bank from routing by the support team during planned maintenance in that bank.

   Additionally, the Payment Service AntiDDOS Router periodically (every 3-5 minutes) performs health checks on banks, and in case of bank unavailability, it automatically excludes it from routing.

   Payments that, according to routing rules, were supposed to be processed by the excluded bank are automatically redirected to an alternative bank.

2. In case of a technical error during order registration in the bank (response with HTTP codes 403 Forbidden, 502 Bad Gateway, 504 Gateway Timeout), the Payment Service AntiDDOS Router immediately selects an alternative bank for registration and payment. The choice of an alternative bank is based on the Partner's rules (if provided) or the internal rules of the Payment Service.

3. The API method getBindings.do by default returns all the client's stored credentials without filtering. The response may contain two stored credentials with the same card PAN, but from different banks. Filtering of stored credentials in getBindings.do can be enabled upon Partner's request. Previously, the list of stored credentials was always filtered so that only unique PANs were present in the response.

   If the Partner does not enable stored credential filtering, then in the case where getBindings.do includes stored credentials with the same PAN, the Partner must select a stored credential based on their own criteria (e.g., from a specific bank, the most recent one, the first one with this PAN, etc.).

4. Changed the HTTP response codes of the Payment Service for business errors (non-technical).
   

   • Payment Service responses with errorCode 8, 9, 11 now return HTTP 200 Ok regardless of the bank's HTTP response code (previously, the Payment Service AntiDDOS Router returned HTTP 5xx).
   • For other errorCodes, the HTTP status of the Payment Service response remains HTTP 5xx.

1.7.6

New Features

1. Added SberPay payment support for the app2app scenario. When registering an order with the app2app parameter, a deepLink to the SberBank Online mobile app (МП СБОЛ) is returned.
2. For Partners previously operating with RBS without the Payment Service, the methods refund, deposit, getReceiptStatus, getOrderStatusExtended have been updated to support requests to the Payment Service AntiDDOS Router using the bank's order identifier (mdOrder). Requests are redirected to the bank the Partner worked with before transitioning to Payment Service AntiDDOS Router.

Changes

1. Implemented order lifecycle tracking in the Payment Service. If the order is not paid within this timeframe, Payment Service AntiDDOS Router returns the order status 6 (DECLINED). Previously, Payment Service AntiDDOS Router returned the status -1 (PREREGISTERED) indefinitely.
2. Changed the logic of forming the redirectUrl after order payment. In case of failure, the redirectUrl points either to failUrl (if specified during registration) or to returnUrl, if failUrl is unknown. The final page (finish.html) is no longer used.

1.7.5

New Features

1. Added support for the parent-child merchant schema. A new parameter merchantLogin (login of the child merchant) in the register and getBindings methods.
2. New fields added in the getOrderStatusExtended response: approvalCode, actionCode, actionCodeDescription.
3. When the payment page is opened, the requested payment methods are checked for the presence of corresponding permissions and settings. If they are absent, such a payment method is removed from the payment page, even if it was requested during registration.

Changes

1. When calling paymentOrderBinding with the "Expand the bundle into card data" setting enabled, the payment was always made by card, regardless of the target bank. Starting from version 1.7.5, if the target bank matches the bank that stores the bundle, the payment will be made via the bundle rather than the card.
2. When requesting stored credentials (getBindings and stored credentials on the payment page), the list of stored credentials is filtered. If the same card is linked in different banks, only the "freshest" stored credential (based on the creation date) is returned. Previously, all stored credentials for the same card were returned.

1.7.0 - 1.7.4

New Features

1. Added support for two-stage payments (methods registerPreAuth and deposit).

2. Added payment method SberPay (via payment page and API). Support for the additional parameter back2app=true when registering an order.

3. Added routing (bank selection) when paying with a stored credential. New merchant parameter expandBindingToCardData. If set to true, when paying via a stored credential, card data is restored from it, and the card payment can be directed to another bank rather than the one where the stored credential is stored.

4. Added routing (bank selection) based on the order amount and the presence of the order VERIFY feature (for zero-amount card stored credential).

Bug Fixes

1. Fix in the response to the getOrderStatusExtended status request. The field orderId now contains the order ID in the Payment Service, and gwOrderId contains the order ID in the Gateway (previously: both orderId and gwOrderId contained the order ID in the Gateway, and the order ID in the Payment Service was in the additional order parameters).

2. Fix in the response to the recurrentPayment recurring payment request: the response format has been aligned to fully match the order status getOrderStatusExtended (including changes in the orderId parameter).

3. Changed the card stored credential scenario using a special merchant.

Prior to version 1.7, card stored credential using the special Partner login occurred through order registration in the Payment Service and subsequent authorization (fund holding) or debiting. At the same time, the Payment Service AntiDDOS Router selected between holding or debiting based on the Partner’s settings.

Starting from version 1.7, full support for two-stage payment has been introduced. The merchant setting determining whether to hold or debit funds during stored credential has been removed. Now, when stored credential cards using a special merchant, the Partner must independently decide whether to perform holding or debiting. Depending on this, when registering an order for card stored credential, it is necessary to use either registerPreAuth or register.

Partners who are already using the card stored credential page combined with register and were set up for holding funds rather than debiting must update their integration and switch to using registerPreAuth.