Change Log

New PaymentsOS API features and fixes are released from time to time. All new features and fixes are listed in the change log below.

Upgrading to the Latest API Version

When upgrading to the latest API version, you should be aware that there are two types of changes: breaking changes and non-breaking changes:

  • Breaking changes are changes that could potentially break your existing API requests, if your requests don't include an api-version header. A breaking change can be introduced, for example, when we add a new mandatory request parameter to an existing API request. We increase the api-version number when we release these type of API changes. For this reason, you should always include an api-version header in your requests, so as to ensure that the changes we introduce will not break your code.
  • Non-breaking changes are changes do not break your existing API requests. Non-breaking changes include new API resources, optional request parameters or new response objects. Note that we reserve the right to introduce non-breaking changes without prior notice. Make sure that your integration does not treat the presence of unexpected non-breaking-attributes in responses, as an error condition.

Fixes and New Features

September 2020

Payments API The Payments API now returns a 429 HTTP response code in the event that too many requests hit the API too quickly.
Payments API The addendums.airline_passenger_itinerary.airline_designator_code field now also accepts digits.
Management API When downloading a Key PEM File after generating a RSA JSON Web Key (JWK), you can now specify whether to download it as file holding the JWK public key properties, or as a certificate that is self-signed by PayU as the certificate authority.

August 2020

Provider Integrations PaymentsOS now supports 3D Secure version 1 Internal with PayU Asia Pacific.
Provider Integrations PaymentsOS now supports BT24 Internet Banking and BCR Click 24 bank transfer payment methods with PayU Romania.

July 2020

Payments API PaymentsOS now allows you to perform a fraud risk analysis on a payment that was initiated, by invoking the Perform a Risk Analysis request.
Management API PaymentsOS now supports End-to-End Encryption (E2EE), allowing you to pass encrypted card data in an authorization request. You can use the Encryption Keys endpoints for generating a RSA JSON Web Key (JWK) to be used for encrypting the card data. For more information, see End to End Encryption.
Payments API PaymentsOS now provides a Retrieve Supported Plans endpoint for fetching details of plans (such as installment plans) configured in your provider account.
Provider Integrations Added support for domestic Chinese merchants who want to integrate with AliPay.
Provider Integrations Added support for credit card transactions with PayU Asia Pacific.
Provider Integrations Added support for passing a statement soft descriptor in payment requests routed to PayU South Africa.
Provider Integrations PaymentsOS now supports fast refunds for refund requests routed to PayU Romania, allowing a refund amount to be paid to the customer within 30 minutes after the refund has been processed. Fast refunds are supported for payments done in RON, EUR or USD with MasterCard or Visa.
Provider Integrations The provider_data returned in the response of transaction requests routed to PayU Romania, PayU Turkey and PayU Russia now also includes an rrn (retrieval reference number) field. The rrn can be used to track transactions at the issuer bank of the customer and the card scheme networks.
Provider Integrations Added support for installments with transactions routed to PayU India. This includes the ability to pass a code representing the number of allowed installments, as defined in your PayU India payment plan.
Provider Integrations You can now pass an invoice_id issued for transactions routed to PayU India. Use the Bodybuilder to generate a sample request.

June 2020

Provider Integrations Added support for automatic captures with PayU Single Platform.

April 2020

Payments API PaymentsOS now provides a 3D Secure Authentication service that handles the entire 3D secure authentication flow, with support for both 3D Secure version 1 and version 2.
Management API Added the authentication resource fields that can be excluded from a webhook's data object. See the Provider Retrieve Blacklist Fields API request.
Management API Added Features endpoints for fetching feature information from an account, and enabling or disabling a feature per Business Unit.
Reporting API Added new report columns: transaction_authentication_type, transaction_authentication_id, transaction_return_partial_result

November 2019

Reporting API Added new report columns: payment_statement_soft_descriptor, cof_transaction_indicators_card_entry_mode, cof_transaction_indicators_consent_transaction_id, transaction_three_d_secure_auth_status, transaction_three_d_secure_result_version, transaction_three_d_secure_result_eci, transaction_three_d_secure_result_type, provider_cvv_verification_code
Payments API The API now includes support for passing SCA (Strong Customer Authentication) exemption data in the three_d_secure_attributes.sca_exemptions object.
Payments API The three_d_secure_attributes.internal.product_code field is now required in an internal 3DS transaction flow when transacting against Credorax.

