41 posts tagged with "release"

Changelog​

General​

• Update: Additional dataEntryModes options have been introduced, including instruction, iframe, and html, providing flexible methods for customer data entry in the Retrieve Payment Methods and Create Order endpoints.
• Update: Expanded transferType options for payouts, adding the following new methods:
  • sbp - Russian System for Fast Payments
  • open_finance - Open banking options
  • virtual_account - Virtual account payments
  • spei - Mexican interbank electronic payments (SPEI)
  • vietqr - Vietnamese QR code payments
  • paysafecard - Prepaid voucher service
  • multibanco - Portuguese bank transfer method
  • bancontact - Belgian payment method
  • blik - Polish mobile payment system
  • p24 - Przelewy24, a Polish online payment system
  • rapidtransfer - Rapid Transfer for bank payments
  • upi - India’s Unified Payments Interface
  • thb_qr - Thai QR payments
  • sberbank - Sberbank Online for Russian transfers
  • account2card - Direct bank-to-card transfer

Cryptocurrency​

Initial support for cryptocurrency transactions has begun, but implementation is still ongoing. Below are the changes introduced so far, with further updates planned for upcoming releases. All modifications are backward-compatible.

• Update: A new cryptoTokenStandard parameter has been added to the order object in the Create Order endpoint and to the payout in the Create Payout Request , required if the currency is set to a cryptocurrency. This allows specifying the blockchain standard for crypto payments, such as ERC20.
• Update: The amount and currency fields in order -> cost object were modified to support cryptocurrency transactions, including the addition of decimal precision requirements for crypto and the need to specify cryptoTokenStandard in the Create Order endpoint and in payout -> cost in the Create Payout Request .
• Update: The customer data container now allows customer details (firstName, lastName, middleName, phone, and email) from the order request to be automatically used on the payment page without re-entry, governed by the Use customer data as payer information setting. This behavior applies across all orders created using the Create Order endpoint.

Payouts​

• New fields: Added ipAddress, beneficiaryName, and beneficiarySurname to RecipientPersonalData for enhanced payer identification in the Create Payout Request endpoint.
• Update: Added RUT to RecipientDocuments to support Chilean taxpayer identification in the Create Payout Request endpoint.

Changelog​

General​

• New feature: A new status need_action has been added to the status model for both payments and payouts. This status indicates that further action is required to complete the transaction. More details can be found in the Order Actions and Conditions and Payout Scenarios sections.

Orders​

• New feature: A new provider object has been added to the payments array in the response of the Retrieve Order Details endpoint and the Order Status Callback, which includes the payment provider's code.

Payouts​

• New feature: A new status object has been added to the payoutTransactions array in both the Retrieve Payout Status and Payout Callback endpoints. This object contains:

  • status: The current state of the payout, with possible values: in_progress, completed, cancelled, failed, and the new need_action.
  • details: Nullable object providing additional error details if the payout fails, including:
    • errorId: Unique error identifier.
    • providerMessage: Error message from the payment provider.
    • code: Internal error code for categorizing the error.

• New feature: A new status object has been added to the payoutTransactions array in both the Retrieve Payout Status and Payout Callback endpoints to enhance payout status reporting. It includes the current state of the payout and detailed error information if the payout fails.

Changelog​

Payouts​

• Bug fix: The Callback Payout now adheres to the documentation correctly. Previously, the callback was not matching the described behavior in the docs.
• Bug fix: Resolved an issue where the Create Payout Request was returning an error for a valid request in some scenarios.

Orders​

• Update: The default cancellation time for orders has been reduced to 15 minutes. Refer to the timeLimit parameter in the Create Order endpoint for more details.

  • If no active transaction is initiated by the payer within the first 15 minutes, the order will be automatically cancelled with the status cancelled.
  • If a transaction is initiated within this window, the order will remain active for an additional week. However, if a final successful status is not received from the payment provider within this extended period, the order will be cancelled.

