PCI Watch

Tracking changes across the Payment Card Industry

EMV® 3-D Secure White Paper v1.0 - DRAFT - Disposition of Comments

Draft Specification
3-D Secure

Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV® 3-D Secure White Paper v1.0 – Draft Date: April 2024 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/ Table/Note Type of comment2 Comment (justification for change) EA 2.2.2 te MINOR In preconditions, consider adding something about consistency of merchant identification across Trust List enrolment and subsequent transactions. EA 2.2.2 Table 2.1 te Card Range Data entry could be more MINOR specific about version requirements. Proposed change Status (Accept, Reject, In progress) It is vital that merchants present the same merchant names and identifiers in subsequent transactions as were used when cardholders add a merchant to a Trust List, otherwise the ACS may not be able to properly exempt a transaction. Accept Clarify that the value 09 for Trust List Exemption Supported applies to 2.3.1 only. Accept EMVCo Use Only EMVCo observations on each comment submitted Note added to the preconditions: “The Merchant and/or 3DS Server should provide consistent merchant information (Merchant Name, 3DS Requestor Name, 3DS Requestor ID) across the Trust List enrolment and the subsequent transactions for the ACS to recognise the merchant.” Clarification added.

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 2.2.6 P23 te MAJOR For DS-managed Device Binding, no step to perform the actual device identification is defined. The sequence describes only that the AReq will be sent from the 3DS Server. This appears to be a standard AReq. Something needs to be added to explain (ideally) how, or minimally when the device identification by the DS actually occurs, as without confirming a device identification there is no basis for the DS to assert this is the bound device. This is a very tricky use case and I think it will be difficult to make it work in practice. Suggest omitting it at this revision until it can be better defined. Reject The following note has been added to the preconditions: “How the DS or ACS identifies the Consumer Device is outside the scope of the 3DS Specification.”

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 3.1 EA 3.1 te MAJOR ed Sentence is contradictory: “OOB authentication is known to be effective in preventing fraudulent attacks, especially in e-commerce, as OOB authentication protocols can be invalidated if the hacker uses a sophisticated method of intercepting messages on a wireless network.” Additional advantage of OOB authentication. There are many attack vectors to authentication challenges, including OOB. The most practical methods exploit the people as opposed to harder methods such as wireless network sniffing. Suggest to reword to: “OOB authentication is known to be effective in preventing fraudulent attacks, especially in e-commerce” so as not to undermine the efficacy of OOB in the white paper. In addition to control over the authentication methods etc., a key benefit is the ability to leverage consistent authentication across 3DS and non-3DS channels, e.g. online banking. Accept Accept Final part of the sentence has been revised to read: “OOB authentication is known to be effective in preventing fraudulent attacks, especially in e-commerce.” The following text has been added at the end of the paragraph: “Another key benefit is the ability to leverage consistent authentication methods across 3DS and other channels, e.g. online banking.”

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 3.2 te MAJOR Automated App-App transfer is only applicable when the merchant and OOB app are on the SAME DEVICE. This point is regularly (but not always) overlooked in OOB discussions and could be tweaked in a few instances on the following pages. The later section 3.5 is a good example of explaining this correctly. Reword to: “Automated App-to-App transfers between merchant and OOB apps on the same device”. Accept Sentence reworded as recommended. Same and different device scenarios create a lot of considerations when the use of app-app switching comes into play. If we assume, because the problems are too hard to solve, that the ACS, 3DS Requestor App, and OOB app have no knowledge of whether the 3DS Requestor and OOB apps are on the same or different devices, then default recommendations should be made about the UIs in the 3DS Requestor and OOB Apps displaying content for manual More thought on addressing same and different device scenarios, and associated recommendations, is recommended throughout sections 3.2-3.6. Accept Specific sections have been added to cover scenarios when automatic switching between the merchant app and the OOB Authentication App is not possible; when the apps are on different devices, or when the merchant or the ACS do not want to use automatic switching.

