You're viewing documentation for our latest API. This will not impact your integration, but you will need the documentation relevant to you. If you have an account with Checkout.com you have received an email confirming which version to use.
In regions where SCA is mandated, following the Payment Services Directive (PSD2) means the initial cardholder-initiated transaction (CIT) payment will require SCA. As such, you must authenticate the CIT with a challenge in these mandated regions.
In your API request, set authentication_type to recurring or installment.
You will also need to send the recurring or installment object with the following required fields.
For Visa payments, the initial customer-initiated transaction (CIT) to set up a recurring or installment series should be processed as a regular authentication and the additional fields described in the following fields are not required.
Only applies to installment payments.
Integer Min : 1 Indicates the agreed total number of payment installments to be made in the duration of the installment agreement.
Integer Default : 1 Indicates the minimum number of days between authorisations. If no value is specified for a recurring authentication type the default value will be used.
String Default : "99991231" Date after which no further authorisations are performed in the format YYYY/MM/DD. If no value is specified for a recurring authentication type the default value will be used.
For non-recurring or non-installment payments, these fields will be ignored if they are sent to the API.
Redirect the customer using the _links.redirect URL you received in the response.
In the background, our Sessions API will then gather the device data, process the challenge (if required), and authenticate the payment. After authentication is completed, your customer will be redirected to your success_url or failure_url. You can now continue to authorize the payment via our Payments API.
If the authentication is approved or attempted, the customer will be redirected to your success URL. All other authentication results will redirect the customer to your failure URL.
Below are the possible values of the status field, which tell you the current status of the session.
Authentication has been requested and the session has been started. The session id is passed back to your server and can be shared with the mobile app (iOS or Android) SDK.
The 3DS server has updated the authentication with channel data collected by the SDKs and has created and sent an authentication request to the directory server. The access control server is now evaluating the data to decide whether to authenticate the transaction (frictionless) or challenge it.
The payment has been successfully authenticated (frictionless or challenged).
The payment has been authenticated by a stand-in service, because the access control server could not be reached or does not support 3DS2 natively. You can treat this as a successful authentication and proceed to authorization.
Authentication failed because of technical problems with the directory server or the issuer's access control server.
The transaction was not authenticated. The issuer denied the transaction.
The transaction was rejected. The issuer is rejecting the authentication and requests that authorisation not be attempted.
Authentication has been requested but the issuer requires that the cardholder be presented with a challenge.
Authentication has been started and challenged, but the cardholder did not complete the challenge.
Authentication has been started but the channel data could not be collected, meaning an authentication request was not created.
Below are the possible values for the next_actions field. When present, they identify what action to take in order to complete the session.
Redirect the customer so we can handle all the other necessary actions (collect channel data, issuer fingerprint, and challenge) for you.
Hosted and non-hosted
No further actions are required. You can complete the session.
Browser and app
When requesting a session, you can add additional data fields to increase the chances of a frictionless authentication. Below is a summary of the optional data you can add to your request.
Type of data
Description and examples
Client user data
Data that supports the specific authentication and information about the authentication method used.
For example, your own credentials, and the issuer's credentials.
Prior transaction information
For returning users and recurring transactions, gather and submit data with each following transaction.
For example, when the recurring payment plan expires, payment references, and the authentication method used.
Indicates whether the cardholder's shipping and billing address are the same.
Cardholder account / user information
Information about the cardholder and their account on your platform.
For example, how long they've had an account with you, and the number of purchases they've made in the last six months.
User purchase history
Details of the cardholder's purchase history.
For example, the number of purchases in the last six months, and the number of card attempts in the last 24 hours.
Shipping address usage
Information about the use of the shipping address.
For example, when the shipping address was first used, and whether the address name matches the cardholder's name.
Suspicious account activity
Indicates whether you've experienced any suspicious activity on the cardholder's account.
Additional information you want to provide about the cardholder and their account with you.
Cardholder email address
The email address associated with the cardholder's account.
Cardholder shipping address
The cardholder's full shipping address.
Indicate the shipping method being used for the order, or flag non-shippable items, like digital goods.
For example, whether it's being shipped to a verified address on file, or being picked up by the cardholder from a local store.
Information about the delivery, like the delivery email address or delivery timeframe.