Online Payments: Security and Efficiency
3DSv2 Card Payments and Frictionless Payments
As the volume of online transactions increases, so does the risk of financial fraud. To tackle these challenges, the European Union has implemented measures, mostly around security, to protect consumers and businesses alike. One crucial development is the introduction of 3D Secure v2: all payments must now go through risk assessments by banks and schemes.
Risk-based assessments are based on the following elements:
- Client information
- Transaction value (usually large amounts are subject to challenge)
- Transaction history
- Device information
- Behavioural history
Determining the Payment Mode: Web or Direct Card Payments Mode?
Lemonway offers API methods for two types of card payment modes: Web and Direct Payments.
Web Payments
They are used when the end-user buys a service or goods on a partner's website and then is redirected to the PSP (Payment Service Provider) payment page. The benefits of using this mode are:
-
PSPs are PCI-DSS certified
-
PSPs usually support multiple currencies
-
PSPs support a wide range of payment methods (debit and credit cards, mobile wallets, and more)
Did you know?
Neither Lemonway nor the Partner process the bank card owners' data when this mode is used.
Direct Mode Payments
They are used when our Partners want to process payments using their own payment page, without redirecting their users to another URL outside their network.
PCI-DSS Certified
Partners using this mode are obliged to maintain a high level of network security and be PCI-DSS certified.
This section outlines Lemonway’s current card payment solutions and how you can implement them on a use-case basis.
Security and 3D Secure v2
Better known by its commercial names Visa Secure, Mastercard Identity Check or American Express SafeKey, the 3D Secure protocol aims to reduce fraud and strengthen the security of online payments.
To deal with fraudulent payments, the card networks rolled out the first version of the 3D Secure protocol in 2001: Address Verification System (AVS), CVC code verification, second verification with a code... However, it added complexity to the payment process so it has been rethought to give 3D Secure v2.
One of the main differences in version 2 is that the issuer can use a large amount of data from the transaction to determine the risk of the transaction (risk-based analysis). For low-risk transactions, issuers do not further check the transaction although they authenticate it (the transaction is fluid - without strong authentication). On the contrary, for high-risk transactions, issuers will require the cardholder to authenticate himself using a code sent via SMS or a biometric via an application or other means.
In addition, the strong authentication (SCA) required from 1 January 2021 for the European Union, as specified in the Payment Service Directive PSD2, will lead to a substantial increase in the number of transactions requiring the use of 3D Secure authentication. The use of 3D Secure version 2 should limit the negative impact on conversion as much as possible.
Strong Authentificaction
The DIRECTIVE (EU) 2015/2366 defines the Strong Authentification as: "an authentication based on the use of two or more elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data".
Strong authentication is a guarantee of confidentiality that is particularly useful to ensure security.