EA 3.2 Use Case Overview te MINOR switching instructions by default in all cases. That way if the automation works, great, and if it doesn’t (for example because the apps are on different devices), then it should fail silently leaving clear instructions for the cardholder on what to do. Issuer benefits: only one authentication method to deploy. Contradicts previous page. Proposed change The previous page explains that multiple authentication methods is an OOB benefit. The point here is not that it’s one method, but that it’s the ability to use authentication methods across 3DS and non-3DS channels. An issuer might offer a cardholder several types of OOB; app-based, tokenbased, etc. That is mainly an advantage if all those methods can be leveraged for 3DS and non-3DS. Status (Accept, Reject, In progress) Accept EMVCo Use Only EMVCo observations on each comment submitted Clarification added in Issuer benefits.

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 3.2 EA 3.3 Use Case Overview Flow 1 te MINOR te The bullets about whether the transaction and OOB app are on the same device, and the next bullet about app-app transitions, need to be “tightened up”. The flow does not include the RReq/RRes exchange, which is a critical difference with the next chapter 3.3.1 Suggest to combine the bullets into: “When the transaction is on the same device as the OOB Authentication App: whether the transaction is app or browser-based and whether the transitions between the 3DS Requestor checkout and OOB app are manual or automated.” Inclusion of the RReq/RRes message in the text and visual flows. This should also include the link between the user action on the confirmation page and the RReq/RRes trigger. Reject Accept Bullets are a clearer way to present all the factors that influence the OOB flow. Rather than presenting the 3DS flow in detail, the objective was to highlight the key steps relevant to OOB. For clarification and consistency with the different flows, the RReq/RRes messages have been added.

Proposed change EA 3.3 Sequence diagram explanation te Step 8 indicates that the cardholder clicks Adjust the diagram with the description. on “continue” and (step 9) the Final CREs is sent through the browser’s Iframe. On the sequence diagram below, there is outgoing connection from the ACS to the Merchant Server -> which is wrong and does not match with the description. EA 3.3.1 Browser ed The alternative flow is, arguably, the Consider positioning this as the preferred Channel preferable flow for the reasons stated. flow, either by switching the scenario order Alternative or strongly recommending this flow. Flow EA 3.3.1 Sequence te

, step 9: The ACS sends the results of the diagram The ACS sends the results of the authentication in the RReq message to the authentication in the RReq message to DS. the 3DS Server. EA 3.3.1 Sequence te 10. After receiving the RRes message 10.After receiving the RRes message from diagram from the 3DS Server… the 3DS Server, though the DS. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Diagram updated. Reject Accept The document presents the original flow as defined in the 3DS Specification, followed by the alternative flows. Description updated. Accept Description updated.

countries.

Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV® 3-D Secure White Paper v1.0 – Draft Date: April 2024 EA/Sub1 EA Clause No./ Subclause No. /Annex) Paragraph/ Figure/ Table/Note 3.3.1 Sequence diagram Type of comment2 te Comment (justification for change) Proposed change Status (Accept, Reject, In progress) “10. After receiving the RRes message from the 3DS Server, the ACS sends a Final CRes message through the iframe to the 3DS Requestor to indicate the end of the challenge and the outcome of the authentication.“ There is no chance for the ACS to send the final CRes through the 3DS Requestor’s iframe as there is no action (POST) from the cardholder (no “continue” button) to which the ACS can respond. ACS cannot send the Final CRes without cardholder (POST) action. Think of omitting the Final CRes in this case. Accept EMVCo Use Only EMVCo observations on each comment submitted Note added to clarify that if the iframe is still open, the Cardholder may select the “Complete” button and the ACS may send the Final CRes message through the iframe.

Proposed change EA 3.3.1 Sequence te Diagram, step 10 shows ACS sending Clarify diagram directly (in an outgoing connection) the Final CRes to the “Merchant Server”. Does this mean that the ACS should directly connect to the “notificationUrl” to send the final CRes? This goes against the core specification. Excerpt from