• Bug fix: Fixed an issue where customer details in a previous order were sometimes overwritten by updated data for the same customerId from a new order. Now, customer details always reflect the information provided at the time of the order's creation, even if they were changed in subsequent orders for the same customerId. This applies to both the Retrieve Order Details endpoint and the Callback.

Changelog​

Orders​

Enhancements​

• New Parameter: Added transactionId field to the payments object in both the Retrieve Order Details API response and the Order Status Callback. This new field allows merchants to track the unique identifier for each transaction associated with an order, improving traceability and reconciliation of payments.

Changelog​

Payouts​

Enhancements​

• Time-To-Live (TTL): For all payouts, a TTL of 1 week has been introduced, starting from the moment the payout is created. For more details, please refer to the Create Payout Request Documentation.

Changelog​

Orders​

Enhancements​

• New Feature: Introduced the ability to assign and use aliases for payment configurations. Merchants can now specify a paymentSettingsAlias in the order creation endpoint to control which payment configuration is used for processing the order. This feature is particularly useful for merchants who need to manage multiple configurations with the same provider. To learn more about configuring and using aliases, please refer to the Alias Documentation.

Payouts​

Enhancements​

• New Feature: Similar to the enhancements for orders, the alias feature has also been extended to payouts. Merchants can now specify a paymentSettingsAlias in the payout creation endpoint. This allows for precise control over which payment configuration is used for payouts. To learn more about configuring and using aliases, please refer to the Alias Documentation.

Bug Fixes​

Fix: Resolved an issue where payouts could not be created if the DataEntryMode was not specified during payout creation, when only one DataEntryMode was available for the payment method. Now, the DataEntryMode is only required when there are multiple DataEntryMode available in the Retrieve Payout Methods endpoint response. If only one DataEntryMode is provided, it will be automatically applied, and no manual input is necessary.

Changelog​

Payouts​

Enhancements​

• Update: The response structure of the Retrieve Payout Status endpoint has been expanded. This includes additional fields that provide more detailed information about the payout process. Backward compatibility with the previous response format has been maintained, ensuring existing integrations continue to function without disruption.

• Update: New values have been added to the transferType. The transferType can now include the following values:

  • virtual_account
  • khipu
  • giropay
  • eps
  • open_finance

Breaking Changes​

Changelog​

Orders​

Enhancements​

• Update: When customers pay through certain providers, they may enter an amount different from the original order amount specified by the merchant during order creation (order -> cost -> amount) or the provider might adjust the amount. In these cases, both the amount in the Retrieve Order Details endpoint and the callback for payment status will now reflect the actual amount paid or modified by the provider in data -> cost -> amount, rather than the initial amount specified by the merchant.

Bug Fixes​

• Fix: Corrected a naming issue in the order status callback where the rrn parameter (payments -> paymentDetails -> rrn) was incorrectly returned as rnn. The parameter is now correctly returned as rrn.
• Fix: Added a new paymentStatus object to the payments array in the Retrieve Order Details endpoint response and the order status callback. This object contains the payment status and additional error details in the details object if the payment status is failed.

Payouts​

Bug Fixes​

• Fix: Resolved an issue in the POST Retrieve Required Payout Fields endpoint where the value and label parameters in the options array were swapped. The values now correctly match the documentation:

  Before:

  "options": [
    {
      "value": "Checking account",
      "label": "C"
    }
  ]
  

  Now:

  "options": [
    {
      "value": "C",
      "label": "Checking account"
    }
  ]
  

Upcoming changes in the next release​

Payouts​

Enhancements​

• Update: In the upcoming release on August 27, the response structure of the Retrieve Payout Status endpoint will be expanded. Backward compatibility with the current response format will be maintained.

Here is the structure of the Retrieve Payout Status response and the Payout Callback structure that will be introduced in the August 27 release:

