Changelog​

Callbacks​

Signature Verification Logic Update:

We have updated the requirements for generating the control signature to support Unicode characters in callback payloads (e.g., in customer names).

When generating the signature on your side to compare with api-notification-sign, ensure that your JSON encoding preserves Unicode characters and does not escape slashes. For updated examples, please refer to the Configuring Callback documentation.

PHP: Add JSON_UNESCAPED_UNICODE to your json_encode flags.

$message = json_encode($phpInput, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE);

Python: Use ensure_ascii=False in json.dumps.

message = json.dumps(data, separators=(',', ':'), ensure_ascii=False)

Backward Compatibility:

We recommend applying this update to all integrations. It ensures correct signature verification for Unicode data and is fully backward compatible for ASCII-only payloads.

Changelog​

Crypto Wallets​

Removed Endpoints:

• The following CryptoWallet endpoints have been removed from the API:
  • POST /customers/crypto-wallet — Create Crypto Wallet for a Customer
  • GET /customers/{customerId}/crypto-wallet — Retrieve Customer's Crypto Wallets

Orders​

Customer and Payer Data Handling:

• Updated priority rules when both customer and payer objects are provided in the Create Order request. This behavior applies only when the company setting "Use customer data as payer information" is enabled:
  • Data from customer and payer objects will be merged
  • Fields from the payer object take priority over corresponding fields from customer
  • Missing fields in payer will be supplemented from customer data

Cryptocurrency Payments:

• Customer identification is now required for cryptocurrency payments (instrumentType: crypto_wallet). You must provide at least one of the following fields in the customer object:
  • customerId — to use an existing customer
  • email — to identify or create customer by email
  • phone — to identify or create customer by phone

Shop Hosted Integration:

• When using dataEntryMode: instruction with paymentPageDesign.format: shop_hosted, the payer object with required fields must be provided in the request. If payer data is insufficient, a validation error will be returned.
• Instruction parameters are returned in the operationReference object via webhook and Retrieve Order Details response.

Documentation Updates​

Shop Hosted Integration​

The operationReference object structure in the H2H Integration for Instructions documentation has been updated.

Updated Structure:

{
  "operationReference": {
    "parameters": [
      {
        "label": "Reference",
        "value": "KT53386"
      },
      {
        "label": "Amount",
        "value": "10.00"
      },
      {
        "label": "Entity",
        "value": "db76f9cc-fbb0-4394-ac81-7b4fcfd6b2be"
      }
    ]
  }
}

Key Changes:

• type and metadata fields replaced with parameters array
• Parameter items now use label and value fields (previously id, type, value)
• The operationReference object has been moved to the payments array for orders and to the payoutTransactions array for payouts

See the Retrieve Order Details endpoint, Callback, Retrieve Payout Status endpoint, and Callback Payout documentation for the complete schema definition.

Antifraud Manual Review - reviewTimeout Field Correction​

The reviewTimeout field unit has been corrected from hours to minutes. The field accepts values from 1 to 1440 minutes (24 hours).

See the Antifraud Manual Review guide, Retrieve Order Details endpoint, and Retrieve Payout Details endpoint documentation.

Standardized Error Responses​

All API endpoints now include standardized error response codes documentation:

Changelog​

Antifraud​

Manual Review Action for Antifraud Rules​

Antifraud rules now support a new review action that allows merchants to pause transactions for manual review before they are processed by the payment provider.

New Review Action:

• When configuring antifraud rules, you can now select the review action alongside existing actions (decline, alert, 3DS)
• The review action pauses the transaction and sets both order and payment status to review
• A configurable timeout period determines how long you have to make a decision
• The system sends a callback notification with the new reviewTimeout field indicating the decision deadline

New API Endpoint:

• Submit Antifraud Review Decision - POST /api/v1/order/review/result
• Use this endpoint to submit your decision (accept or decline) for transactions in review status
• Works for both orders (payments) and payouts

Updated Schemas:

• The Retrieve Order Details endpoint and Order Status Callback now include:
  • New review status in orderStatus enum
  • New optional reviewTimeout field indicating timelimit available for decision
• The Retrieve Payout Details endpoint and Payout Status Callback similarly include the review status and reviewTimeout field

For complete implementation details, see Antifraud Manual Review.

Orders and Payouts​

New payer Object in Payment Attempts​

