Changelog

We take the utmost care in ensuring that changes to our APIs do not break your integrations. We consider the following changes to be backward-compatible:

  • Adding new API resources/endpoints.
  • Adding new, optional request fields/parameters to existing APIs.
  • Adding new fields to existing API responses.
  • Adding new, optional HTTP request headers.
  • Adding new HTTP response headers.
  • Increasing the length of existing string field values.
  • Changing the format of identifiers including changing or removing prefixes.
  • Adding new webhook event types (you will need to explicitly opt into these).

Note that the above also applies to changes in our webhook event schemas.

In the event that a breaking change is completely unavoidable (e.g., for compliance reasons), we will contact you in advance to ensure that you have sufficient time to update your integration.

Changelog

12 July 2019

We've launched a brand new version of Frames. If you'd like to upgrade, read our migration guide.

10 July 2019

Added support for QPay, a popular payment method in Qatar.

28 June 2019

Added support for Fawry, a popular payment method in Egypt.

6 June 2019

  • The response to requesting a payment now includes two new optional fields: processing.retrieval_reference_number and processing.acquirer_transaction_id.
  • The response to retrieving payment actions now includes two new optional fields:
    processing.acquirer_reference_number and processing.acquirer_transaction_id.
  • The payment_approved, payment_declined, card_verification and card_verification_declined webhooks have two new optional fields: processing.retrieval_reference_number and processing.acquirer_transaction_id.
  • The payment_captured webhook notification has two new optional fields: processing.acquirer_reference_number and processing.acquirer_transaction_id.
  • Added support for Bancontact and KNET.

3 June 2019

  • Added further support for payment requests using the second version of 3D Secure authentication:

16 May 2019

The version of 3D Secure used for authentication is now provided in the 3ds.version field of the payment retrieval response.

29 April 2019

Added support for EPS, a popular payment method in Austria.

24 April 2019

The source.bic field in a Giropay payment request is now optional. If you include the Bank Identifier Code (BIC), your payment will follow a slightly different flow.

12 April 2019

Added an endpoint to iDEAL that allows you to get an up-to-date list of issuers that support iDEAL payments.

8 April 2019

Added support for payments requests using the second version of 3D Secure authentication (3DS2) to help merchants comply with Strong Customer Authentication (SCA) requirements. Find out more.

22 March 2019

Payment actions are now idempotent and therefore allow you to safely retry capture, refund and void requests. Find out more.

9 February 2019

Added support for Klarna, a favorite payment method in Europe.

21 January 2019

The response to retrieving a payment using a session ID will now include an action object, which provides a summary of the actions performed for that payment.

10 January 2019

The payment_approved, payment_declined, card_verifed, and card_verification_declined webhook notifications now include an approved flag. This allows you to easily know if the authorization or capture was a success without having to use the status or response code.

9 January 2019

An approved flag has been added to the payment retrieval response, bringing it in line with the payment creation response. Primarily used in the redirection flows (3-D Secure and APMs), this allows you to easily know if the authorization or capture was a success without having to use the status or response code.

14 November 2018

  • Our payments endpoint is now idempotent, allowing you to safely retry payments without a duplicate payment taking place. Find out more.
  • We now provide you with the scheme transaction ID (scheme_id) in the response when creating a payment.

24 October 2018

Support for payments using pre-decrypted Apple Pay tokens has been added to the payments endpoint.

18 October 2018

  • Support for network token payments has been added to the payments endpoint.
  • Support for 3-D Secure payments where the cardholder is authenticated using a third-party MPI has been added to the payments endpoint.
  • The ECI value that the payment was authorized with is now provided in the response to 3-D Secure and Visa token payments.

11 October 2018

We now provide the payment_account_reference for digital wallet and Visa token payments. This is a reference to the underlying card and allows you to know if two tokens reference the same underlying card.

14 August 2018

We’ve updated the Events API so you can search using payment_id and reference. This will allow you to easily find events related to a particular payment. Find out more.

24 July 2018

For recurring payments that use stored card details, you can now use the scheme transaction ID from a payment processed by your current acquirer as your previous_payment_id to start processing those payments with us, with no need to take the customer's details again.

26 June 2018

previousChargeId now supports Visa’s scheme transaction ID. Find out more.

4 April 2018

Added support for Mada, Saudi Arabia's domestic payment network.

2 April 2018

To support the new requirements from Visa and Mastercard for payments using stored card details, a new cardOnFile and a new previousChargeId field must be included in charge requests where applicable. Find out more.

21 March 2018

Financial institutions now need to provide the recipientDetails in their charge requests when processing any domestic UK transactions. Find out more.

2 February 2018

We have introduced new chargeback and retrieval webhooks to help keep you up to date on your payments. You can subscribe to them by updating your configuration through our API or via the Hub.

Can we help?

Thanks for using Checkout.com. If you need any help or support, then message our support team at support@checkout.com.

Changelog


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.