v2.3.1.1 “The CRes message is posted by the ACS through the Cardholder Browser at the end of the challenge” Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Diagram updated. The CRes arrow ends at the browser.

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 3.3 Sequence te Sections 3.3, 3.4, 3.5 and 3.6 contain We strongly recommend adding the Accept Rather than presenting the 3DS + 3.4 Diagram (steps + MAJOR scoomrrees‘pOoOndB tFoloEwMsV’ d3eDsScriopptieornastiownhiicnh RReq/RRes exchange or clarifying that the RReq/RRes messages exchange is always flow in detail, the objective was to highlight the key steps relevant to + 3.5 figure) Challenge. mandatory in the descriptions all the use OOB. + 3.6 But all these operations (except the cases in sections 3.3, 3.4 and 3.6 (before For clarification and consistency alternative proposed in subsection step 9). This would avoid misinterpretations with the different flows, the 3.3.1) are described with NO and potential implementation/interoperability RReq/RRes messages have been RReq/RRes exchange (for these Use issues (in the field, most merchant only rely added. Cases, the steps descriptions and on the Transaction Status in the RReq diagrams seem to indicate that the message to perform the payment operation is managed an AReq/ARes authorization – and the Transaction Status in exchange and then the ACS directly the Cres message is only used by the sends the final CRes after receiving the merchant to inform the Cardholder). OOB complete information – except in section 3.3.1, which is the only OOB flow Note: and if EMVCo wants to introduce new Challenge Use Cases with no RReq/RRes mentioning the RReq/RRes messages). exchange, we recommend adding a note to clearly This does not seem compliant with the basic EMV 3DS rule which defines that for each ARes with Transaction Status = C, indicate that this is intended and to clarify why EMVCo decided not to use the RReq/RRes exchange. the ACS shall send an RReq message (see Step 16 of Browser-Based flow in EMV 3DS specification + see Q/A n°31

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted and n°45 in the latest version of the EMV 3DS FAQ) EA 3.4 OOB Version 2.1 flow ed 3DS Version 2.1 end of life is imminent. Consider removing this section as it will soon Accept be redundant. The Version 2.1 section has been deleted. EA 3.4 + 3.5 + 3.6 te MAJOR Section 3.3.1 introduces of a ‘Browser Channel – Alternative OOB Flow’ to clarify that the ACS does not need to wait for the authentication completion information from the Cardholder (“Complete” button) before sending the results of the authentication in the RReq message during a BrowserBased operation (which seems very positive). But the fact that this use case example is described only for Browser-Based in the WP could be misinterpreted as ‘not applicable to App-Based’ (even if the end of step 17 of the ‘Challenge Flow with OOB Authentication Requirement’ defined Please, add the description of an “OOB Flow: Version 2.1, 2.2 and 2.3 – App Channel – Alternative OOB Flow’ to clarify that, during any App-Based Challenge with OOB authentication, if the ACS knows the result of the OOB authentication before the Cardholder switches to the 3DS Requestor App, then the ACS does not need to wait for the “OOB complete” information from the 3D SDK before sending the results of the authentication in the RReq message to the 3DS Server. Note: at least, please clarify that the alternative flow (and particularly the Note) defined in section Accept RReq and RRes have been added for consistency between the different flows. Clarification has been added stating that the ACS may send the RReq before receiving the “OOB complete” information from the 3DS SDK if it knows the result of the OOB authentication.

Proposed change EA 3.5.1 te MAJOR in section 3.2 of the EMV 3DS ‘Core’ spec. already indicates that the ACS may apply step 18 as soon as it has access to the result of the OOB authentication in AppBased). Flow doesn’t work as described. When the App Link back to the 3DS Requestor App doesn’t work, the OS may open the browser, but it may also take other actions, depending on why it doesn’t work, such as opening the device’s app store. The text assumes the 3DS Requestor can “provide a landing page to display to the cardholder” but this is not a valid assumption. For example the 3DS Requestor App may just be on another device. Instead it should be specified that the OOB App detects, and handles this condition. 3.5.2 expresses this better. 3.3.1 of the WP also applies to App-Based operations (whatever the protocol version). This seems very important if we want to improve the success rate of App-Based Challenge operations. It’s actually the OOB App that should detect and handle this condition by displaying content to the cardholder to instruct them to return to the 3DS Requestor App. Align the description with 3.5.2. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept The OS handles the Universal App Link. It may open the URL on the browser if it cannot find a match for a 3DS Requestor App or report the error to the 3DS Requestor App. A note has been added to clarify that the OOB Authentication App needs to interpret the error returned by the OS and be able to display the instructions to the Cardholder.

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 3.5.1 + 3.5.2 + 3.6.1 + 3.6.2 te MAJOR It seems that the flows described in sections ‘3.5.1 Technical Variant: Version 2.2 – the 3DS Requestor App URL Is Incorrect’ and ‘3.5.2 Technical Variant: Version 2.2 – the 3DS Requestor App URL Is Invalid or Is Based on a Custom Device Operating System’ are also applicable to EMV 3DS v2.3.1 operations. And it seems that the flows described in sections ‘3.6.1 Technical Variant: Version 2.3 – the OOB App URL Is Incorrect’ and ‘3.6.2 Technical Variant: Version 2.3 – the OOB App URL Is Invalid or Is Based on a Custom Device Operating System’ are also applicable to EMV 3DS ‘v2.2 + Bridging Message Extension’ operations. Clarify in the WP that the flows described in sections 3.5.1 et 3.5.2 also apply to EMV 3DS v2.3.1 operations. And clarify in the WP that the flows described in sections 3.6.1 et 3.6.2 also apply to EMV 3DS v2.2 operations if the Bridging Message Extension is supported. Accept To clarify the different cases for the App flow, three App flows have been explained:

  • No automatic switching
  • Automatic switching to the 3DS Requestor App
  • Automatic switching to the OOB App with the applicable specification version. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 3.5.2 Second ed In the second note, it is assumed that the Eliminate the ACS in the 2nd note to keep the Accept The note has been updated. note ACS IS the OOB App. OOB app as the only instigator of the display The OOB Authentication App needs In practice, the ACS is never the OOB action. to interpret the error returned by the app, these are 2 separate components Device Operating System and be and providers. able to display the instructions to Therefore, the ACS cannot display in the the Cardholder. OOB app, the OOB app does so on its own. EA 3.5.2 te MINOR ACS is assumed to have responsibility to display failed 3DS Requestor App activation instructions to the cardholder when the App Link will not open. In an OOB transaction it may not be (likely will not be actually) the ACS that interacts with the cardholder, it’s the OOB service. The ACS may, or may not, be providing the authentication service to the OOB App. Remove the “Note: The ACS needs to support….” Line as it’s correctly explained in the previous line. Accept The note has been updated. The OOB Authentication App needs to interpret the error returned by the Device Operating System and be able to display the instructions to the Cardholder. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 3.5.2 EA 3.6.1 ed Section 3.5.2 is a redundant scenario after Consider merging 3.5.1 and 3.5.2 into one Reject considering the changes above. scenario. te MINOR OOB App URL incorrect variant: more likely scenario is that the reason the OOB App URL doesn’t work is because the OOB and 3DS Requestor Apps are on different devices. It may also be that the OOB App just isn’t installed. Retitle this scenario to be the OOB and 3DS Requestor Apps on different devices as opposed to supposing the OOB App link “doesn’t work”. Each similar earlier section can then be structured this way: into scenario (a) being apps on same device and (b) being apps on different devices. Accept Also merge 3.6.1 and 3.6.2 as they are not really different. The OS handles the Universal App Link. It may open the URL on the browser if it cannot find a match for a 3DS Requestor App or report the error to App. Refer to the definition of the Universal App Link for details for Android and iOS, and different error scenarios. To clarify the different cases for the App flow, there are 3 flows:
  • No automatic switching
  • Automatic switching to 3DS Requestor App
  • Automatic switching to OOB App Refer to the definition of the Universal App Link for details for Android and iOS, and different error scenarios. Proposed change EA 3.6.1 User te Title: “Technical Variant: Version 2.3 – the Consider changing the title to” Technical Experienc OOB App URL Is Incorrect” Variant: Version 2.3 – the OS cannot match e “incorrect” is wrong term, as this is a the OOB App URL to an installed App” correct URL but the operating system (due to internal factors) cannot resolve it to an application. Therefore, the ACS renders a landing page on this (correct) URL to instruct the cardholder for the further steps. EA 3.6.2 Second te In the second flow of 6 steps, in step 3, is Additional details on the error sent from the flow indicated that the 3DS SDK sends an error 3DS SDK to the ACS. to the ACS if the URL cannot be resolved by the OS. How is this error sent ? Additional details on this error are needed. Erro message cannot be expected with a subsequent Cres from the ACS. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Updated title:

