Releases 07.07 – 29.09.2026

Release 29.09.2026

Orders, Payouts, and P2P

Removed statusReason from status responses and callbacks (Breaking):

• The statusReason field is no longer returned. It could contain internal system messages that did not reflect the actual reason for the status; use the statusCode and statusDescription fields instead — see the Status Codes reference.
• Affected endpoints:
  • GET /order/{shopId}/{orderNumber} — Retrieve Order Details — and the Order Status Callback.
  • GET /payouts/{shopId}/{payoutNumber} — Retrieve Payout Status — and the Payout Status Callback.
  • GET /p2p/{shopId}/{p2pNumber} — Retrieve P2P Transaction Status — and the P2P Status Callback.
• If your integration parses statusReason, remove the dependency on this field.

Status Codes reference synchronized with the production directory:

• The Status Codes reference now includes the provider codes introduced by payment integrations over the past months: 2-01-04, 2-02-23 – 2-02-42, the Payment Method Definition group (2-03-XX), 2-04-05, 2-05-10 – 2-05-28, 2-06-03/2-06-04, 2-07-14 – 2-07-21, 2-08-03/2-08-04, the Wallet Errors group (2-10-XX), and the Payout Processing group (2-11-XX), as well as the system code 1-07-28.
• The system behavior itself is unchanged; this update only documents the codes already returned in responses and callbacks.

Underscores allowed in order, payout, and p2p numbers:

• The orderNumber, payoutNumber, and p2pNumber fields now accept the underscore character (_) in addition to Latin letters, numbers, and hyphens. The validation is applied consistently in the Create Order, Create Payout Request, and Create P2P Transaction endpoints.

Release 15.09.2026

Orders

Payment settings alias in order details and callbacks:

• Each item of the payments array now contains the optional paymentSettingsAlias field — the alias of the payment configuration that processed the payment attempt. Use it to identify which configuration was used when several configurations differ only by alias.
• The field is returned only for configurations that have an alias.
• Affected endpoints:
  • GET /order/{shopId}/{orderNumber} — Retrieve Order Details.
  • Order Status Callback.
  • For payouts, the same field is returned in the payoutTransactions array items of Retrieve Payout Status and the Payout Status Callback.
• For details, see Alias Setup and Usage Guide.

Release 01.09.2026

Orders and Payouts

Provider fee in status responses and callbacks:

• A new optional providerFee field has been added to the payments array items (Retrieve Order Details, Order Status Callback) and to the payoutTransactions array items (Retrieve Payout Status, Payout Status Callback).
• The field contains the fee charged by the payment provider for the transaction (amount and currency) and is null when the provider did not report it.

Provider payment name for payout transactions:

• The providerPaymentName field (the name of the final payment provider that processed the transaction) is now also returned in the payoutTransactions array items of the payout status response and callback — previously it was available only for order payments.

Removed isDefault from the payment and payout methods responses:

• The isDefault field is no longer returned in the Retrieve Payment Methods and Retrieve Payout Methods responses.
• The default-method mechanics it referred to is no longer used: when the request does not identify a single payment method, the selection follows the shop's First attempt settings — see Payment Flow.

New walletType value company_extra:

• The walletType parameter now supports a third value, company_extra, used when a provider exposes more than one corporate processing flow for the same wallet. The value is accepted in Create Order, Create Payout Request, and Retrieve Required Payout Fields, and is returned in the walletTypes arrays of the payment/payout methods endpoints.
• For details, see Payment and Payout Methods — WalletType.

Orders

Decline notice on the retry form of the payment page:

• When a payment attempt fails and a new attempt requires the payer to enter additional data (for example, after a cascading retry to a method with different custom fields), the payment page now shows the data entry form together with a notice that the previous attempt was declined.
• For details, see Payment Flow — Automatic retries: cascading.

Release 04.08.2026

Orders

Renamed status code 1-01-07 and automatic assignment of system status codes:

• The description of status code 1-01-07 has been changed from Provider circuit breaker open to Payment gateway is temporarily unavailable.
• The system now automatically assigns codes 1-01-02, 1-01-06, and 1-01-07 in the transaction details instead of the generic 2-01-01 (General decline) when a payment fails on the system side — for example, when the provider did not respond within the timeout window.
• See the updated Status Codes reference.

Manual retries reuse the payment method of the failed attempt:

• When cascading is disabled and payment attempts remain, the payer can retry the payment with the Try Again button. The retry reuses the payment method determined for the previous attempt.
• A retry is offered only if the status code of the failed attempt allows it (see the Retry allowed column in the Status Codes reference); otherwise the order fails immediately with 1-07-26.
• Custom field values entered by the payer are reused for the retry where possible; sensitive data such as card details, wallet and bank account requisites is requested again.
• For details, see Payment Flow — Manual retries.

Payment page timer is reset on retries:

• When a new payment attempt is created for an order (a manual retry or a cascading retry), the payment page timeout is reset to 15 minutes from the start of that attempt — this applies even when timeLimit was specified in the Create Order request.

Release 21.07.2026

Orders and Payouts

Expanded Status Codes reference:

• The status code directory has been extended with new codes:
  • System codes 1-01-06 (DNS resolution failed) and 1-01-07.
  • General provider code 2-01-03 (payment amount does not match the required amount multiple).
  • Provider request validation codes 2-02-09 and 2-02-11 – 2-02-22 (invalid parameter format, merchant/terminal not found, IP not whitelisted, amount below/above limit, and others).
  • Provider 3DS codes 2-04-03 (3DS failed) and 2-04-04 (3DS authentication cancelled or abandoned).
  • Antifraud code 2-05-09 (Security violation) and limits code 2-06-02 (Merchant processing limit reached).
  • Payment processing codes 2-07-05 – 2-07-13.
  • A new Card Processing group 2-09-XX with detailed card decline reasons (invalid card number, expired card, unsupported BIN, issuer limits, and others).
• The description of code 2-02-06 has been fixed to Duplicate request.
• See the updated Status Codes reference for the full list with the Retry allowed flags.

Orders

Clarified behavior of the Use request parameters only mode:

• When the first attempt mode is Use request parameters only and the selected payment method requires fields that were not passed in the request, the data is not collected on the payment page — the payment fails with status code 1-07-01 (Missing required parameters for the selected payment method).
• For details, see Payment Flow — Use request parameters only.

Payouts

Unified bank directory:

• For payout methods that require selecting a bank, a unified bank directory can be enabled for your company: Retrieve Required Payout Fields then returns the platform's unified bank codes instead of provider-specific ones, so the same banks have the same codes regardless of the provider. The same codes are used for bank selection on the payment page in purchases.
• The platform maps the unified code to the provider's own code when sending the request, and the selected bank is reused on cascading retries through another provider.
• The feature is enabled per company on request and covers the providers for which the mapping has been configured; otherwise the provider's own codes are used as before.
• For details, see Payouts — Unified Bank Directory.

Release 07.07.2026

Payouts

New paymentPageDesign.alias parameter in payout creation:

• The Create Payout Request endpoint now accepts an optional paymentPageDesign object with an alias field, the same way as the Create Order endpoint.
• Use it when the payout data is collected on the payment page and several page designs are configured for your shop: the alias selects which design is applied. The alias values are set through technical support.