SPC for Recurring payments

[ianbjacobs]

What changes would be needed in SPC to support recurring payment use cases (e.g., display and signing of terms such as recurrence period or number of transactions)?

It would be good to hear from people whether they think standardized browser UX is appropriate for this situation, or whether the details of recurring payments would make standardization difficult.

[ianbjacobs]

cc @stare893

[SensibleWood]

Typical details of a recurring payment - using a standing order from UK open banking as an example - are:

• A first payment amount.
• A final payment amount.
• Date of first payment.
• Frequency (in the reference this is codified according to a pattern set in the OpenAPI document).
• Number of payments.

The UK standing order example also purposefully ignores T&Cs as they are set elsewhere.

In terms of a standardized UX I think this is "doable", with the caveat this would make for a crowded confirmation screen given the amount of information to convey. T&Cs - where not already covered in existing agreements - would most likely need to live elsewhere.

It's also worth noting that "variable recurring payments" has become a thing relatively recently in the UK standards - https://openbankinguk.github.io/read-write-api-site3/v3.1.10/profiles/vrp-profile.html - and as such "could" be initiated using SPC. This, however is more likely to reflect a non-payment authentication experience as is discussed in #186.

[ianbjacobs]

Note for future discussion: support both recurrences (with differing parameters potentially varying) and installment payments.

[stare893]

Discussion note from EMV 3DSWG discussion with Ian on Mar-23, Not supporting/accommodating recurring payments/installment transaction/free trial use cases in SPC API is a potential blocker for adoption. When issuers will be presented with any of the above mentioned scenarios, they may be forced to not use SPC as currently the SPC UX can not show the user the necessary information about their payment amount, frequency and what amount the users may be authenticating for. EMV 3DS spec has been revised to accommodate these use-cases and this issue reflects the same need for SPC API.

[gpk00]

When issuers will be presented with any of the above mentioned scenarios, they may be forced to not use SPC as currently the SPC UX can not show the user the necessary information about their payment amount, frequency and what amount the users may be authenticating for

I don't think this is a dealbreaker for card transactions and would not consider a blocker nor must have:

1. I don't recall seeing many issuers actually rendering the information made available by merchants on AReq.recurringFrequency and AReq.recurringExpiry on challenge screens
2. Users will always have the ability to dispute these transactions for non-fraud reasons if they believe the merchant did something wrong.
3. Also, given the recurring transactions don't actually carry liability shift, users can actually dispute them for fraud reason as well

[adrianhopebailie]

Some comments based on the discussion in the WG meeting on 27 March:

Phased Approach

Recurring payments can be very complex and it will be very challenging to codify all possible models and scenarios. Experience has shown that trying to codify complex arrangements (e.g. trial periods) can cause confusion with customers and worsen the user experience.

There is always a tension between UX and security/risk/legal compliance. SPC is just a tool that can be used by merchants to solve for security/risk/compliance challenges where they consider the UX change a fair compromise. SPC won't become the ONLY checkout mechanism for some time (if ever).

If we undertake this work we should approach it in phases and handle simple cases first such as subscriptions and instalments.

SPC = Signed Electronic Mandate

SPC provides a means to get a signed attestation from the customer that they have consented to future payments being debit from their account.

The long term goal should be for this "electronic mandate" to be accepted by payment schemes as a basis for liability shift as this will drive adoption.

For payment schemes where only "push" payments are possible the SPC generated mandate may be a critical piece to enabling e-commerce. Many push-based schemes leverage a "payment request" flow to support use cases like e-commerce that traditionally use pull-based payment methods.

Today payment requests don't work for recurring payments as they require the customer to approve the payment each time after receiving the request. However, a payment request submitted along with an SPC-generated mandate MAY be auto-approved without requiring user interaction.

[stare893]

When issuers will be presented with any of the above mentioned scenarios, they may be forced to not use SPC as currently the SPC UX can not show the user the necessary information about their payment amount, frequency and what amount the users may be authenticating for

I don't think this is a dealbreaker for card transactions and would not consider a blocker nor must have:

1. I don't recall seeing many issuers actually rendering the information made available by merchants on AReq.recurringFrequency and AReq.recurringExpiry on challenge screens
2. Users will always have the ability to dispute these transactions for non-fraud reasons if they believe the merchant did something wrong.
3. Also, given the recurring transactions don't actually carry liability shift, users can actually dispute them for fraud reason as well

The feedback EMVCo has received from European Regulators does paint a landscape where the issuers will be (in time) required to present the the necessary information to the cardholders when they are being authenticated using 3DS. This issue is not about the ability to fight fraud or dispute but making sure the cardholders are fully informed at the time of authentication. The blocker mentioned earlier is related to adoption. With the additional knowledge built regarding recurring transactions in EMV 3DS , merchants and issuers will have more insight into what kinds of transaction is being authenticated and they may lean towards using an authentication method (example issuer's i-frame displaying the break-down of the transaction with OTP/Other authentication method) that gets the cardholders most clarity. The issuers not using the recurring fields today should change over-time with recurring transactions becoming more prevalent and more focus from regulators on these type of transactions.