Supported Functionality

Feature	Supported
Authorization	✅
Capture	✅
Refund	✅
Void	✅
Card Tokenization	✅
Dynamic Merchant Descriptors	✅ Trimmed to 25 characters
3D Secure	✅ Pass your own or gateway-managed
$0 Transactions	✅

Setup

To connect a Merchant using the Checkout.com Gateway,

First add Merchant
Select Checkout.com as the Gateway
Add Gateway Details as outlined below

Gateway Details	Description
API Secret Key*	provided by Checkout.com
Using Previous API Version	Check this box if this merchant is boarded on Checkout.com's previous API version. When it is unchecked Vrio uses the current API, and a Processing Channel ID is required.
Processing Channel ID**	Processing Channel ID provided by Checkout.com. Sent with every charge on the current API version.
Sandbox	Check this box if these are sandbox credentials. When checked, requests are sent to the Checkout.com sandbox environment.
Merchant Payment Methods*	The types of payment methods this merchant accepts — credit card only.
Merchant Card Types*	Card types to be accepted on this Merchant
Merchant Default Currency*	Default currency that will be used, if currency is not specified
Merchant Currencies*	All currencies accepted on this merchant
Pass Merchant Descriptor	When checked, the merchant descriptor set on the Merchant Account is sent to Checkout.com with the charge. See Dynamic Merchant Descriptors.
Bypass $0 Transaction Authorizations	Checkout.com accepts $0.00 transactions and will validate the card when processing them. Check this box to bypass the gateway entirely for $0 transactions. This setting only applies to initial transactions — $0 renewals will always bypass the gateway. Learn more about $0.00 transaction handling.
Pass MOTO Payment Type	Check this box to send initial transactions with the payment type MOTO (Mail Order/Telephone Order). See MOTO below.
Attempt 3D Secure	Have Checkout.com authenticate the cardholder on initial transactions. Requires a `redirect_url` to be passed with the order. See 3D Secure below.
Allow Non-3DS Fallback	Only shown when Attempt 3D Secure is checked. Approve cards that are not enrolled in 3D Secure instead of declining them. See Cards that are not enrolled below.

Required *Required unless Using Previous API Version is checked

Supported Payment Methods

Credit Card

Card Tokenization

Charges made with card data ask Checkout.com to save the card. Vrio stores the returned source id and reuses it for every renewal.

Dynamic Merchant Descriptors

When Pass Merchant Descriptor is checked, Vrio sends the Merchant Account descriptor with every charge, or a merchant_descriptor passed when the order is processed, which is then reused for that order's renewals.
If the order later moves to a different merchant, that merchant's descriptor is used instead.
Checkout.com accepts up to 25 characters and silently shortens anything longer.

3D Secure

Checkout.com can perform 3D Secure authentication itself, with Vrio handling the redirect back to you. This is separate from generating authentication data with a third party provider such as PAAY and passing it to Vrio — for that, see Third Party 3DS Providers. If you pass third party authentication data, it takes precedence and Checkout.com will not run its own authentication.

Two things are required to trigger it, and both must be present:

Attempt 3D Secure checked on the merchant.
A redirect_url passed when the order is processed.

With the box checked but no redirect_url, or with a redirect_url but the box unchecked, the order is processed as an ordinary payment with no authentication. Because renewals are processed without a redirect_url, a stored card being rebilled is never sent for authentication.

The flow

Process the order, passing a redirect_url you host.
If the card is enrolled, Vrio returns a success response with response_code: 101 and the Checkout.com authentication URL in post_data.
Send the customer to the URL in post_data. They authenticate with their issuer and are returned to your redirect_url.
Complete the order with POST /orders/{order_id}/complete, passing the payment ID returned to your redirect_url as the transaction_token. (When using the Legacy API, use POST /order/doProcess3ds.)

For full details on handling the 101 and the completion call, see Handling 101 Response Codes.

📘
Every card that is enrolled in 3D Secure returns a 101, including cards that authenticate without challenging the cardholder. Checkout.com performs device data collection behind the authentication URL and decides there whether a challenge is needed, so a frictionless authentication still requires the round trip. The customer simply is not asked for anything before being returned to you.

Cards that are not enrolled

A card that is not enrolled in 3D Secure cannot be authenticated. By default Checkout.com declines these with response code 20150 and the message Card not 3D-Secure enabled.

Check Allow Non-3DS Fallback on the merchant to approve these payments instead. Checkout.com falls back to an ordinary unauthenticated authorization and returns 3ds.downgraded = true on the payment, which is stored with the full gateway response on the transaction.

This setting only affects cards that are not enrolled. Enrolled cards are unaffected, and a challenge that the cardholder fails or abandons is still declined — a fallback cannot override an issuer that has rejected the authentication.

🚧
A payment that falls back to non-3DS is not authenticated, so fraud chargeback liability stays with you rather than moving to the card issuer. Cards issued in the EEA and UK are also subject to Strong Customer Authentication, and their issuers commonly decline unauthenticated transactions regardless of this setting.

Passing your own values

Checkout.com also accepts 3D Secure authentication data that you generate with a third party provider. When those values are present on the order they are sent with the charge and Checkout.com does not run its own authentication.

Vrio	Checkout.com
`order_eci`	`three_ds.eci`
`order_cavv`	`three_ds.cryptogram`
`order_xid`	`three_ds.xid`
`order_cardholder_auth`	`three_ds.status`
`order_3ds_version`	`three_ds.version`

See Third Party 3DS Providers for the full parameter reference.

MOTO

When Pass MOTO Payment Type is checked, Vrio sends initial transactions to Checkout.com with payment_type: MOTO, which tells Checkout.com the order was taken by mail or telephone.

The setting only affects the first charge on an order. Renewals are always sent as payment_type: Recurring, whatever this box is set to.

📘
3D Secure takes priority
MOTO describes an order taken while the cardholder is not present, and 3D Secure authenticates a cardholder who is, so the two describe opposite transactions. When an authentication is actually being attempted, Vrio leaves MOTO off.
That covers both ways a transaction gets authenticated: Attempt 3D Secure running on an order processed with a redirect_url, and third party authentication data present on the order as described in Passing your own values. Everything else with the box checked is still sent as payment_type: MOTO.

Testing

Note : Placing test orders using Checkout.com test cards will not automatically set the order as a test in Vrio. Be sure to flag the order as a test using the is_test flag after the order is processed. For more details on placing test orders, click here.

For Checkout.com test cards, check here.