Deprecate non-tokenized MPO

[ct-clearhaus]

No description provided.

[mt-clearhaus]

There are some quirks to be ironed out, and I'm a bit puzzled over Hugo's behaviour ...

[mt-clearhaus]

@Lassejoe Are you able to quickly see what is going on here? Why e.g. [:json:] will not stay on the same line as mobilepayonline[payment_token]?

[Lassejoe]

should be fixed now by f0a8dff

[mt-clearhaus]

@Lassejoe 🙏 🙇

[tjconcept]

I asked MobilePay earlier this year if we could deprecate non-tokens, but they were pretty clear that especially Finnish cards were not tokenized, but in general they still have non-tokenized ones around. Do you have a more recent communiqué?

[ct-clearhaus]

I asked MobilePay earlier this year if we could deprecate non-tokens, but they were pretty clear that especially Finnish cards were not tokenized, but in general they still have non-tokenized ones around. Do you have a more recent communiqué?

I haven't heard from MPO on this recently, but I also haven't seen any exemption on the fees from Mastercard for Finland so I wonder how this should work out.

[tjconcept]

We're still seeing use of this from MobilePay (I suppose you have that insight too), so I'm going to ask them once more. I'll keep you posted.

[ct-clearhaus]

We're still seeing use of this from MobilePay (I suppose you have that insight too), so I'm going to ask them once more.

I can confirm.

I would like to deprecate non-tokenized MPO for multiple reasons, but the intention is to steer integrators towards the tokenized version as the primary and most important — to make sure tokenized is considered primary and non-tokenized is considered fallback (much like when 3DSv2 took over from 3DSv1). However, there are a few details that are unclear to me, so I'll likely end up "just" hinting this with text for now — which is indeed a much weaker statement — and leave this PR as an indication that it'll likely be coming (as opposed to indicating that the change is coming) 🙂

[tjconcept]

the intention is to steer integrators towards the tokenized version

I actually don't think this is necessary. From our integration and communication with MobilePay, we have no say in this matter and simply act upon whether MobilePay ships us one or the other. Both are mandated for integrators to support. I specifically requested to skip the non-tokenized one but got rejected.
From experience it does seem like MobilePay prefers the tokenized version, as we are seeing non-tokenized versions appearing for instance after several failed attempts with tokenized ones.

steer integrators towards the tokenized version

This is how I normally understand "deprecated" (more like "discouraged/better exists"), so in that sense, I'd personally go right ahead and deprecate it. However, if you use the word differently, it would be awesome with some kind of statement as to "how urgently" we need to address these as they currently, at least theoretically, pose a serious and unknown risk to us.

[tjconcept]

MobilePay replied suggesting us to respond to them with a "hard block" reason code once you remove support. In that case, I'd consider us in compliance with their mandate "to support".