<td style={{ textAlign: "left" }}>
Merchants can now select an **Order Processing Channel** when creating or editing their profiles. This channel represents the **sales channel through which the shopper provides their card details** and will be used as the default value sent to the processor unless explicitly specified in the payment request.<ul>Available options:<li>**E-Commerce**</li><li>**MOTO (Mail Order / Telephone Order)**</li></ul> Currently, this feature is supported only for **Worldpay**, while for other processors, the **E-Commerce** value will always be used. For all merchants created before this release, the default value has been set to **E-Commerce**.\`
</td>
</tr>
Changes
Default Order Processing Channel Selection for Merchants
<td style={{ textAlign: "left" }}>
The **OrderProcessingChannel**parameter has been added to the structure of **Authorization** and **Sale** requests (Authorization and Capture in a single request). This parameter defines the **sales channel through which the shopper provides their card details** and allows merchants to specify it when initiating a transaction.<ul>Available options:<li>**ecommerce**</li><li>**moto**</li></ul>If not explicitly provided in the request, the default value set at the merchant level on the Revolv3 Portal will be used. Currently, this parameter is sent only to **Worldpay**, while for other processors, the default value remains **E-Commerce**.<ul>Updated end points:<li>[Authorize With Payment Method Details](/reference/post_api-payments-authorization)</li><li>[Authorize With Payment Method Id](/reference/post_api-payments-authorization-paymentmethodid)</li><li>[Sale With Payment Method Details](/reference/post_api-payments-sale)</li><li>[Sale With Payment Method Id](/reference/post_api-payments-sale-paymentmethodid)</li></ul>
</td>
</tr>
Changes
Order Processing Channel
Technical Enhancements
Changes
Description
Bug fixes
We've resolved several bugs to improve the stability and performance of the product.
<td style={{ textAlign: "left" }}>
Previously, during payment processing via Worldpay, we first requested a token and then executed the payment using the token. With this update, the Primary Account Number (PAN) is now directly utilized for the first transaction, streamlining the process and reducing latency for initial payments.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Configurable Retry Timing for Backup Processor Payments
</td>
<td style={{ textAlign: "left" }}>
We have introduced a feature that allows configuring the delay before the system retries a payment with the backup processor if the initial attempt with the primary processor fails. By default, the retry is immediate (0 minutes), but you can now set a delay of up to 60 minutes. This provides greater flexibility in managing transaction retries and optimizing payment workflows.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Enhanced Card Handling for Subscription Payments
</td>
<td style={{ textAlign: "left" }}>
Our system supports linking multiple cards to a subscription and sequentially attempting payments. If the payment with the first card fails, the system will try the second card, and so on.
With the new feature, you can configure whether the second and subsequent cards should be used on the same day as the initial attempt or only in the next recycle cycle. This added flexibility allows for better control over retry strategies and ensures alignment with business needs.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Introduction of Stateful Webhooks with Enhanced Features
</td>
<td style={{ textAlign: "left" }}>
We have transitioned from a stateless to a stateful webhook mechanism to align with industry best practices. This new implementation improves reliability, transparency, and efficiency when notifying external systems about events.
**Key Features:**
* \*Stateful Webhooks\*\*: Each webhook now includes the state of the entity at the moment of generation, ensuring accurate context for external systems.
* \*Retry Mechanism\*\*: Supports progressive retries in case of transient failures, enhancing delivery reliability.
* \*Preserved Order\*\*: Webhooks are processed sequentially for each merchant, preventing disorder and ensuring consistent event streams. Processing halts and resumes as issues are resolved.
* \*Custom Configuration\*\*: Merchants can now define specific webhook types they wish to receive, reducing system load and unnecessary notifications.
This update ensures a robust, scalable, and configurable webhook experience for merchants and their integrated systems.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Optimized EPX Transaction Processing
</td>
<td style={{ textAlign: "left" }}>
Transactions with EPX now process faster by using the PAN for the first payment when no token is available. Token retrieval happens in parallel, ensuring seamless processing for subsequent transactions.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Enhanced TSYS Transaction Processing
</td>
<td style={{ textAlign: "left" }}>
The transaction flow with TSYS has been improved to reduce delays. For the first payment method transaction without a token, the PAN is used directly, while token retrieval occurs in parallel to ensure smooth processing for future payments.
</td>
</tr>
Changes
Direct PAN Usage for Initial Transactions with Worldpay
Documentation Portal Updates
Changes
Description
Webhook Usage
We have revised the documentation on the portal to reflect the latest changes and best practices for using webhooks: Webhook Events.
Network Processing Types
We have revised and expanded the documentation on transaction processing to provide clearer guidance for various transaction types, including Initial Recurring, Recurring, and others: Network Processing Types.
Descriptor Guide
We have also updated the Descriptor Guide to include the latest recommendations and examples for customizing transaction descriptors: Descriptor Guide.
<td style={{ textAlign: "left" }}>
We have optimized the number of requests sent to payment processors by removing unnecessary calls. This improvement reduces the overall transaction volume and helps to minimize operational costs associated with processing fees.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Direct Integration with Nuvei for Network Transaction ID Support
</td>
<td style={{ textAlign: "left" }}>
To address the limitation in the Nuvei SDK, which currently does not support the network transaction ID required for linking recurring transactions into a unified stream, we have implemented a direct integration with Nuvei.
This new integration bypasses the SDK, allowing us to include the network transaction ID and ensure seamless handling of recurring transactions.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Bug fixes
</td>
<td style={{ textAlign: "left" }}>
We've resolved several bugs to improve the stability and performance of the product.
</td>
</tr>
<td style={{ textAlign: "left" }}>
A new mechanism has been implemented to allow merchants to securely retrieve data from our system. This secure data transfer is particularly beneficial when merchants transition to a different payment service or processor, ensuring that sensitive information is protected throughout the process.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Tokenization Retry
</td>
<td style={{ textAlign: "left" }}>
This feature introduces the ability to enable tokenization retry for merchants. Tokenization retry can be configured to automatically attempt tokenization again after a failure, ensuring higher success rates in capturing payment methods.
Additionally, tokenization retry is designed to work seamlessly with multiple payment methods, which were introduced in the 1.13.0 release.
</td>
</tr>
Changes
Secure Data Transfer for Payment Service Migration
<td style={{ textAlign: "left" }}>
ACH transactions are not processed in real-time. To ensure accurate transaction status in the system, it is essential to obtain data on any rejections. This functionality has been implemented to improve transaction status accuracy and system reliability.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Backup Processor Retry for Recurring Payments
</td>
<td style={{ textAlign: "left" }}>
The backup processor retry feature was enhanced to support recurring payments, in addition to one-time payments. When a payment attempt fails through the primary processor, the system will automatically retry the payment using a backup processor, provided the relevant setting is enabled. This enhancement ensures that both one-time and recurring payment transactions have a higher chance of success, reducing disruptions and improving the overall user experience.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Expanded Time Zone Support
</td>
<td style={{ textAlign: "left" }}>
Time zone support has been expanded from previously only accommodating US time zones to now including a full global list of time zones. This enhancement ensures that users from around the world can select and use their local time zones, improving the accuracy and relevance of time-based data and scheduling within the system. Additionally, the UI now displays the user's local time and supports Daylight Saving Time (DST), providing a more personalized and user-friendly experience. This feature aims to provide a more inclusive and flexible user experience for a global audience.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
TSYS Payment Processing via Payments API
</td>
<td style={{ textAlign: "left" }}>
Existing endpoints in the [Payments API](https://docs.revolv3.com/reference/payments_sale) now support processing payments through TSYS. This enhancement allows for seamless integration with TSYS, providing greater flexibility and more options for handling transactions.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Merchant Search
</td>
<td style={{ textAlign: "left" }}>
The dropdown menu for searching merchants has been enhanced with a new search functionality. Users can now quickly find and select merchants by typing keywords into the search field within the dropdown, streamlining the process of locating specific merchants.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Role Based Access Control (RBAC)
</td>
<td style={{ textAlign: "left" }}>
Role-Based Access Control (RBAC) has been implemented to enhance security and streamline user management within the system. This feature allows administrators to assign specific roles to users, each with defined permissions and access levels.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Multiple Payment Methods for Subscriptions
</td>
<td style={{ textAlign: "left" }}>
A new feature has been added that allows multiple payment methods to be associated with a single subscription. When creating a subscription, users can now add several payment methods, which will be used sequentially for processing payments. <br/><br/> If a payment fails with the primary card, the system will automatically attempt to process the payment with the next available card during the next billing cycle. The number of retry attempts for each payment method can be configured to meet specific needs. <br/><br/> In the event of a hard decline on a card, that card will be excluded from further payment attempts and will no longer be used. This feature is configurable and operates for merchants when enabled, providing increased flexibility and reliability in subscription management. It ensures that payments are more likely to be successfully processed, even if initial payment attempts fail.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Configurable Subscription Payment Recycle Scheduling
</td>
<td style={{ textAlign: "left" }}>
A new feature allows merchants to configure the payment recycle schedule for subscriptions by contacting support. Merchants can now request customized scheduling for retrying failed subscription payments, ensuring that payment attempts are aligned with their specific needs and preferences. <br/><br/> To set up or modify the payment recycle schedule, merchants can reach out to our support team, who will assist in configuring the desired retry intervals and frequency. This feature provides greater control over payment management and enhances the ability to handle subscription payments effectively.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Expanded Country Support for Merchant Configuration
</td>
<td style={{ textAlign: "left" }}>
Previously, merchant configuration was limited to a single country, the US. This release expands the available options to include all countries. Merchants can now configure their settings for any country.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Improved Network Token Retrieval Process
</td>
<td style={{ textAlign: "left" }}>
The process for obtaining network tokens has been enhanced to provide a more efficient and reliable experience. This improvement streamlines the steps involved in retrieving network tokens, reducing latency and increasing the accuracy of token generation.
</td>
</tr>
Changes
ACH Transaction Processing and Rejection Handling for **Nuvei** Processor
<td style={{ textAlign: "left" }}>
Several Avatax-related tax parameters were removed to streamline the invoicing process. The following parameters have been removed: <ul><li>**EntityUseCode** (Avalara tax exemption code) from the invoice and customer entities.</li><li> **TaxFinalizationStatus** from the invoice entity.</li> <li>**TaxCode** from the invoice line items. </li></ul>
</td>
</tr>
Changes
Removal of Avatax Tax Parameters
Documentation Portal Updates
Changes
Description
Checkout Line Items Value Types
The Checkout Guide has been updated to include detailed information about the Value Types of line items. This addition provides clear guidance on how to define and utilize different value types for line items during the checkout process.
Technical Enhancements
Changes
Description
International payments
The architecture has been prepared to support international payments, ensuring a seamless and reliable transaction experience for global users.
Framework update
The .NET framework has been updated to the newest version. This upgrade brings enhanced performance, improved security, and better support for modern development practices.
Bug fixes
We've resolved several bugs to improve the stability and performance of the product.
<td style={{ textAlign: "left" }}>
* [Create Checkout Link](https://docs.revolv3.com/reference/checkout_createcheckoutlink) Create a URL for a checkout page to accept payments.This URL can be seamlessly integrated into your payment flow, embedded into your payment page, or used to direct customers to a hosted payment page. The link will be deactivated once the customer opens the checkout page.
* [Get Complete Checkout Information](https://docs.revolv3.com/reference/checkout_getcompletecheckoutinformation) endpoint allows to retrieve complete checkout information, merchants can use our API to access detailed data about each transaction. This includes customer details, payment method information, transaction status, and any error messages if the payment fails.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Email is optional
</td>
<td style={{ textAlign: "left" }}>
The email associated with a billing address is now optional for processing transactions through Nuvei processor
</td>
</tr>
Changes
The new endpoints for the checkout are available
Documentation Portal Updates
Changes
Description
The new guide for the checkout are available
To assist merchants with the integration process, we have introduced the Checkout Guide . This comprehensive guide provides step-by-step instructions on how to integrate with either the hosted checkout page or the embedded payment page. It covers all aspects of the integration, from initial setup and configuration to customizing the payment form and handling responses.
Core Functionality Updates
Changes
Description
Checkout feature
The Checkout feature provides the ability to use our page with a form to collect payments. Merchants can embed Checkout directly into their websites or redirect customers to a Revolv3 hosted checkout page. This feature ensures a seamless payment experience by securely handling customer payment information, supporting various payment methods, and complying with PCI DSS standards.
<td style={{ textAlign: "left" }}>
The information about the credit card BIN number is now returned in the responses of the following endpoints:\
Invoices and PaymentMethod
</td>
</tr>
<td style={{ textAlign: "left" }}>
It is now allowed to Update the billing address associated with an existing payment method by supplying a billing address object. Previously, it was only possible to supply an existing billing address ID.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
Create Subscription response enhancements
</td>
<td style={{ textAlign: "left" }}>
The following enhancements were made to the [Create Subscription](https://docs.revolv3.com/reference/subscriptions_createsubscription) endpoint response to provide more information and make the result of the call more transparent:
A “**message**” parameter was introduced to return information about the first payment transaction result.
The **subscription object** will always be returned in the response (previously, it was not returned in the case of the first payment transaction failure).
</td>
</tr>
<td style={{ textAlign: "left" }}>
Newly implemented endpoints will allow merchants to send additional optional parameters that will identify whether a payment is one-time, recurring, or an installment (initial or subsequent). This will enable linking transactions at a processor/card scheme level. The following transaction types are introduced:
* \*Note**: Currently, linking transactions on a processor/card scheme level is implemented for**Adyen **and**Worldpay \*\*processors.
</td>
</tr>
<tr>
<td style={{ textAlign: "left" }}>
One-time payment without subscription
</td>
<td style={{ textAlign: "left" }}>
The specification of One-time payment without a subscription was updated with detailed information about parameter validations that will make integration processes smoother
</td>
</tr>
Changes
New Payments API end points
Core functionality updates
Changes
Description
Proportion routing rule enhancements
Transactions will be routed more effectively to distribute transaction volume between processors in line with the merchant's desired proportion rule.