In the Retrieve Order Details endpoint and the Order Status Callback, each payment attempt in the payments array now includes an optional payer object with the following structure:

• personalData: Personal information including id, firstName, lastName, middleName, phone, email, birthDate, and ipAddress
• addressData: Complete address information including type, zipCode, country, state, city, and address
• documentData: Identity document details including type, series, number, issueCountry, and validBefore

All fields within these objects are optional.

New recipient Object in Payout Transactions​

In the Retrieve Payout Status endpoint and the Payout Status Callback, each payout transaction in the payoutTransactions array now includes an optional recipient object with the same structure as the payer object described above.

Use Cases​

This enriched data enables merchants to:

• Antifraud Review: Make informed decisions on transactions flagged by antifraud systems with complete payer/recipient context

Changelog​

Customer Data in Payout Field Retrieval:

The Retrieve Required Payout Fields endpoint now accepts a new optional customer field in the request body. Allows passing customer information for more accurate payout field determination

Documentation​

New Integration Guides:

• H2H Integration for Instructions): Guide for implementing shop-hosted integration with instruction-based payment methods. This integration enables merchants to receive payment instruction parameters directly via host-to-host (H2H) communication without redirecting to a payment page.

• Payout via Payment Page: New documentation for creating payouts with minimal required fields and collecting additional recipient information through a payment page.

Orders​

Shop Hosted Integration - payer.cardData Field Update:

In the Create Order endpoint, the payer.cardData field is now optional and nullable. This provides more flexibility when implementing shop-hosted integration for instruction-based payment methods that do not require card data

Payment Instruction Parameters - operationReference Field:

The Retrieve Order Details and Callback endpoint now returns a new optional operationReference object array. Note: This is a preliminary object structure. The field structure and naming may change in future updates. See the H2H Integration for Instructions) documentation for implementation details.

Payouts​

Payout via Payment Page Support:

The Create Payout Request endpoint now returns a new optional payoutLink field in the 201 response:

• Contains the payment page URL when additional recipient information is required
• Only present when recipient details are incomplete
• Enables recipients to securely complete their payout information on a hosted page
• See the Payout via Payment Page documentation for integration details

Changelog​

Enhanced Order Details​

The Retrieve Order Details endpoint:

Response data.payments[] array items:

• New fields:
  • entryMode (payment entry mode)
  • parentId (reference to parent payment)
• Updated fields:
  • paymentDetails.paymentSystem: new enum value verve

Cryptocurrency Wallet Improvements​

The Create Crypto Wallet endpoint:

Request Body:

• accountCurrency.networkTokenStandart → accountCurrency.networkTokenStandard (typo fixed)

Payout API Updates​

Response data.payoutDetails object:

• recipient.paymentSystem: new enum value verve
• sender.paymentSystem: new enum value verve

Customer Identification Updates​

customerId: Merchants can optionally provide their own customer identifier across multiple endpoints Create Order and Create Payout Request . If not provided, the system will not auto-generate this value.

The Retrieve Payout Status endpoint:

Response data object:

• customer.customerId: removed from required fields, now nullable

The Retrieve Order Details endpoint:

Response data object:

• customer.customerId: removed from required fields, now nullable

Changelog​

Payout​

The Create Payout Request endpoint has been changed:

• The acquirerCode, instrumentType, and providerCode fields are no longer required. All three fields are now nullable.

Payment Settings Alias Support​

Payment settings alias functionality has been expanded across multiple endpoints:

• Retrieve Payment Methods: Response may now includes paymentSettingsAlias field for each payment method.
• Retrieve Payout Methods: Response may now includes paymentSettingsAlias field for each payout method.

This enhancement allows merchants to identify and use specific payment configuration aliases when creating orders or payouts.

Documentation Enhancements​

The Cryptocurrency Reference Guide has been expanded with a comprehensive new section on cryptocurrency payouts:

• Cryptocurrency Payouts: Complete guide on using the POST /api/v1/payouts endpoint for cryptocurrency withdrawals, including:
  • Two methods for specifying cryptocurrency (crypto_currency_code with cryptoTokenStandard, or asset_code format)
  • Detailed examples for both native cryptocurrencies (BTC, ETH) and token-based cryptocurrencies (USDT, USDC)
  • Provider-specific sourceCurrency parameter usage for cross-network conversions and currency denomination specification

Changelog​

