51 posts tagged with "release"

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.

Changelog​

Crypto​

Renamed cryptocurrency asset_code values:

• The following asset_code values have been renamed to use blockchain-based suffixes instead of token standard suffixes. If you use the asset_code format in cost.currency, update your integration to the new values:
  • USDC_ERC20 → USDC_ETH
  • USDT_TRC20 → USDT_TRX
  • USDT_ERC20 → USDT_ETH
  • USDT_BEP20 → USDT_BSC
  • USDT_SPL → USDT_SOL
  • MATIC_ERC20 → MATIC_ETH
  • USDC_TRC20 → USDC_TRX
• Affected endpoints and callbacks:
  • POST /order — Create Order
  • POST /payouts — Create Payout Request
  • GET /order/{shopId}/{orderNumber} — Retrieve Order Details
  • GET /payouts/{shopId}/{payoutNumber} — Retrieve Payout Status
  • Order Status Callback
  • Payout Status Callback
• For the full list of supported cryptocurrencies and their formats, see the Cryptocurrency Reference Guide.

Orders​

Automatic finalization from need_action on payment amount mismatch:

• Orders moved to need_action with status code 2-07-04 due to a provider callback with a different payment amount can now be resolved automatically when a follow-up callback arrives with the correct amount.
• Automatic resolution requires the Automatic finalization of orders in the "Need action" status setting to be enabled for the shop. Otherwise, the order remains in need_action and must be resolved manually.
• For details, see Order Status Model — Need Action.

Orders, Payouts, and P2P​

New statusCode and statusDescription fields in responses and callbacks:

• Each response and callback payload now includes two new optional fields at the top level of the data object:
  • statusCode — status code that provides additional context for the current order, payout, or P2P status.
  • statusDescription — human-readable description corresponding to statusCode.
• Affected endpoints and callbacks:
  • Retrieve Order Details — GET /api/v1/order/{shopId}/{orderNumber}
  • Retrieve Payout Status — GET /api/v1/payouts/{shopId}/{payoutNumber}
  • Retrieve P2P Transaction Status — GET /api/v1/p2p/{shopId}/{p2pNumber}
  • Order Status Callback
  • Payout Status Callback
  • P2P Status Callback
• For the full list of status codes and their meaning, see the Status Codes reference.

Changelog​

Orders​

Added middleName to payer personal data:

• Added payer.personalData.middleName to the Create Order request.

Changelog​

Orders​

Cryptocurrency Payment Structure Unification (Breaking):

The cryptocurrency payment parameters in the Create Order request have been restructured for clarity and to group merchant-side data under a dedicated recipient object. See the updated Cryptocurrency Reference Guide for full details.

• Removed the cryptoPayment object. Its fields have been moved and renamed as described below.
• Added order.cost.tokenStandard — the token standard of the customer's wallet cryptocurrency (for example, TRC20, ERC20, BEP20). Replaces the former cryptoPayment.walletTokenStandard. Optional. Should be provided for token-based cryptocurrencies when using crypto_currency_code in order.cost.currency; not needed for native cryptocurrencies or when using asset_code format.
• Added recipient object with the nested merchantBalance object, which declares the currency of the merchant's balance. The merchant balance currency may be fiat or crypto and is independent from order.cost.currency (the currency the customer pays in).
  • recipient.merchantBalance.currency — the merchant balance currency code (replaces the former cryptoPayment.accountCurrency.currency). Required when the merchantBalance object is provided.
  • recipient.merchantBalance.tokenStandard — the token standard of the merchant balance currency (replaces the former cryptoPayment.accountCurrency.networkTokenStandard). Optional. Should be provided when merchantBalance.currency is a token-based cryptocurrency; ignored for fiat currencies.

Migration example:

Before:

{
  "order": {
    "cost": {
      "amount": "20",
      "currency": "USDT"
    }
  },
  "cryptoPayment": {
    "walletTokenStandard": "TRC20",
    "accountCurrency": {
      "currency": "USDC",
      "networkTokenStandard": "TRC20"
    }
  }
}

After:

{
  "order": {
    "cost": {
      "amount": "20",
      "currency": "USDT",
      "tokenStandard": "TRC20"
    }
  },
  "recipient": {
    "merchantBalance": {
      "currency": "USDC",
      "tokenStandard": "TRC20"
    }
  }
}

E-wallet Payer Data Support:

