Release 28.05.2026

Changelog

Orders and Payouts

New walletType parameter for wallet payments and payouts:

• A new optional walletType parameter has been added for operations with instrumentType = wallet. It selects how the wallet operation is processed by the provider when an acquirer supports several wallet flows (for example, a personal vs. corporate account).
• Supported values:
  • personal — the operation is processed as a transfer to a personal account.
  • company — the operation is processed as a transfer to a corporate account.
• The parameter is optional.
• Affected endpoints:
  • POST /order — Create Order — paymentSettings.walletType in the request body.
  • POST /payouts — Create Payout Request — walletType at the top level of the request body.
  • POST /payouts/fields — Retrieve Required Payout Fields — walletType inside the payoutSettings object of the request body.
  • GET /shops/{shopId}/payment-methods — Retrieve Payment Methods — walletTypes array in the response. The field is returned only when the payment method has at least one walletType configured.
  • GET /payouts/payout-methods/{shopId} — Retrieve Payout Methods — walletTypes array in the response. The field is returned only when the payment method has at least one walletType configured.
• For details, see Payment and Payout Methods — WalletType.

Orders

Clarified behavior for provider callbacks with a different payment amount or currency:

• The Order Status Model documentation now describes how the system handles callbacks where the provider returns a payment amount or currency that differs from the original order:
  • Amount changes can be accepted automatically within a per-shop allowed range configured by technical support. Outside the range, the order moves to need_action with status code 2-07-04.
  • Currency changes are never accepted automatically — the order always moves to need_action with status code 2-07-04.
• The system behavior itself is unchanged; this update only documents the existing logic.
• For details, see Order Status Model — Payment Amount and Currency Changes by the Provider.

Documented order processing timeout:

• The Order Status Model documentation now describes the processing timeout that moves a payment order to failed when no terminal response is received from the provider.
• The default timeout is 7 days from order creation. It can be increased per shop and payment setting by technical support for integrations where a longer wait is expected.
• The timeout applies to payment orders only and does not apply to payouts, P2P transactions, or crypto payments.
• The system behavior itself is unchanged; this update only documents the existing logic.
• For details, see Order Status Model — Order Processing Timeout.

New Retry allowed column in the Status Codes reference:

• The Status Codes reference now includes a Retry allowed column for each status code.