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?

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
  1. Use Initiate a Web Payment API v2 or Initiate a Web Payment API v1.

📘 Register a card

*Optional. To make future payments on the card, set registerCard=1 (APIv1) or registerCard=true (APIv2)

Payments with a Registered Card
  1. Use Get Card Information API v2 or Check if Card is Registered API v1 to confirm the end-user's card is registered.
  2. 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
  1. 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) or registerCard=1 (APIv1).
  2. Use Charge a Registered Card API v2 or Charge a Registered Card API v2 (APIv1) for all subsequent equal amounts payments.
Payments Upon Delivery
  1. 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.
  2. To guarantee the payment, use Capture a Deferred Payment API v2 or Capture a Deferred Payment API v2.
  3. 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
  1. Use API v1 moneyin3dinit or API v2 moneyins_direct3dinitpost to initiate the payment.
  2. To enable future payments on the card, set the registerCard=1 (API v1) or registerCard=true (API v2).
2. Authentication
  1. The card owner will be authenticated with 3-D Secure.
  2. After the end-user has authenticated, call MoneyIn3DAuthenticate (API v1) or POST /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).
3. Finalize Payment
  • Finally, call MoneyIn3DConfirm (API v1) or PUT /moneyins/card/direct/{transactionid}/3dconfirm (API v2) to complete the payment.
Payments with a Registered Card 1. Check Card Registration and Initialize Payment
  1. First, call the GetCard (APIv1) or Get /v2/moneyins/card/{cardId} (APIv2) method to ensure that the end-user's card is registered.
  2. If the end-user's card is registered, then call the MoneyIn3DInit (APIv1) or POST /moneyins/card/direct/3dinit (APIv2) method.
2. Authentication
  1. The card owner will be authenticated with 3-D Secure.
  2. After the end-user has been authenticated, you should call MoneyIn3DAuthenticate (APIv1) or POST /moneyins/card/direct/{transactionid}/3dauthenticate (APIv2) to check the status of 3D Secure Authentication after receiving a callback from the Payment Service Provider (PSP).
3. Finalize Payment
  • Finally, call MoneyIn3DConfirm (APIv1) or PUT /moneyins/card/direct/{transactionid}/3dconfirm (APIv2) to finalize the payment.
Subscriptions with Equal Recurring Amounts 1. Initial Subscription Payment
  1. For the initial subscription payment, use MoneyIn3DInit (APIv1) or POST /moneyins/card/direct/3dinit (APIv2).
  2. Then, use MoneyIn3DAuthenticate(APIv1) or POST /moneyins/card/direct/{transactionid}/3dauthenticate (APIv2).
2. Confirm Payment
  • Use MoneyIn3DConfirm (APIv1) or PUT /moneyins/card/direct/{transactionid}/3dconfirm (APIv2) as explained below.
3. Subsequent Payments
  • Use MoneyInWithCardID (APIv1) or POST /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
email 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