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.
- The response to requesting a payment now includes two new optional fields:
- The response to retrieving payment actions now includes two new optional fields:
card_verification_declinedwebhooks have two new optional fields:
payment_capturedwebhook notification has two new optional fields:
The version of 3D Secure used for authentication is now provided in the
3ds.version field of the payment retrieval response.
Payment actions are now idempotent and therefore allow you to safely retry capture, refund and void requests. Find out more.
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.
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.
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.
- 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.
Support for payments using pre-decrypted Apple Pay tokens has been added to the payments endpoint.
- 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.
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.
previousChargeId now supports Visa’s scheme transaction ID. Find out more.
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.
Financial institutions now need to provide the
recipientDetails in their charge requests when processing any domestic UK transactions. Find out more.
Thanks for using Checkout.com. If you need any help or support, then message our support team at email@example.com.