3.6.1 Technical Variant – the Device Operating System Cannot Match the OOB App URL to an Installed App Accept Clarification added: “The 3DS SDK indicates the error to the ACS in the CReq message using OOB App Status (01) and OOB Continuation Indicator (02).”

Proposed change EA 3.6.2 ed In section 3.6.2, two user experience flows Merge both flows to have a single detailed are described while they seem to flow. correspond to the same sequence (the 1st flow describes only 4 steps when the 2nd flow describes 6 steps, but each step of the 1st flow seems more detailed) Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Reject The user experience is different depending on the error and whether it is the ACS or the OOB Authentication App that provides the error message to the Cardholder.

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 4.2 Table 4.1 te MAJOR It seems that the White Paper does not explain how to proceed recurring/installed operations when the Bridging Message Extension is not supported during an EMV 3DS v2.1.0 and v2.2.0 operation. Note: while this is the most common case on the field currently (at least, in France). Particularly, in Table 4.1 ‘3DS Data Elements Related to Recurring and Instalment Transactions’, the data elements Recurring Expiry and Recurring Frequency are defined as applicable only in the EMV 3DS v2.3.1 protocol or using the Bridging Message Extension. This is probably explained by the fact that these data elements cannot be “ignored” by the ACS when the Bridging Message Extension is not supported in v2.1.0 and v2.2.0, but this does not seem compliant with the ‘Core’ specification which define these 2 data elements for v2.1.0 and v2.2.0. Add some guidelines to propose some management rules and some instructions to be provided to the Cardholder when initializing a recurring/instalment transaction in v2.1.0 and v2.2.0 without the Bridging Message Extension (e.g. the WP could clarify that the Recuring Expiry should not be displayed to the cardholder as it is not possible to know if it is accurate depending on the use case in v2.1.0 or v2.2.0 without ‘Bridging’). If EMVCo decide not to cover these cases, we recommend adding some explanations to clearly indicate this decision and to clarify why the Recurring Expiry and Recurring Frequency data elements are defined as applicable only in the EMV 3DS v2.3.1 or with the Bridging Message Extension in the table. In progress The next release of the White Paper will have a dedicated section on the Bridging Message Extension. Where applicable, a clarification has been added stating that the feature is possible with 3DS v2.3.1 or v2.2 + Bridging Message Extension.

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 4.3.9 te MAJOR In section 2.3.9 ‘Best Practices for Defining Recurring Periods’, it has been decided to add 1 to the maximum number of days in a calendar interval to define the values which shall be interpreted as calendar intervals (e.g. maximum of days in a month = 31  32 is used to indicate ‘monthly’). But in the specification (and Bridging Message Extension), the reccuringFrequency is defined as the minimum number of days between authorisations. And therefore, it seems that using values which are greater than the “maximum of days withing the calendar interval” may induce some issue if the recurringFrequency is verified by the ACS/Issuer when processing the subsequent authentications and/or authorisation. Also, if not correctly interpreted by the ACS, it could lead to “incorrect” messages to the cardholder (e.g. indication that he will be charged We strongly recommend using the minimum number of days in a calendar interval to designate this calendar interval (as this will permit to always provide “correct” instructions to the cardholder, and also to be compliant with the definition of the recurringFrequency in the ‘Core’ spec., and with any potential checks implemented by the ACS or Issuer). Proposal [preferred solution in bold]: Recurring Freq. Issuer Messaging 7 Every Week / Weekly 14 Biweekly 28 Every month / Monthly 59 Bimonthly 89 Quarterly 181 Twice a year 365 Every year / Annually Accept The section has been updated and now takes into account the proposed calendar interval definition.

EA 4.3.9 te minor every 32 days (or more), while he may be charged after 28 days in February…). In section 2.3.9 ‘Best Practices for Defining Recurring Periods’, some values are defined to indicate the following calendar intervals = weekly, biweekly, monthly, bimonthly, twice a year, and annualy. But the Quarterly interval is not covered/defined while it is a common calendar interval for some recurring payments (at least, in the French market). Proposed change Please, add a specific value to be interpreted as “Every 3 month / Quarterly” in section 4.3.9 (e.g. ‘‘89’ with our above recommendation or 92’ using the proposal in 1st Draft of the WP). Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept The quarterly calendar interval has been added.

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 4 EA 4 4.3.3 4.3.6 te minor te minor In the EMV 3DS Specification (and in the Bridging Message Extension addendum) the recurring frequency is defined as the minimum number of days between authorisations. But the recurring/instalment use cases defined in the WP seem to recommend that the ACS consider this frequency as ‘fixed’ (i.e. all examples are indicating “[…] every XX days […]”) It seems that the definitions of the 2 Recurring use cases ‘Use Case 2’ and ‘Use Case 5’ are identical (same sequence, same steps, …). Systematically replace “[…] every XX days […]” by “[…] every XX days (or more) […]” in the WP examples. Note: else, clarify in the ‘Core’ specifications (or Spec. Bulletins) that the Recurring Frequency corresponds to the “number of days between authorisation” (and not the “minimum number of days between authorisations” as currently indicated). In order to simplify the document and to ease the understanding, we propose to merge both identical use cases ‘Use Case 2’ and ‘Use Case 5’ into a single use case (proposal = “Recurring Payment with a Fixed Amount, Fixed Frequency, and with a Promotial Rate or a One-Time Purchase”). Else, we recommend adding some clarifications to precise the differences between the 2 use cases. Accept Reject The examples have been updated with “every XX days (or more)”. The use cases are relevant from a Merchant’s point of view.

