Didn’t Twitter have that problem with the self replicating tweet? 
Edit:
4 Likes
Also, we will soon have different wording depending on the action you are trying to approve:
- adding a card to your mobile wallet (or when the merchant wants to store your card details)
- approving a recurring payment
Any suggestions on those? 
4 Likes
Am reminded that there’s an xkcd comic for everything:
6 Likes
I would always say that consistency is key, but maintaining the “After” case with its plain English also great
“Open your Monzo app to approve adding your card”
“Open your Monzo app to approve storing your details”
As per “After” case, but just inserting “recurring”
We are thinking of using the word “subscription”, as it’s a bit simpler to understand
2 Likes
100% down with that if it is suitably accurate for the cases in question
So this would mean, for example, entering my card details for Netflix would in future trigger a 3DS2 challenge needing app approval?
Late next year, when ecommerce Strong Customer Authentication is enforced, we will have to decline transactions which don’t go through 3DS.
Recurring payments are a slight exemption where the first payment in the recurring chain (ie. the very first time you setup your Netflix subscription) needs to go through 3DS. All subsequent payments can go through without it
2 Likes
So the wording I am discussing here is what to show the user when they are setting up the first payment of a recurring chain
1 Like
Curve actually supports this. If you add your Monzo card to Curve, you will go through our new 3DS flow
2 Likes
I think “recurring payment” is better since that is a term on its own, which is consistently used by others to refer to this type of payment.
I also think it conveys the automatic nature of the next payment better than the word “subscription” would do, since people might assume that manual intervention is required, or that they would at least get a clear chance to avoid another payment, before the “subscription” renews - and of course this isn’t the case with recurring payments, the default is totally automatic renewal.
2 Likes
Agree with @SebH.
Could the relevant word monthly/quarterly/annual be inserted in front of the word “recurring“ to make it clearer?
1 Like
I wonder if this is possible? Good idea if it is, but it would require data from the merchant on how often the payment is set to recur, and I’m not sure Monzo do normally get that.
Just to add as well, I’m all for keeping language as simple as possible in order to ensure it’s easy to understand, but the one case I think this shouldn’t be done in is where simplifying the language would replace a highly specific, unambiguous term with a more general term, since this adds ambiguity and, sort of paradoxically, risks actually making it more difficult to understand what the message is.
At least if you don’t know what a specific word means, you could look it up, whereas a whole sentence written in overly-general terms could be confusing in meaning with no way to work out what is meant on your own.
I hope Monzo do bear this in mind when deciding on language like this.
2 Likes
Could you post the current examples?
1 Like
They can actually provide that information on the 3DS challenge, but it’s not enforced and they don’t need to strictly obey the “promised frequency” they told us… So we won’t be displaying the frequency right now.
If in the future we notice merchants are behaving, we may display it
3 Likes
Yep. We have to keep it simple and consistent with our brand. Also, our mission is to “make money work for everyone”. It wouldn’t be friendly to everyone if we used complex words (like we may be doing now).
We actually have to pass all of this through our Writing team, who are professionals specifically on “nice wording” (I’m sure there is a better definition for their title…)
4 Likes
Will keep you posted… 
Totally agree, thanks for replying, and I think what you are doing around trying to make sure customers easily understand all of your wording is very admirable.
Just to clarify, I didn’t mean you should be using complex words for the sake of it, just that a balance has to be struck and it may not always be appropriate to simply language to its fullest extent (although I am aware it’s difficult and I don’t think my normal writing would be likely to pass the “simplicity test” unedited)!
My personal opinion is that where an industry term may not be totally simple, yet is also not that difficult to understand for probably most people, I think it would be best to favour the industry standard term rather than try to simplify it further - since this would introduce a further unfamiliar term to describe the same thing that many customers may already be familiar with.
I hope that makes sense, and I’m sure your expert team already has thought about these sorts of things, and they are obviously better placed to make a decision on what’s appropriate than I am!
Anyway, thanks again and I appreciate the opportunity to have some input! I hope you find my ideas helpful in your decision making in some small way.
4 Likes
You do realise 3DS(2) most likely isn’t PSD2/SCA compliant right? What are your backup options??
Are you sure current card not present solutions hold all the required answers for e-commerce come PSD2/SCA?
Why isn’t 3DS2 SCA compliant?
Our current solutions for card-not present are not PSD2 compliant, although we can make them complaint at any point by declining ecommerce transactions which don’t go through SCA. We are already ready for this, but most merchants/acquirers out there are not and we don’t want to mass decline. I’m actually in talks with Google to start a gradual rollout with them as a merchant.
If you are really interested on the SCA regulation, here is our point of reference on the opinion of the European Banking Authority (EBA): https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32018R0389&from=EN
2 Likes
My job is translating that legal document into code 
3 Likes