The following use cases illustrate the technical capabilities of 3DS with recurring data elements and cover the most common types of recurring or instalment transactions. Payment systems may impose additional requirements on the use of recurring data, including for the purposes of ensuring compliance with market regulations.
With version 2.2 of the 3DS Specification, the Merchant has a limited set of data available to provide to the ACS about a recurring or instalment transaction. For example, the Merchant cannot indicate if the recurring transaction has a variable amount, or if the instalment amount is different from the initial amount (purchase amount).
Presented below are example use cases for recurring or instalment transactions in version 2.2:
In this use case, the amount due at recurring payment set-up is the same amount that will be due on a recurring basis. In the example below, the Cardholder is committing to pay €8.99 monthly, starting on the day of the purchase and ending on 15 October 2024.
Merchant/Acquirer | Issuer | Cardholder |
|---|---|---|
Existing recurring data elements
| Determines that a Cardholder challenge is necessary and builds the message with the recurring payment information. Message is displayed to the Cardholder in the 3DS challenge window. |
|
An instalment payment is a payment made over time according to a pre-agreed schedule for goods and services that have been fully delivered or performed.
One example is the purchase for a total of €999.99, to be paid in 4 instalments (i.e., 3 times €300.00 each month after the first payment of €99.99), with the first payment occurring on the day of the purchase. The merchant cannot provide information on the different amounts between the first payment and the 3 successive instalment payments. Similarly, if anything else is purchased at the same time as the instalment set up, the amount of that purchase would be added to the purchase amount with the first installment payment
Merchant/Acquirer | Issuer | Carholder |
|---|---|---|
Existing recurring data elements
| Determines that a Cardholder challenge is necessary and builds the message with the recurring payment information. Message is displayed to the Cardholder in the 3DS challenge window. |
|
With version 2.3.1 of the 3DS Specification, the Merchant has a large set of data available to provide to the ACS about a recurring or instalment transaction. For example, the Merchant can indicate if the recurring transaction has a variable amount, or if the recurring amount is different from the initial amount (purchase amount).
The use cases are also possible with version 2.2 of the 3DS Specification if the Bridging Message Extension with a Recurring Data object is present and supported by the ACS and the 3DS Server:
In this scenario, the amount due at recurring payment set-up is the amount that will be due on a recurring basis. Use Case 2 covers the scenario when the two amounts differ.
In the example below, the Cardholder is committing to pay €7.99 monthly, starting on the day of the purchase and ending on 15 October 2024.
Merchant/Acquirer | Issuer | Cardholder |
|---|---|---|
Existing recurring data elements
Additional elements
| Determines that a Cardholder challenge is necessary and builds the message with the recurring payment information. Message is displayed to the Cardholder in the 3DS challenge window. |
|
A rate is considered promotional when the amount to be paid at set-up is not the same as the amount to be paid on an ongoing basis. In the case of an ongoing subscription of €7.99/month, the data listed below need to be provided.
If the first month is free:
If there is a 50% discount:
If there is no promotional rate and the €7.99 is also due on the day of the purchase, refer to Use Case 1: Recurring Payment with a Fixed Amount and a Fixed Frequency.
In the example below, the first month is free, the recurring amount is €7.99, and there is no end date provided. When there is no end date, there is no need to (and it is recommended not to) convey this information.
Merchant/Acquirer | Issuer | Cardholder |
|---|---|---|
Existing recurring data elements
Additional elements
| Determines that a Cardholder challenge is necessary and builds the message with the recurring payment information. Message is displayed to the Cardholder in the 3DS challenge window. |
|
In the case of a recurring payment with a variable amount, the method of calculating the amount is typically communicated in the Merchant’s terms and conditions of the recurring payment set- up. For example, in the case of an electricity bill, a Merchant will typically inform the Cardholder that the amount to be charged will depend on usage and will be calculated on display €x per kW of usage.
It is recommended that Issuers find a generic way to convey the meaning of “variable amount” by using terms such as “of an amount calculated as per the terms and conditions previously displayed by the merchant”. When there is no end date, there is no need to (and it is recommended not to) convey this information.
The example below shows data provided when the Merchant has required a payment of €85 on the day of the purchase (considered the average monthly payment) and payment on usage every month starting one month after that date.
Merchant/Acquirer | Issuer | Cardholder |
|---|---|---|
Existing recurring data elements
Additional elements
| Determines that a Cardholder challenge is necessary and builds the message with the recurring payment information. Message is displayed to the Cardholder in the 3DS challenge window. |
|
In the case of a recurring payment with a:
For example, in the case of a payment to be collected by a highway operator when the Cardholder’s transponder is used on a highway, the operator informs the Cardholder that a payment will be charged at the end of the day, every time the highway is used on that day, for an amount based on the distance driven.
It is recommended that Issuers find a generic way to convey the meaning of “variable amount” and “variable frequency” to Cardholders by using terms such as:
When both amount and frequency are variable, Issuers should try to avoid displaying the wording “described in the terms and conditions previously described by the merchant” twice, for example, as per the image below.
Note: Payment systems may impose additional requirements on the use of recurring data or may set limits such as a maximum amount.
Merchant/Acquirer | Issuer | Cardholder |
|---|---|---|
Existing recurring data elements
Additional elements
| Determines that a Cardholder challenge is necessary and builds the message with the recurring payment information. Message is displayed to the Cardholder in the 3DS challenge window. |
|
In the case of payments with a variable frequency, the event that will trigger a charge/payment is typically described to the Cardholder in the Merchant’s terms and conditions of the recurring payment set-up.
For example, in the case of a payment to be collected by a transit operator that provides prepaid transit cards, the triggering event could be the transit card balance falling below an amount set by the Cardholder or set by the operator and communicated to the Cardholder.
The terms and conditions set forth by the operator may state, for example, that a reload of €30.00 will occur when the transit card balance falls below €15.00.
In the example below, at set-up, the card is loaded with €30 and a reload of €30 will occur when the balance falls below €15.00.
Note: Payment systems may impose additional requirements on the use of these data or may set limits such as a maximum transaction per recurring period.
Merchant/Acquirer | Issuer | Cardholder |
|---|---|---|
Existing recurring data elements
Additional elements
| Determines that a Cardholder challenge is necessary and builds the message with the recurring payment information. Message is displayed to the Cardholder in the 3DS challenge window. |  |
In every use case, the amount to be sent in the purchase amount is the amount the Cardholder must pay on the day of the authentication. This will include:
The amounts and frequency to be provided in the recurring data amount and frequency should follow the principles set forth in Use Cases 1–5.
For example, if the one-time purchase has a value of €42.89 and the fixed recurring payment is free for the first month and payable only in the second month (see example below), then the purchase amount should be sent as €42.89. If 50% of the recurring amount is due on the day of the purchase (€3.99), in addition to the purchase of €42.89, the amount to be sent in the purchase amount would be €46.88 (sum of €42.89 and €3.99).
Merchant/Acquirer | Issuer | Cardholder |
|---|---|---|
Existing recurring data elements
Additional Elements
| Determines that a Cardholder challenge is necessary and builds the message with the recurring payment information. Message is displayed to the Cardholder in the 3DS challenge window. |  |
An instalment payment is a payment made over time according to a pre-agreed schedule for goods and services that have been fully delivered or performed.
One example is the purchase of a sofa for a total of €2595.99, to be paid in 6 instalments (i.e. €432.66 each after the first payment of €432.69), with the first payment occurring on the day of the purchase. As the first instalment is paid on the day of the purchase, only 5 instalments remain. The value provided in the Instalment Payment Data corresponds to the maximum number of authorisations permitted for instalment payments (6 in this example).
If any other purchase was made at the same time as the instalment set-up, the amount of that purchase would be added to the purchase amount with the first instalment payment, following the principles set forth in Use Case 6.
Note: 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.
Merchant/Acquirer | Issuer | Cardholder |
|---|---|---|
Existing recurring data elements
Additional elements
| Determines that a Cardholder challenge is necessary and builds the message with the recurring payment information. Message is displayed to the Cardholder in the 3DS challenge window. |  |
The Recurring Frequency data element defines the minimum number of days between authorisations. This is a limitation, as Merchants often charge on a fixed interval basis – not necessarily based on the number of days but on a calendar interval (week, month, quarter…).
It is recommended that Merchants use the Recurring Frequency values indicated in the table below to ensure that the Issuer’s message is expressed as a calendar interval rather than a number of days. Issuers receiving those Recurring Frequency values should use the corresponding calendar intervals to display recurring transaction information to Cardholders.
Recurring Frequency value | Issuer messaging |
|---|---|
7 | Every Week |
14 | Biweekly |
28 | Every Month |
59 | Bimonthly |
89 | Quarterly |
181 | Twice a year |
365 | Annually |
For example, for a Recurring Frequency of 28 days, the ACS should interpret the frequency as a monthly payment and provide the following message to the Cardholder:
“You are authorising payment to [Merchant abc] every month”.
If the ACS does not interpret the 28 days as a monthly payment, it may provide the following message to the Cardholder:
“You are authorising payment to [Merchant abc] every 28 days (or more)”.
Last Updated: April 17, 2020
Welcome to EMVCo. By accessing or using the EMVCo website at www.emvco.com (“Site“) or any Site Materials, whether or not you obtained them via the Site, you agree to the following Terms of Use on behalf of yourself individually and the company or organization for which you are using the Site or Site Materials (“Organization“). If you do not agree to the following Terms of Use, do not use the Site or other Site Materials.
In these Terms of Use, “Site Materials” means all email messages sent to you by EMVCo in connection with your registration on the Site or participation in an EMVCo participation program, and all content, files and other materials that are available for viewing or download on the Site, including the EMV® Specifications, requirements, guidelines, white papers or other documents, APIs, SDKs, software, scripts, code, trademarks, videos, text, graphics, pictures, information, and other materials.
You represent that either (a) you are an authorized representative of your Organization with authority to bind your Organization to these Terms of Use, in which case the term “you” refers collectively to both you individually and your Organization, or (b) you are not authorized to bind any Organization to these Terms of Use and are using the Site or Site Materials solely in your personal capacity, in which case the term “you” refers to you individually. EMVCo, LLC (“EMVCo“) reserves the right to modify or replace these Terms of Use at any time and in EMVCo’s sole discretion.
EMVCo will indicate at the top of these Terms of Use the date such document was last updated. Any changes will be effective immediately upon posting the revised version on the Site (or such later effective date as may be indicated at the top of the revised Terms of Use). Your continued use of the Site or Site Materials following the posting of any changes to these Terms of Use will constitute your acceptance of such changes. If you do not agree to the changes, you must stop using the Site and Site Materials. In addition, EMVCo may provide other methods by which you may accept or receive notice of these Terms of Use or changes to these Terms of Use.
In these Terms of Use, “EMV Products” means products or services that are designed to comply with the EMV Specifications. The foregoing license applies retroactively to include activities prior to the date you agreed to these Terms of Use, but is granted solely under the intellectual property rights that EMVCo owns or has the right to license. To the extent the foregoing license includes rights to a third party’s patents, the license is limited to those patents or patent claims that would be necessarily infringed by an entity implementing the mandatory or optional requirements of the EMV Specifications.
And after the cover page of each copy of a translation, the following (or a substantially similar notice) must be printed:
Notwithstanding the foregoing, the Public Documents may be subject to a separate agreement you may have with EMVCo or to supplemental terms and conditions that are included in or accompany Public Documents, in which case you agree that such separate agreement or supplemental terms and conditions will apply to your use of the Public Documents. Any use of the Site or Site Materials other than as specifically authorized herein (or in such separate agreement or supplemental terms and conditions) is strictly prohibited and will automatically terminate the foregoing license without notice.
EMVCo's new website and Participant Dashboard are now live. To access your account for the first time on our new website you'll need to carry out a password reset here. You will then be sent an email to reset your password.
EMVCo Associates, Subscribers and public users of emvco.com can create accounts to manage their engagement and participation with EMVCo. Using your EMVCo account, you can create your own watchlist of EMV technologies documents, monitor queries and responses, and manage your profile.