August 2019

Reporting API Introduced in version: 1.1.0 You can now Create a Report Schedule to automatically generate a report each day, week or month. Note: As part of this change, the timezone field was renamed to display_timezone.
Payments API The API now includes support for initiating a 3DS 2 internal and external transaction flow. The three_d_secure_attributes.external and three_d_secure_attributes.internal objects include all additional fields that should be passed as part of an internal or external 3DS 2 transaction flow.

July 2019

Payments API The provider_data object holding the response returned from a provider, now also includes a transaction_cost object. This object holds information about the fees that the provider applied to the transaction.

April 2019

Payments API Introduced in version: 1.3.0. If you are SAQ D compliant, you can now pass full credit card details in a Create Authorization, Create Charge and Create Credit request without using our tokenization service.
Payments API Introduced in version: 1.3.0. The three_d_secure_attributes object (passed in a Create Authorization , Create Charge and Create Credit request) has been modified to include a nested external object for passing data received from an external MPI.
Payments API Introduced in version: 1.3.0. The following fields/objects were added to the response of the Create Token request: holder_name,expiration_date,last_4_digits,billing_address (only applicable to a token_type of credit_card) and shipping_address.
Payments API Introduced in version: 1.3.0. The Create Token request now also returns a HTTP 503 status code in the event of a Service Unavailable error.
Payments API Introduced in version: 1.3.0. Instead of creating multiple Create Payment Method requests, you can now also pass an array of payment methods in a Create Customer request.
Payments API Introduced in version: 1.3.0. The eci_flag indicator (passed in the three_d_secure_attributes.external object of a Create Authorization, Create Charge and Create Credit request) now only accepts one of the values that can be returned by the card processing networks.
Payments API Introduced in version: 1.3.0. The provider response data (returned in the provider_data object) now also includes a cvv_verification_code field, holding the result of the CVV verification check performed by the card issuer.
Payments API Introduced in version: 1.3.0. The Payments API now strictly validates the data types you pass. If your data does not meet the API specification, an error will be returned.
Management API You can now retrieve the availability status of your providers. For more information, see the Provider Health API requests.

March 2019

Payments API The bank_code field was added to the response of the Retrieve Supported Payment Methods request.
Management API You can now exclude fields from the data object returned in the webook event body. See the Webhooks topic for more information.

September 2018

Webhooks Introduced in version: 1.2.0. The webhook body now also returns the complete transaction resource related to the Webhook event. Important: changes have been made to the structure of both the event body and the event header. See the Webhooks topic for more information.

January 2018

Payments API Introduced in version: 1.2.0. You can now save a token, so that customers do not need to re-enter their payment details each time they want to initiate a transaction on your site. The token object has been extended to include a state attribute whose value reflects the token's usage.
Webhooks An order_id (if available) has been added to the `resource` object.

November 2017

Payments API Introduced in version: 1.1.0. All amounts and unit_prices have been changed to minor currency units format, and their field types have been changed from double to integer (for details see the Minor Units Format guide.)
Payments API Introduced in version: 1.1.0. The type attribute was renamed to token_type, and a new type attribute was added. This change affects the token resource and the payment-method resource.
Payments API Introduced in version: 1.1.0. The country_code format, in the payment-method resource changed from 2 to 3 letter ISO 3166-1 alpha-3 format.
Payments API Introduced in version: 1.1.0. The payment_method object is now mandatory for the POST Authorize and POST Charge methods.
The payment_method_token and credit_card_cvv attributes were moved from the body of these methods, into the new mandatory payment_method object.
Payments API Introduced in version: 1.1.0. HTTP error code 504 was replaced by error code 503.
Payments API Introduced in version: 1.1.0. If the x-client-ip-address is not sent in POST Authorize or POST Charge methods, then we will no longer substitute the server ip_address as the default value.

October 2017

Payments API The following Response Sub-categories were added: insufficient_funds and lost_stolen_card.

July 2017

Webhooks Introduced in version: 1.0.1. The structure of the POST request body has been modified to include a resource object. You will not receive the new structure, unless you upgrade to this version.

Previous API Versions

Still on a previous API version? If so, you can find older references here:

results matching ""

    No results matching ""