Release Notes

• Payment method Campaign with type FloatingDueDate now available. FloatingDueDat' campaign also includes paymentTerm as number of days. For example, if paymentTerm is 30 then payment is due within 30 days from dispatch.
• Authorize and Available now have a limit for the OrderItem object. Up to 200 items per call are possible, otherwise, an error 400.008 "Array size exceeds the maximum allowed." will be returned.

• Message publisher performance improved.
• identificationNumber validation improved.

• Hosted Fields: Fields are now styled based on the configuration of the merchant.
• Hosted Fields: Placeholder configuration added in the format field-languageCode-country.
• Hosted Fields: Default validation for input based on field and profile has been added.
• Hosted Fields: Now fetching the Bank Name and BIC when IBAN is provided. BIC, Bank Name and masked IBAN are provided back to the merchant in the onChange event.
• Hosted Fields: Support for loading Google Fonts is added. Fonts can be specified by adding the font-family names into config input "googleFonts".

• Hosted Fields: Front-end optimization and better accessibility - title and keyboard support.
• Hosted Fields: The base address is now controlled by Riverty. Former configuration is ignored to keep control over changes in hosting infrastructure.
• Hosted Fields: Formatting improvements for social security number.

• Extended API monitoring with new risk provider health-checks.

• Search Order endpoint now responds with an empty result set in case an order was not found instead of a business error "Customer Not Found".
• Improved IBAN validator logic for ValidateBankAccount endpoint.

• Idempotency key handling was improved.

• Refined customer lookup response filtering.

• Remaining authorized amount was added to the Void response.
• Extended Authorize response to include risk provider information based on client setting.
• Extended customer-facing messages in French.
• DACH region risk provider request was extended with ExternalClientID.
• Added DirectDebit tokenization support in Authorize call.
• Added Hosted Fields support in ValidateBankAccount call.
• Monitoring parameters were extended to provide risk steering data.
• New translations for customer-facing messages were added.

• Fixed an issue where duplicate reservations with the same checkoutID were generated.
• CustomerCardClassification is now forwarded to the DACH risk provider.

• GetOrderResponse now includes the Payment object.
• PaymentMethod object in AvailablePaymentMethods response now contains the consumerFeeAmount field. This is relevant to display dynamic consumer invoice fee.
• It is now possible to split the Tolerance Amount in case of partial capture calls.
• The Tolerance Amount is a merchant-specific Core setting that allows a merchant to Capture an amount higher than Authorized. (Contact your Key Account Manager to learn more.)
• With this release, the total Tolerance Amount for an order can be used up in parts between multiple Partial Captures.

• Improved risk steering for DACH region.

• googleAnalyticsClientId and googleAnalyticsUserId during Capture call added to the invoice.
• The ApplyForCredit call now returns correct ResponseMessage if customerNumber exceeds the maximum length.
• Now it is not allowed to send Authorize request with already used checkoutId.
• Fixed an issue with the Refund creation date.

• Billing customer validation has been changed based on the new client setting.
• New process now available for retrieving customer identifiable information from Hosted Fields.
• AutoCapture functionality added based on new client setting.
• Customer lookup is now working in Sandbox Environment.

• Improved mobilePhone and phone validation.

• Fixed a bug where Capture request parameters were discarded when orderDetails or orderDetails.TotalGrossAmount are missing.

• Negative authorization handling now works correctly.

• Successful address validations from our DACH risk engines were erroneously processed as False.

• The following responses now contain ExpiryDate:
• AuthorizePaymentResponse
• GetOrderResponse

- UpdateOrderResponse

• This is the expiry date of the order's Reservation in the Riverty backend. Captures after this date will be rejected.

• The response to GetCapture no longer includes Riverty's internal Invoice ID. (This is a value that is not relevant to the merchant).
• For NL merchants, Low VAT Category has been changed from 6% to 9% (as per new local legislation).
• Removed the error message 400.130, as Zero-Amount Void calls are now allowed.

• Implemented a new version of the risk provider API for the DACH market.
• New customer-facing messages for validating IBAN numbers from other countries.

