Change Log

New PaymentsOS API features and fixes are released from time to time. Changes that will require you to update your integration code are always released under a new api-version number. For this reason, we recommend that you always include an api-version header in your requests. This ensures that the changes we introduce will not break your code.

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:

Payments API version 1.2.0

results matching ""

    No results matching ""