The Card schemes, or more specifically the EMVCo are highly interested in providing secure Credit Card payments, in same time not jeopardizing the Customer experience and keeping the payment conversion rates high. If the Customer tries to pay with his Credit Card and he is not able to, it is most desirable that the Customer is informed about the reasons, so that he can correct what is required from his side.
Issuers can use a text field (cardholder Information Text) in EMV 3DS to provide additional information to cardholders when an authentication request can not be completed, for example:
→ “This transaction has been declined due to security reasons. For further details please contact number at the back of card.”
→ “Your transaction has not been processed. Please call us on 555-1234 so we can help you.”
It provides a valuable opportunity for issuers to tell cardholders why their payment can not proceed and guide them to the necessary corrective action
Currently, it is optional for Merchants to display this text to cardholders in EMV 3DS 2.1 but becomes mandatory in EMV 3DS 2.2.
It is always optional for Issuers to use it (unless using Decoupled Authentication – 2.2 Only).
PAYONE built an EMV 3DS Service that does not require merchants to implement any changes to their existing integrations, while ensuring full compliance to minimum data requirements for authentication requests as stipulated by the card schemes.
However, relying on the current implementation will lead to an uptick in challenges during checkouts. This can affect your conversion rate negatively. Therefore, we've implemented additional and optional parameters you can send to our Server API in order to take advantage of 3D Secure's exemption management.
If you want to optimize your conversion rate, here's what you have to do:
If you are connected with PAYONE via Server APIRequired parameters are already implemented in the PAYONE Server API. The more information you can supply per transaction, the greater the chance to proceed frictionless since there is more information provided to the transaction risk assessment of the issuer. Therefore, additional optional data can be provided to your payment requests. We recommend enlarging the parameters added to the authentication requests by the end of 2020. |
If you are connected with PAYONE via Shop-PluginPlease update regularly to ensure you use the latest version of our plugin and provide optional request parameters as we optimize our plugins for better conversion. |
Not sure if 3D Secure is active for you?Please contact your sales contact or our merchant service to ensure your merchant account is configured for 3DS. |
3-D Secure is a technology to increase safety for credit card payments on the Internet for both dealers as well as for customers. It is used in order to authenticate a buyer during the payment process and to reduce the risk of a chargeback.
Visa calls this procedure "Verified by Visa", MasterCard "MasterCard SecureCode", American Express "Safekey" and Diners/Discover "Protect Buy".
The PSD2 states that all payment transactions must be processed with strong customer authentication as far as there are no excemptions.
That means that all credit card transactions will have to be handled with 3-D Secure - which can be 3-D Secure 1 or 3-D Secure 2 (EMV 3-DS) on the issuer side.
If you have already activated 3-D Secure in your merchant settings the PAYONE platform will be able to handle both varying processes for you: 3-D Secure 1 or 3-D Secure 2. This depends on the credit card and its issuer and if it is allowed to process with 3-D Secure 1 or 2.
Please be aware that credit card transactions may be declined by your acquirer or the issuer if they are not processed with 3-D Secure at all.
In the case of 3-D Secure, virtually every payment transaction must be authorized by the end customer if the end customer has registered for the 3-D Secure procedure and the card-issuing bank participates in the procedure. Therefore the customer is forwarded to a website of the card-issuing bank, where the 3-D Secure password must be entered.
The disadvantage of this method is that the customers often do not complete the authorization and thus have prematurely terminated the purchase process.
3-D Secure 2 was introduced by the EMVCo and leading credit card companies to facilitate the customer's payment process by offering up-to-date authentication methods such as biometric procedures.
In addition, 3-D Secure 2 provides exemptions in order to bypass this authentication if certain conditions are met and proceed frictionless. In that case additional data, such as device data, can be transmitted and used to decide whether authentication by means of 3-D Secure is required. Transactions that are subject to higher risk or that have to comply with more stringent specifications (such as PSD2) can also be assigned to the authentication process.
PAYONE provides a landing page, which determines the necessary device data of the browser and makes them accessible to the ACS. As a result, no adjustments are required on by the merchant or the shop (other than stay updated on the latest shop-plug in version.
This sequence diagram shows the new workflow, which first asks whether 3-D Secure 2 is supported by the issuer. If not, then the 3-D Secure 1 workflow is triggered.
If 3-D Secure 2 is supported, device data from the browser will be determined and sent to the issuer along with the transaction data, which may agree to a frictionless process. In this case, the transaction is processed with 3-D Secure, without the customer having to enter his 3-D Secure credentials or to approve the transaction via his banking-app.
If the issuer asks for a "challenge" - so the customer must be prompted to enter their 3-D Secure Credentials - a redirect to a browser page is created that includes the issuer page for entering the 3-D Secure credentials.
We have made all technical adjustments for the integration of 3-D Secure 2 for you. If you have already secured your credit card payments using the 3-DS procedure, you can now benefit from these advantages without restriction: They are thus ideally positioned for the PSD2 and the challenges of the future.
Please contact us immediately if you do not yet use the 3-DS procedure: In this case, there is a risk of payment defaults from 14 September 2019 onwards.
Further options will follow for seamless integration into shop systems via browser and app.
Positive test cases with credit cards
These credit card numbers (PAN) will simulate successful payment transactions. As processing is identical for all credit card types a test with a single type is sufficient.
Note on CVC and expiry date
The expiry date should always be a date in the future.
The CVV/CVC can be any combination of 3 digits, except where stated otherwise
Card type | Card number (PAN) | Comments |
---|---|---|
V (VISA) | 4111111111111111 | if BIN-Country-Check is activated this card will only be accepted for BIN-Country = DE |
V (VISA) | 4111121011111111 | if BIN-Country-Check is activated this card will only be accepted for BIN-Country = AT |
V (VISA) | 4111131010111111 | if BIN-Country-Check is activated this card will only be accepted for BIN-Country = CH |
V (VISA) | 4111141011111111116 | PAN with 19 digits |
M (Mastercard) |
5500000000000004 2720990000000015 |
PAN with new BIN range |
A (American Express) |
340000000000009 370000000000002 |
CVC must be 4 digits (e.g. "1234") |
J (JCB) |
3528000000000007 |
|
O (Maestro International) | Please see TD - Credit card with 3-D secure 1.0 / 2.0 since Maestro only works with 3D Secure | |
D (Diners Club) | 30000000000004 | |
D (Discover) | 6011111111111117 | |
Unknown | 11111111111111116 | This PAN will not be detected automatically and will return API errorcode 875 |
Requests with credit cards resulting in response type “INVALID” and defined error code. For technical reasons all credit card numbers will result in “INVALID” and a given error code. The API may respond with “ERROR” instead of “INVALID” in some times – however the error code remains the same.
TEST PAN |
TEST PseudoCard |
Error code |
Description |
---|---|---|---|
4301111100000101 |
9410009000000000102 |
1 |
Card Issuer temporarily not available |
4301111100000200 |
9410009000000000201 |
2 |
Authorization declined |
4301111100000408 |
9410009000000000409 |
4 |
Retain card |
4301111100000507 |
9410009000000000508 |
5 |
Authorization declined |
4301111100000705 |
9410009000000000706 |
7 |
CVC2/CVV2 mandatory, but not transmitted or invalid |
4301111100001208 |
9410009000000001209 |
12 |
Transaction invalid |
4301111100001307 |
9410009000000001308 |
13 |
Limit exceeded |
4301111100001406 |
9410009000000001407 |
14 |
Invalid Card |
4301111100003006 |
9410009000000003007 |
30 |
Format Error in request message (e.g. CVC missing). |
4301111100003105 |
9410009000000003106 |
31 |
Card type invalid |
4301111100003402 |
9410009000000003403 |
34 |
Suspicion of Manipulation |
4301111100004301 |
9410009000000004302 |
43 |
Stolen Card |
4222222200005100 | 51 | Limit exceeded or account balance insufficient | |
4222222200005506 |
|
55 |
Incorrect secret code |
4301111100005605 |
9410009000000005606 |
56 |
Unknown Card |
4222222200005704 |
|
57 |
Cancelation: Wrong card has been used as for original authorization |
4222222200005803 |
|
58 |
Terminal ID unknown |
4222222200006009 |
|
60 |
Card acceptor must contact the acquirer |
4222222200006108 | 61 | Card blocked | |
4301111100006207 |
9410009000000006208 |
62 |
Restricted Card |
4222222200006306 |
|
63 |
Card is not allowed. Card is blocked. |
4222222200006405 |
|
64 |
Transaction amount is different from authorization. |
4222222200006504 | 65 | Card has been used too often | |
4301111100009102 |
9410009000000009103 |
91 |
Card issuer temporarily not reachable |
4301111100070104 |
9410009000000070105 |
701 |
Payment rejected by the BIN-Check |
4301111100070203 |
9410009000000070204 |
702 |
Payment rejected due to the BIN-Country |
4301111100072209 |
9410009000000072200 |
722 |
Payment rejected by the Velocity-Cardpan-Check |
4301111100073207 |
9410009000000073208 |
732 |
Payment rejected by the Blacklist-Cardpan-Check |
CreditCardCheck currently never does any communication to the acquirer. So these return codes will currently not happen in live mode and will only be detected with authorization / preauthorization.
These amounts will result in failed transactions with status "ERROR" - independent from PAN / PPAN to simulate special use cases.
amount | PAN / PPAN | Error code | Description |
---|---|---|---|
10051 | any | 51 | Limit exceeded or account balance insufficient |
10055 | any | 55 | Incorrect secret code |
10057 | any | 57 | Cancelation: Wrong card has been used as for original authorization |
10058 | any | 58 | Terminal ID unknown |
10060 | any | 60 | Card acceptor must contact the acquirer |
10061 | any | 61 | Card blocked |
10063 | any | 63 | Card is not allowed. Card is blocked. |
10064 | any | 64 | Transaction amount is different from authorization |
10065 | any | 65 | Card has been used too often |
10902 | any | 902 | Unknown error with external service provider |
Test cases with credit cards
Since 3-D Secure v1 will no longer be accepted from October 2022, test credit cards will only work with 3-D Secure v2. Please see available cards for 3-D Secure v2 below.
These credit card numbers (PAN) will simulate successful payment transactions for cards taking part in 3-D Secure. The processing is again identical for all credit card types. A test with a single type is sufficient.
Transaction Status Notification details: Parameter for the TransactionStatus query - Platform - PAYONE docs
Note on Password, CVC and expiry date:
3-D Secure works with redirects - so the URLs for redirect / processing need to be set:
V (VISA) Verified by VISA |
M (Mastercard) MasterCard SecureCode |
A (American Express) Safekey |
Maestro | Comments |
---|---|---|---|---|
|
|
|
||
4716971940353559 | 5404127720739582 | 375144726036141 |
Process with 3-D Secure 2.0
|
|
4532993462191243 | 5227248189915672 | 343111216781956 |
Process with 3-D Secure 2.0
|
|
4499510096392186 | 5535343773242596 | 374309404465067 |
Process with 3-D Secure 2.0
|
The Card schemes, or more specifically the EMVCo are highly interested in providing secure Credit Card payments, in same time not jeopardizing the Customer experience and keeping the payment conversion rates high. If the Customer tries to pay with his Credit Card and he is not able to, it is most desirable that the Customer is informed about the reasons, so that he can correct what is required from his side.
Issuers can use a text field (Cardholder Information Text) in EMV 3DS to provide additional information to cardholders when an authentication request can not be completed, for example:
→ “This transaction has been declined due to security reasons. For further details please contact number at the back of card.”
→ “Your transaction has not been processed. Please call us on 555-1234 so we can help you”
It provides a valuable opportunity for issuers to tell cardholders why their payment can not proceed and guide them to the necessary corrective action
Currently, it is optional for Merchants to display this text to cardholders in EMV 3DS 2.1 but becomes mandatory in EMV 3DS 2.2.
It is always optional for Issuers to use it (unless using Decoupled Authentication – 2.2 Only).
Transaction Status Notification details: Parameter for the TransactionStatus query - Platform - PAYONE docs
Visa | Master | AMEX | Use Case | Cardholder_info |
---|---|---|---|---|
4532993462191243 |
5227248189915672 |
343111216781956 |
Process with 3-D Secure 2.0 *No challenge, auth accepted ("frictionless") |
"Für künftige Zahlungen registrieren Sie Ihre Karte bitte auf unserer Webseite. Ihre Zahlung wurde erfolgreich abgeschlossen" |
4499510096392186 |
5535343773242596 |
374309404465067 |
Process with 3-D Secure 2.0No challenge, auth declined ("frictionless") |
“Your transaction has not been processed. Please call us on 555-1234 so we can help you" |