Proposed change EA 4.3.5 Use case 4 te In 4.3.3, the assumption made in this Unacceptable scenario for an issuer stand whitepaper is that if the purchaseAmount point. is different from the recurringAmount, it acts as a first payment amount. For this, this becomes very dangerous. If the subsequent amounts are unknown it means that a merchant can change and most importantly increase the subsequent amounts. This is a very obvious big risk of abuse and source of cardholder refund quests if they end up paying more (or much more) than initially agreed upon. The idea is to have issuer liability on these: let’s say the initial amount is 5,00 USD, and then variable amount. If the next payment is 1000,00 USD and the issuer has liability, the message stating that it’s the merchant setting the rules is useless. In this case, the issuer would have to use a technical rule in the ACS either rejecting Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted In progress The following note has been added: “Payment systems may impose additional requirements on the use of recurring data or may set limits such as a maximum amount.” A new data element – Maximum Amount – is envisaged for the next specification version.

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted the CIT in this scenario or all subsequent MIT if the amount increases… EA 4.3.7 Use case 6 te Same comment as for 4.3.5, but on the varying frequency In progress The following note has been added: “Payment systems may impose additional requirements on the use of these data or may set limits such as a maximum transaction per recurring period.” EA 4.3.8 Use case 7 te The assumption made is that the purchaseAmount is the amount of the first payment. With the associated message, it means it’s up to the cardholder to calculate themselves the total amount: Initial amount + recurringAmount*nb_instalments The cardholder cannot be the one to make the calculation, the purschaseAmount should be the total amount the user will In progress The following note has been added: “Payment systems may impose different requirements on the use of these data. For example, they may require that the total amount (€2595.99) be provided in the Purchase Amount.” A new data element – Total Amount – is envisaged for the next specification version.