{
  "data": {
    "shopId": 123,
    "id": 54222,
    "payoutStatus": "in_progress",
    "payoutNumber": "56573FDFVFDBWF",
    "purpose": "string",
    "cost": {
      "amount": "56.99",
      "currency": "USD",
      "region": "RU"
    },
    "payoutCreatedAt": "2023-08-29T15:34:56+03:00",
    "payoutPaidAt": "2023-08-29T15:34:56+03:00",
    "payoutTransactions": [
      {
        "transactionId": "79",
        "providerTransactionId": "990943",
        "cost": {
          "amount": "56.99",
          "currency": "USD"
        },
        "provider": {
          "code": "fyst"
        },
        "acquirer": {
          "code": "fyst"
        },
        "instrumentType": "card"
      }
    ],
    "customer": {
      "customerId": "56656",
      "firstName": "John",
      "lastName": "Doe",
      "middleName": "James",
      "phone": "79221110500",
      "email": "john.doe@mymail.com"
    },
    "payoutDetails": {
      "recipient": {
        "paymentSystem": "visa", // returned only if instrumentType = card
        "maskedCardNumber": "123456******7890", // returned only if instrumentType = card
        "walletId": "34534534333", // returned only if instrumentType = wallet
        "accountNumber": "34543243243534333", // returned only if instrumentType = bank_transfer
        "transferType": "sbp" // returned only if instrumentType = bank_transfer
      },
      "sender": {
        "paymentSystem": "visa", // returned only if instrumentType = card
        "maskedCardNumber": "123456******7890", // returned only if instrumentType = card
        "walletId": "34534534333", // returned only if instrumentType = wallet
        "accountNumber": "34543243243534333" // returned only if instrumentType = bank_transfer
      }
    }
  }
}

Changelog​

Improvements​

• Feature: The webhook for order status and the order status endpoint now return the paymentDetails object within the payments array in the following format:

  • For cards (instrumentType=card):

    {
      "CardPaymentDetails": {
        "paymentSystem": "visa",
        "authCode": "auth94753457343",
        "rrn": "rrn583743856734",
        "maskedCardNumber": "123456******1234"
      }
    }
    

  • For bank transfers (instrumentType=bank_transfer):

    {
      "BankTransferPaymentDetails": {
        "transferType": "swift",
        "purpose": "Payment for invoice #12345",
        "accountNumber": "5103984571309587"
      }
    }
    

  • For wallets (instrumentType=wallet):

    {
      "WalletPaymentDetails": {
        "walletId": "aslk1351346"
      }
    }
    

• Enhancement: When creating an order, if the redirectUrls object in paymentSettings does not include values for success and failUrl, the default values will now be the shop URL that created the order.

Orders and Payouts​

Improvements​

• Feature: The administrative panel at Vertex Dashboard now includes the ability to manually resend callbacks for order/payout status. When sent, these callbacks will transmit the current status of the order/payout.

Changelog​

Orders​

Bug Fixes​

• Fix: Resolved an issue where, in some cases, the payment page was incorrectly generated when creating an order with "dataEntryMode": "redirect". This caused the user to be unable to redirect to the provider's page because the Pay button was not clickable.

• Fix: Resolved a bug where the Retrieve Order Details could accept payoutNumber as orderNumber. This endpoint now only accepts orderNumber. If payoutNumber is provided as orderNumber, an error will be returned:

  {
    "message": "Not found order number some_number in shop with id: some_shop_id",
    "code": 404
  }
  

Payouts​

Bug Fixes​

• Fix: Resolved an issue where the response from the Retrieve Required Payout Fields endpoint sometimes included an empty recipient property. The response now adheres to the documentation.
• Fix: Corrected a problem where creating a payout would fail due to missing mandatory fields. Payouts are now created correctly.

Changes expected in the next release​

• Feature: There will be an option for manual resending of the order/payout status callback. In the merchant account dashboard, within the order/payout details window, a button Send order status by API will be added. Clicking this button will resend the order or payout status callback. The callback will be sent to the addresses specified in the callback settings, and if webhookUrl was specified during the order/payout creation, both callbacks (settings and webhookUrl) will be sent.

• As we mentioned in the previous release note, the new payout endpoint Retrieve Required Payout Fields is currently available but is returning placeholder responses instead of actual data. We are working on finalizing this feature, and it will be fully functional and provide accurate data in the next release.