This is where we document the changes to our API. Here, you'll find a record of product features and payment methods we've introduced, as well as new fields and values we've added.
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, 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).
- Changing our webhook event schemas.
In the event that a breaking change is unavoidable (e.g., for compliance reasons), we will contact you in advance to ensure that you have sufficient time to update your integration.
Friday, 12th
- We launched a brand new version of Frames. If you'd like to upgrade, read our migration guide.
Wednesday, 10th
- Added support for QPay, a popular payment method in Qatar.
Friday, 28th
- Added support for Fawry, a popular payment method in Egypt.
Thursday, 6th
- Added two new optional fields to the response to requesting a payment:
processing.retrieval_reference_numberprocessing.acquirer_transaction_id
- Added two optional fields to the response to retrieving payment actions:
processing.acquirer_reference_numberprocessing.acquirer_transaction_id
- Added two optional fields to the
payment_approved,payment_declined,card_verificationandcard_verification_declinedwebhooks:processing.retrieval_reference_numberprocessing.acquirer_transaction_id
- Added two new optional fields to the
payment_capturedwebhook notification:processing.acquirer_reference_numberprocessing.acquirer_transaction_id
- Introduced support for Bancontact and KNET.
Monday, 3rd
- Added further support for payment requests using the second version of 3D Secure authentication:
- Added an integration guide for our hosted and custom options.
- Added a list of required and optional data elements that can be included alongside the standard parameters in a payment request when requesting a 3DS2 payment.
Thursday, 16th
- The version of 3D Secure used for authentication is now provided in the
3ds.versionfield of the payment retrieval response.
Monday, 29th
- Added support for EPS, a popular payment method in Austria.
Wednesday, 24th
- The
source.bicfield in a Giropay payment request is now optional. If you include the Bank Identifier Code (BIC), your payment will follow a slightly different flow.
Friday, 12th
- Added an endpoint to iDEAL that allows you to get an up-to-date list of issuers that support iDEAL payments.
Monday, 8th
- 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.
Friday, 22nd
- Payment actions are now idempotent and therefore allow you to safely retry capture, refund and void requests. Find out more.
Friday, 8th
- Added support for Klarna, a favorite payment method in Europe.
Monday, 21st
- 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.
Thursday, 10th
- The
payment_approved,payment_declined,card_verifed, andcard_verification_declinedwebhook notifications now include anapprovedflag. This allows you to easily know if the authorization or capture was a success without having to use the status or response code.
Wednesday, 9th
- An
approvedflag has been added to the payment retrieval response, bringing it in line with the payment creation response. Primarily used in the redirection flows (3D 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.
Wednesday, 14th
- 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.
Wednesday, 24th
- Support for payments using pre-decrypted Apple Pay tokens has been added to the payments endpoint.
Thursday, 18th
- Support for network token payments has been added to the payments endpoint.
- Support for 3D 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 3D Secure and Visa token payments.
Thursday, 11th
- We now provide the
payment_account_referencefor 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.
Tuesday, 14th
- We’ve updated the Events API so you can search using
payment_idandreference. This will allow you to easily find events related to a particular payment.
Tuesday, 24th
- 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_idto start processing those payments with us, with no need to take the customer's details again.
Tuesday, 26th
previousChargeIdnow supports Visa’s scheme transaction ID. Find out more.
Wednesday, 4th
- Added support for Mada, Saudi Arabia's domestic payment network.
Monday, 2nd
- To support the new requirements from Visa and Mastercard for payments using stored card details, a new
cardOnFileand a newpreviousChargeIdfield must be included in charge requests where applicable. Find out more.
Wednesday, 21st
- Financial institutions now need to provide the
recipientDetailsin their charge requests when processing any domestic UK transactions. Find out more.
Thanks for using Checkout.com. If you need any help or support, please message our support team at support@checkout.com.