Strengthen the security of your online payments
Online payment security is a key factor in protecting your business from fraud, reducing the risk of chargebacks, and providing a reliable payment experience for your guests.
Gateways integrated with Avantio Payments include security mechanisms such as tokenization and allow you to manage payments in compliance with requirements like PSD2, SCA (Strong Customer Authentication), and 3DS (3D Secure).
Understanding these concepts and knowing how they apply to different types of transactions will help you manage your payments more securely and understand when guest intervention may be required.
What will you learn in this article?
You’ll learn what PSD2, SCA, and 3DS mean, how they relate to each other, and what the differences are between CIT, MIT, and MOTO transactions in the payment process.
Advantages
Increased security: reduces the risk of fraud and protects both your business and your guests.
Greater trust: using authentication and data protection mechanisms provides security throughout the payment process.
Regulatory compliance: allows you to manage payments in line with the requirements for electronic transactions.
When should you consider these concepts?
You should keep them in mind whenever you manage card payments through Avantio Payments, especially when you want to understand why some payments require guest authentication and others can be processed automatically.
They are also especially relevant when you work with:
Bookings made directly from your website.
Subsequent payments for the same booking.
Bookings from portals or OTAs.
Virtual cards.
Additional services or amounts added after the booking is made.
Before you start
It’s helpful to know three key concepts first:
PSD2 (Payment Services Directive 2): European regulation that governs payment services and sets out measures to increase the security of electronic transactions and reduce fraud.
SCA (Strong Customer Authentication): a reinforced authentication mechanism that may require the customer to identify themselves using at least two different factors.
3DS (3D Secure): technology used in card payments to apply authentication processes, for example via a banking app, a security code, or biometrics.
SCA authentication can combine factors related to:
Something the customer knows, such as a password or PIN.
Something the customer has, such as their mobile phone.
Something the customer is, such as their fingerprint or facial recognition.
You should also keep in mind that not all payments are initiated in the same way. The type of transaction determines, among other factors, how authentication can be applied.
Follow these steps
Identify who initiates the transaction
The first step is to determine whether the payment is initiated directly by the guest, by your business, or is processed using card details received from a portal.
Identify the type of transaction
In Avantio, you’ll mainly encounter the following scenarios:
CIT – Cardholder Initiated Transaction
A transaction initiated directly by the cardholder.
A common example is the first payment made by the guest when booking on your website.
This type of transaction may require strong authentication using SCA and 3DS to validate the cardholder’s identity.
MIT – Merchant Initiated Transaction
A transaction initiated later by the merchant without the guest needing to be involved at that moment.
A common example is the second scheduled payment for a booking made on your website.
This type of charge can be made when there is a prior authorization linked to the initial transaction made by the customer.
MOTO – Mail Order / Telephone Order
Transactions made using card details received through channels where the cardholder is not directly involved at the time of payment.
In Avantio, this scenario can occur with certain bookings from OTAs.
MOTO transactions cannot apply SCA in the same way as a transaction initiated directly by the cardholder, so they may carry a higher risk of fraud or chargebacks.
Check if the payment needs new authorization
Authentication will depend on the origin and characteristics of the payment.
For example:
A first payment initiated by the guest may require authorization via SCA.
A subsequent payment linked to a previous authorization can be processed as MIT.
A new amount that was not part of the initial booking may require new authorization from the guest.
Review your Avantio Payments configuration
Check that your payment gateway and Avantio Payments configuration match the types of bookings and cards you work with.
If you handle virtual cards, make sure the corresponding transaction type is enabled in your payment gateway.
Expected result
Your payments will be managed using the appropriate authentication flow for each transaction type, helping you reduce risks and protect card operations.
Guest involvement may vary depending on the origin of the payment, existing authorization, and the specific characteristics of the transaction.
Recommended next steps
After learning how PSD2, SCA, 3DS, and the different transaction types work, review how your payments are set up in Avantio Payments.
Check how payments are managed for bookings from your website and from portals.
Review the authorization settings for cards received from OTAs.
If you work with virtual cards, make sure your gateway supports the required transaction type.
Refer to the related Avantio Payments guides to set up your payments correctly.
Limitations and considerations
Keep in mind that:
The need for authentication may vary depending on the type of transaction, the card origin, and the payment conditions.
MOTO transactions cannot apply SCA in the same way as payments initiated directly by the cardholder.
A subsequent payment can be processed as MIT when there is a valid prior authorization linked to the initial payment.
Additional amounts that were not part of the original authorization may require new authorization from the guest.
If you work with virtual cards, you must ensure your payment gateway can process this type of transaction.
Gateways integrated with Avantio Payments use tokenization, so sensitive card data does not need to be handled directly during subsequent payments.
Best practices
Regularly review the security settings of Avantio Payments.
Correctly distinguish between guest-initiated payments, subsequent payments, and charges from OTAs.
Use authentication mechanisms when available to reduce the risk of fraud and chargebacks.
Check that your gateway supports the transaction types needed for your operations.
Avoid handling sensitive card data directly whenever you can use tokenized processes.
Pay special attention to payments from OTAs when the guest’s real card is used.
Practical example
Challenge:
An agency receives a booking from its website with two scheduled payments: a first amount at the time of booking and a second charge a few days before arrival.
Analysis:
The first payment is initiated directly by the guest and may require authentication. The second payment is linked to the authorization made during the initial transaction.
Strategic decision:
The agency sets up its payment conditions in Avantio Payments so that the first charge is authenticated and the second can be managed later as a merchant-initiated transaction.
Expected result:
The first payment has the necessary authentication, and the second can be processed automatically without asking the guest again, as long as it stays within the originally authorized conditions.
Frequently asked questions
Why doesn’t the second payment for a booking usually require new authentication?
Why doesn’t the second payment for a booking usually require new authentication?
Because it may be a MIT (Merchant Initiated Transaction) transaction.
In this case, the payment is initiated later by the merchant using the authorization granted by the guest during the initial transaction.
What is the purpose of double authentication for bookings from portals?
What is the purpose of double authentication for bookings from portals?
Certain transactions from portals may be managed as MOTO, so they don’t natively include the same authentication process as a payment initiated directly by the guest.
The configuration available in Avantio Payments allows you to add prior authorization to certain charges to increase the security level of these transactions.
What risks are associated with payments from OTAs?
What risks are associated with payments from OTAs?
When a transaction is processed as MOTO, SCA cannot be applied in the same way as a payment initiated by the cardholder, so it may carry a higher risk of fraud or chargebacks.
If the portal provides the guest’s real card, you can review your Avantio Payments configuration to request authorization before making certain charges.
If you work with a virtual card, make sure your gateway can process this type of transaction.
What’s the difference between CIT, MIT, and MOTO?
What’s the difference between CIT, MIT, and MOTO?
The main difference is who initiates the payment and how authorization is obtained:
CIT: the guest initiates the transaction directly.
MIT: the merchant initiates a subsequent payment based on prior authorization.
MOTO: the charge is processed using card details provided through other channels, such as certain bookings from OTAs.
How does tokenization improve payment security?
How does tokenization improve payment security?
Tokenization replaces sensitive card data with an identifier or token.
This way, subsequent payments can be managed without needing to use the full card details directly, reducing the exposure of sensitive information.
Gateways integrated with Avantio Payments use this system to manage cards more securely.
What happens if I add an extra service after making the reservation?
What happens if I add an extra service after making the reservation?
If you add a new charge that was not included in the original authorized amount, such as an extra service booked later, a new authorization from the guest may be required.
The system can process the payment afterwards, but will first include the necessary authorization process for the new amount.
Are 3DS and SCA the same thing?
Are 3DS and SCA the same thing?
Not exactly.
SCA is the requirement for strong customer authentication, while 3DS is a technology used in card payments to carry out that authentication process.
For example, during a 3DS payment, the guest may need to confirm the transaction in their banking app, enter a code, or use biometrics.