Enhanced Customer Management​

The Create New Customer and Retrieve Customer Information endpoints have been expanded with additional customer profile fields:

• affiliatedId: An optional identifier for customer. This field allows merchants to pass arbitrary values that will be stored in the customer record.
• billingAddress: Complete billing address information for customer profiles.
• birthDate: Customer's date of birth in ISO 8601 format (YYYY-MM-DD).

Cryptocurrency Payment Enhancements​

The Create Order endpoint now includes cryptocurrency payment support through the new cryptoPayment object:

• walletTokenStandard: Specifies the token standard for the customer's wallet cryptocurrency (e.g., TRC20, ERC-20, BEP-20). Required for token-based cryptocurrencies but not for native cryptocurrencies like BTC or ETH.
• accountCurrency: Configures the merchant account currency for cryptocurrency payments, including both the currency and its network token standard when applicable.
• The cryptoTokenStandard field has been removed from the order creation request, with this functionality now handled through the dedicated cryptoPayment object.

The Create Crypto Wallet endpoint has been updated:

• The tokenStandard field has been renamed to networkTokenStandart within the accountCurrency object for consistency.
• The accountCurrency field is now nullable.

Expanded Payment Method Support​

New transfer types are now available across multiple endpoints for enhanced regional payment coverage:

• rapipago: Support for Rapipago payment method in Argentina.
• pse: Support for PSE (Pagos Seguros en Línea) in Colombia.

These new transfer types have been added to:

• Create Order
• Retrieve Order Details
• Retrieve Payment Methods
• Retrieve Payout Methods
• Retrieve Required Payout Fields
• Create Payout Request
• Retrieve Payout Status

New payment entry modes for digital wallets:

• apple_pay: Apple Pay integration.
• google_pay: Google Pay integration.

Recurring Payments Configuration​

The Create Order endpoint's recurringPayments object has been refined:

• billingIntervalQuantity and intervalType are now required fields when setting up recurring subscriptions.
• The paymentCount field is now nullable, allowing for indefinite subscriptions.

Payout Enhancements​

The Create Payout Request endpoint has been updated with improved data organization:

• Removed the paymentData field from both recipient and sender objects.
• Added bankAccountUserId to the bankTransferData object for enhanced bank account identification.
• Introduced payoutChannel field in the payoutData object to specify the channel used for payouts.
• Personal data now includes an optional id field.

The Retrieve Required Payout Fields endpoint response has been streamlined:

• Removed paymentData from the available categories.

Changelog​

Modified Endpoints​

Payouts​

Retrieve required payout fields

• The request‑body property payoutSettings.shopId is now required (previously nullable).

Recurring Payments Management​

New endpoints for managing recurring payment profiles and retry configurations:

• Cancel Recurring Payment: Cancels an active recurring payment profile.
• Create Retry Settings: Configure retry behavior for failed recurring charges.
• Retrieve Retry Settings: Get current retry configuration.
• Update Retry Settings: Modify existing retry settings.
• Delete Retry Settings: Remove shop-specific retry settings.
• Retrieve Recurring Payment Profile endpoint has been significantly enhanced.

Saved Cards​

The legacy binded cards endpoints have been removed in favor of the new saved cards functionality.

• Retrieve Saved Cards: Retrieves saved card details for a specific customer.

Modified Endpoints​

Orders​

Create order

• paymentSettings.instrumentType now accepts the new enum value cash.
• For bank‑transfer payments, paymentSettings.transferType now supports the new enum value codi.

Retrieve order details

• payments[].instrumentType now accepts cash.
• payments[].paymentDetails now includes a new schema for cash payments.
• For bank‑transfer payments, payments[].transferType now supports codi.

Retrieve payment methods

• Query parameter instrumentTypes now supports cash.
• Response properties instrumentType, transferType, and transferTypes[] now include cash and codi.

Payouts​

Create payout request

• The request‑body property instrumentType now accepts cash.

Retrieve required payout fields

• instrumentType now accepts cash.
• payoutSettings.transferType now accepts codi.

Retrieve payout methods

• Query parameter instrumentTypes now supports cash.
• Query parameter transferTypes now supports codi.
• Response properties instrumentType, transferType, and transferTypes[] now include cash and codi.

Retrieve payout status

• payoutDetails.recipient.transferType now supports codi.
• payoutTransactions[].instrumentType now supports cash.