• Added walletData object to the payer field in the Create Order endpoint.
• Use this object to pass the payer's e-wallet details for providers that accept payments via digital wallets.
• Available fields (all optional): walletId, walletType, walletName, walletHolderName.

Added tokenStandard to cost for partial operations:

The tokenStandard field has been added to the cost object in the following endpoints, mirroring order.cost.tokenStandard for consistency across the order lifecycle:

• POST /order/capture — cost.tokenStandard
• POST /order/refund — cost.tokenStandard

P2P​

Added tokenStandard to cost:

• Added p2p.cost.tokenStandard to the Create P2P Transaction request. Optional.
• Should be provided for token-based cryptocurrencies when using crypto_currency_code in p2p.cost.currency; not needed for native cryptocurrencies or when using asset_code format.

Payouts​

Added tokenStandard to payout.cost:

• Added payout.cost.tokenStandard to the Create Payout Request endpoint. Optional. Should be provided for token-based cryptocurrencies when using crypto_currency_code in payout.cost.currency; not needed for native cryptocurrencies or when using asset_code format.
• The existing payout.cryptoTokenStandard field is unchanged.

Changelog​

Payment Methods​

New Instrument Type mobile_top_up:

• Added mobile_top_up to the list of supported values for instrumentType. This instrument type represents payments made by topping up a mobile phone number. See Payment and Payout Methods for details.
• Affected endpoints:
  • POST /order
  • GET /order/{shopId}/{orderNumber}
  • GET /shops/{shopId}/payment-methods
  • POST /payouts
  • GET /payouts/{shopId}/{payoutNumber}
  • GET /payouts/payout-methods/{shopId}
  • POST /payouts/fields

New Card Brands humo and uzcard:

• Added humo and uzcard to the list of supported card brands.
• Affected fields and endpoints:
  • paymentSystem in GET /order/{shopId}/{orderNumber} payment details
  • paymentSystem in GET /payouts/{shopId}/{payoutNumber} payout details

Changelog​

Orders​

Removed deprecated redirect entry mode:

• The redirect value was deprecated and has been removed from the entryMode enum.
• Affected endpoints:
  • POST /order
  • GET /order/{shopId}/{orderNumber}
  • GET /shops/{shopId}/payment-methods

Changelog​

Orders​

Bank Transfer Payer Data Support:

• Added bankTransferData object to the payer field in the Create Order endpoint.
• When creating an order with instrumentType = bank_transfer, merchants can now pass the payer's bank transfer details (such as bankCode, accountName, accountNumber, etc.) in payer.bankTransferData.
• This allows providing bank-related information for the payer upfront, reducing the need for manual entry on the payment page.
• Requires the company setting "Use customer data as payer information" to be enabled. This setting can be found in the Dashboard under Settings -> Company tab.

Need Action automatic resolution:

• Orders in need_action status caused by a provider response timeout can now be resolved automatically. If the provider's response is eventually received.
• See Order Status Model — Resolution.

Changelog​

Orders​

• Deprecated endpoint: POST /api/v1/order/reject is now deprecated. Use POST /api/v1/order/cancel instead. The reject endpoint will be removed in a future release.

Documentation Updates​

New Page: Customer and Payer Data​

Added a new documentation page — Customer and Payer Data — covering:

• How the system identifies customers (customerId → email + phone → new record)
• Merge rules when "Use customer data as payer information" is enabled for payments and payouts
• Payment and payout flow diagrams showing the data resolution logic
• Payment retry behavior for payer data

Changelog​

Deprecations​

• Order Status: The rejected order status has been removed.

API Updates - Orders and Payouts​

Shop Hosted Integration (DeepLink Support):

• Added deepLink property to the operationReference object in Order Retrieve Order Details, Payout Retrieve Payout Status responses and webhooks Order Callback and Payout Callback.
• This new field provides a URL for redirecting customers to mobile applications (e.g., banking apps) to complete payments or payouts, improving the user experience for instruction-based integrations.
• Updated H2H Integration for Instructions guide to include deepLink details and examples

Changelog​

Payment Methods​

Samsung Pay Support:

• Added samsung_pay to the list of supported values for entryMode in the Create Order and Retrieve Payment Methods endpoints.

Webhooks​

• Previously, the system sent a webhook with status failed when an order was not created because the Create Order endpoint returned a synchronous error (e.g., 412 Precondition Failed).
• Change: The system no longer sends a callback notification in these scenarios. If the order creation returns an error synchronously, no asynchronous webhook will be triggered.