• eCom API now tracks the expiration date of a Reservation independently. Before, a Reservation could expire without visibility to eCom. In this case, eCom would accept a Capture for an order whose Reservation had already expired.
• Now, eCom will reliably reject a Capture for an expired order.
• Improved validation for DateTime fields in the eCom API.
• eCom now strongly enforces the requirement to always provide the following:
• For the order total - Gross amount and Net amount.
• For each order item - Gross unit price, Net unit price, VAT amount, VAT percent.

• Fixed an error in handling Zero-Amount Authorize calls (see Release Notes for 3.40) where an Order Item had a negative Gross Unit Price. Now, negative Gross Unit Prices cannot affect the order's Reservation.
• eCom API now returns the proper error message when a B2B transaction is attempted in Germany. Riverty's German risk provider does not support companies as customers.
• Validation for the Customer Number field has been improved.
• eCom API now returns the correct error message if an Authorize request is sent with a missing opening curly bracket.
• Improved the masking of Customer Lookup data.
• Improved the translations of customer-facing messages.
• Significantly improved internal Message Queue operations.

• eCom now provides specific and localized responses to Authorize calls if the customer has failed a credit check. For example:
• If the merchant sends an Authorize call with a customer's details, and Riverty's risk provider returns a low score for that customer (meaning that Riverty cannot offer them Part Payment options), eCom will return a Business Error 200.105 with an appropriate Action Code, and a Customer Facing Message in the merchant's configured language, saying that Part Payments are not available, and the customer should select a different payment method.
• Payment method Direct debit now supports bankAccount with hyphens.

• Authorize and Available calls now support two new (optional) fields: ourReference and yourReference.
• Tags for field references are now supported within information displayed to customers (such as Titles and Taglines for payment methods, when returned for an Available call). For example:
• Split over |installment.numberOfInstallments| months will display as "Split over 5 months" if that payment method's Installment Profile is configured for 5 months.
• The text (including tags) is configured on the Riverty end, and cannot be changed by the merchant. Contact your Key Account Manager if you want to use this.

• The Riverty API documentation has been clarified for some fields that were marked as Optional, but are actually Required when used with Partial requests.

• eCom API now supports Authorize, Capture, Void and Refund calls where the Total Gross Amount is 0.
• Up to 100 calls of each type can be made for a particular Order. Otherwise error code 400.177 "Too many calls with 0 amount for same order" will be thrown.
• This is needed to support Voucher purchases, Consolidated Invoices and subscription services, where a single Order can remain open for a long time, and involve multiple transactions. Some transactions will have no cost, but the merchant wants them on the record.

• Error messages for eCom API errors 400.001 and 400.177 no longer mention the request field that contained incorrect data. These errors are returned in cases when a reference to a field is not relevant.

• Fixed a typo in the Developer Portal's API documentation. Order.Item types previously contained both ShippingFee and ShippingFees. The second one is redundant/incorrect and has been removed.
• Previously, a Full Refund worked only if the body of the request was empty.
• Now, it also works if the body contains orderItems=null (and additional parameters, such as an invoiceNumber).
• This was done to support the requirements of certain risk providers.

• Fixed incorrect negative amount handling in Refund calls.
• In case of an incorrect mobile prefix, the system was throwing an ArgumentOutOfRangeException. The exception was removed.

• Refund order response now contains the totalRefundedAmount field.
• Mobile phone numbers are now normalized by eCom.

• Previously, LanguageCode was a string. Now changed to enum.
• If an Authorize call uses a Direct Debit payment method, the bankCode is now optional and the bankAccount is mandatory, in all countries.

• Authorize and Available now have Customer.companyName.
• This is relevant if customerCategory=Company.
• customerLookupRequest now has the parameter customerCategory. The default value is "person".
• Customer Lookup now returns the postalCode of company addresses.

• In Authorize and Available calls, if **conversationLanguage **is not provided, the customer-facing message will be returned based on the merchant's Language Code (Core setting).
• The API now accepts only the 'YYYY-MM-DD' date format.
• The API now normalizes bankAccounts and **bankCode **inputs.
• Misleading error message 400.001 "Request body missing" has been changed to 400.001 "The body of the request is missing, or its format is invalid."

• Previously, if deliveryCustomer contained an invalid value for phone or mobilePhone, eCom would return 500 "System error". Now it returns the error 400.004 "Value format is incorrect."
• Fixed a typo in 400.120 "Cannot capture the order as a capture with the specified invoice number already exists."