pay. This is already what is used by Mastercard for instance. Also, the recurringInd, as per 3DS v2.3.1 specification, applies to both recurring and instalment transactions. We believe that the usecases are lacking the scenarios where the merchant can set variable amount and variable frequency. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted

Proposed change EA 4.3.9 Best practices te The definition of recurringFrequency in the Deletion of the translation of frequencies. 2.3.1 specification indicates that this is “the minimum number of days between authorisations for a recurring or instalment transaction.” With this specification details, one cannot transform an amount into a sentence. If the recurringFrequency is 30, it does not mean every month. It means every or more. Furthermore, some values are incorrect. For instance, 32 is associated with every month. So if it’s within February, the ACS will receive an MIT within 28 days and decline the MIT because it’s lower than 32. Same goes for the year that is set to 367. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted In progress The section has been updated and now includes a new calendar interval definition and recommendation for the 3DS Requestor and ACS. Recurring Frequency value 7 14 28 59 89 181 365 Issuer messaging Every week Biweekly Every month Bimonthly Quarterly Twice a year Annually

Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 4.2 EA 4.3.6 Table 4.1 Table Ed The table lists the data element ‘3DS Replace ‘3DS Requestor Prior DS Accept Requestor Prior DS Transaction ID’ while Transaction ID’ by ‘3DS Requestor Prior DS this data element is not defined in the Transaction Reference’. EMV 3DS Specification (v2.3.1). The provided definition corresponds to the ‘3DS Requestor Prior DS Transaction Reference’ Ed In the Merchant/Acquirer column, it is indicated “Recurring Amount = 7.98” To be replaced by “Recurring Amount = 798” Accept Corrected Corrected

countries.