What is Strong Customer Authentification?
3D Secure v2 - Impact for Card Payments
The Payment Service Directive, commonly known as PSP2 requires SCA (Strong Customer Authentication) to be implemented as part of a set of new measures to combat fraud and increase security. All CIT (Customer Initiated Transactions) are required to go through the 3-D Secure v2 protocol.
What does this change for you in the short term?
Lemonway wants to ensure that card payments are processed smoothly with no declines, we will outline some recommendations and best practices to help you during this transition period.
Partners using the Web Payment mode
Payments with a New Card
📘 Register a card
*Optional. To make future payments on the card, set
registerCard=1 (APIv1)
orregisterCard=true (APIv2)
Payments with a Registered Card
- Use Get Card Information API v2 or Check if Card is Registered API v1 to confirm the end-user's card is registered.
- Use Initiate a Web Payment API v2 or Initiate a Web Payment API v1 to make transactions using the end-user's cardId.
Subscriptions with Equal Recurring Amounts
- For the initial subscription payment, use Initiate a Web Payment API v2 or Initiate a Web Payment API v1 and ensure that you set:
registerCard=true (APIv2)
orregisterCard=1 (APIv1)
. - Use Charge a Registered Card API v2 or Charge a Registered Card API v2 (APIv1) for all subsequent equal amounts payments.
Payments Upon Delivery
- Use API v2: Initiate a Web Payment or API v1: Initiate a Web Payment to pre-authorize the amount you will charge upon delivery. Ensure that you set the
delayedDays
field between 1 to 6 days. - To guarantee the payment, use Capture a Deferred Payment API v2 or Capture a Deferred Payment API v2.
- To capture funds use Charge a Registered Card API v2 or Charge a Registered Card API v1.
For PCI-DSS Partners using Direct Payment mode (no PSP page):
Payments with a New Card
1. Initialize Payment- Use API v1 moneyin3dinit or API v2 moneyins_direct3dinitpost to initiate the payment.
- To enable future payments on the card, set the
registerCard=1 (API v1)
orregisterCard=true (API v2)
.
- The card owner will be authenticated with 3-D Secure.
- After the end-user has authenticated, call
MoneyIn3DAuthenticate (API v1)
orPOST /moneyins/card/direct/{transactionid}/3dauthenticate (API v2)
to check the status of 3D Secure Authentication after receiving a callback from the Payment Service Provider (PSP).
- Finally, call
MoneyIn3DConfirm (API v1)
orPUT /moneyins/card/direct/{transactionid}/3dconfirm (API v2)
to complete the payment.
Payments with a Registered Card
1. Check Card Registration and Initialize Payment- First, call the
GetCard (APIv1)
orGet /v2/moneyins/card/{cardId} (APIv2)
method to ensure that the end-user's card is registered. - If the end-user's card is registered, then call the
MoneyIn3DInit (APIv1)
orPOST /moneyins/card/direct/3dinit (APIv2)
method.
- The card owner will be authenticated with 3-D Secure.
- After the end-user has been authenticated, you should call
MoneyIn3DAuthenticate (APIv1)
orPOST /moneyins/card/direct/{transactionid}/3dauthenticate (APIv2)
to check the status of 3D Secure Authentication after receiving a callback from the Payment Service Provider (PSP).
- Finally, call
MoneyIn3DConfirm (APIv1)
orPUT /moneyins/card/direct/{transactionid}/3dconfirm (APIv2)
to finalize the payment.
Subscriptions with Equal Recurring Amounts
1. Initial Subscription Payment- For the initial subscription payment, use
MoneyIn3DInit (APIv1)
orPOST /moneyins/card/direct/3dinit (APIv2)
. - Then, use
MoneyIn3DAuthenticate(APIv1)
orPOST /moneyins/card/direct/{transactionid}/3dauthenticate (APIv2)
.
- Use
MoneyIn3DConfirm (APIv1)
orPUT /moneyins/card/direct/{transactionid}/3dconfirm (APIv2)
as explained below.
- Use
MoneyInWithCardID (APIv1)
orPOST /moneyins/card/{cardid}/rebill (APIv2)
for all subsequent payments.
Not Recommended
Lemonway does not recommend you use the MoneyIn and RegisterCard method from January 2021. Instead, you should use MoneyIn3DInit and MoneyIn3DConfirm only.
Frictionless Payments
Frictionless payments are essential for a seamless, secure transaction process, and they play a key role in tackling the complexity and security concerns that accompany online payments. Frictionless payments aim to reduce the complexity and stress of the entire transaction process for you and your client. We encourage you to optimize frictionless payments with your clients by populating as much information.
Frictionless payment examples include one-click payments, contactless card transactions, and digital wallet solutions.
You will find these additional input fields in the following methods:
SOAP API v1
REST API v2
Input Reference Help
These fields are considered to have high importance for scoring (and thus bolstering both security and user experience), it is recommended that they be populated in the information that is available. The most important fields are ranked from R1 (being the most important) to R4.
Billing Address Object
Object | Field | Description | Priority |
---|---|---|---|
billingAddress | billingAddress.city | Billing address | R2 |
billingAddress.country | R2 | ||
billingAddress.addressAdditional1 | R2 | ||
billingAddress.addressAdditional2 | R2 | ||
billingAddress.addressAdditional3 | R2 | ||
billingAddress.zipcode | R2 | ||
billingAddress.state | R2 |
Holder Information
Object | Field | Description | Priority |
---|---|---|---|
holder | firstName | Holder contact information | R1 |
lastName | R1 | ||
R1 | |||
phone | R3 | ||
mobile | R3 | ||
workPhone | R3 |
Delivery Address Information
Object | Field | Description | Priority |
---|---|---|---|
deliveryAddress | deliveryAddress.city | Delivery address information | R1 |
deliveryAddress.country | R1 | ||
Address.addressAdditional1 | R1 | ||
deliveryAddress.addressAdditional2 | R1 | ||
deliveryAddress.addressAdditional3 | R1 | ||
deliveryAddress.zipcode | R1 | ||
deliveryAddress.state | R1 |
Delivery Address Additional Information
Object | Field | Description | Priority |
---|---|---|---|
deliveryAdditionalInfo | numberOfItemsBasket | The total quantity of all products in the basket | R2 |
addressDeliveryBillingMatchIndicator | Specifies whether the delivery and the billing addresses are the same | R2 | |
deliveryAddressCreationDate | The date on which the last delivery address used by the merchant's account was reported in the transaction | R2 | |
estimatedDeliveryDelay | Estimated Delivery Delay (in days) by the Merchant | R2 | |
deliveryMode | Delivery Method | R2 |
Holder Account Information
Object | Field | Description | Priority |
---|---|---|---|
customerAccountInfo | customerAccountInfo.customerAccountId | Additional information about the account is optionally provided by the 3D Secure Requestor. | R4 |
customerAccountInfo.numberOfPurchase180Days | The amount of customer transactions made over the last six months (last 180 days) | R4 | |
customerAccountInfo.numberOfTransactionYear | Number of accepted or abandoned transactions in the last year on the merchant's customer account. | R4 | |
customerAccountInfo.customerAccountCreationDate | When the customer account was originally created. | R4 | |
customerAccountInfo.numberOfAttemptsAddCard24Hours | Number of distinct cards the merchant's account used in the last 24 hours. | R4 | |
customerAccountInfo.suspiciousActivityIndicator | Notes if suspicious activity is detected on the customer account on the merchant's website. | R4 | |
customerAccountInfo.numberOfTransaction24Hours | How many transactions did the customer make in the last 24 hours | R4 | |
customerAccountInfo.customerAccountChangeDate | Last date the customer account was changed | R4 | |
customerAccountInfo.passwordChangeDate | Date of last change of password of the customer account | R4 | |
customerAccountInfo.addPaymentMeanDate | Date of last added form of payment made to account. For example, a new card registered to the account | R4 |
Authentication
Object | Field | Description | Priority |
---|---|---|---|
authentication | merchantCustomerAuthentMethod | NOAUTHENT = 1 - No authentication of the customer by the merchant | R2 |
OWNCREDENTIAL = 2 - Customer authentication by the merchant using his own system | |||
FEDERATEDID = 3 - Customer authentication by the merchant using an identifier federated(facebook, ...) (e.g.Facebook) | |||
ISSUERID = 4 - Customer authentication by the merchant using the information of the issuer's payment mean | |||
THIRDPARTY = 5 - Customer authentication by the merchant using the third system | |||
FIDO = 6 - Customer authentication by the merchant with FIDO(Fast IDentity Online) system | |||
merchantCustomerAuthentDateTime | ISO8601 date time format | R2 |
Updated about 1 month ago