> In order to perform this we share basic user details with them only for the purpose of performing this check, and on the basis of this check the provider will either agree or decline to offer the credit.
> How does the payments provider know if the customer has an outstanding balance? They use the customer’s email address.
> [...] Unfortunately this is completely ineffective for the pay-later scenario, which depends on being able to correlate user accounts.
I'm finding it hard that an organisation that is capable of doing a credit check on me (which doesn't rely on my email address) is unable to account for multiple debts without using my email address.
Infact, if they are only using my email address, that is absurd, as one email address != one person.
> Services that use dynamic domains (for example thread.foobar.com) will be unable to authenticate all of their domains.
Services that use dynamic domains (for example thread.youjustgotphished.com) will be unable to be authenticated by end users as being legitimate. Dont do it.
> Best practice for email deliverability suggests that senders should send from a different domain per category of email that they send8. This mostly applies to larger products, but 10 domains is too limiting.
Because our industry is rampant with spam, we have created new ways to try and bypass spam filters. Nope, go away.
> In the EU where GDPR restricts what companies may do with customer data, this leaves Apple’s SSO providing little to no benefit over what is already required by law.
Another layer of protection against companies that fail to abide by the law (and companies that wilfully neglect their obligations under the law) is more valuable than "little to no benefit" to end users.
Sorry to be really blunt, but these are just the highlights. As an end user, all I have for [the retailer] is a tiny violin. Retailers at large have demonstrated a fundamental lack of respect for end users. Apple's service looks like it lacks respect for the new-norms that retailers have adopted.
I get that you don't like spam. Neither do I! I'm very keen on anything to reduce this.
What we're talking about here is not spam. We're talking about transactional email that a user wants. I know that when we fail to send order dispatch emails users shout "Scam!" because it looks like we've taken their money without doing anything. I know that users like being able to pick up their order at a local store (with a security code). I know that users like to be able to pay with a range of payment options.
We're not talking about marketing here, we're talking about the minimum of communication for a user to feel that they can trust a retailer.
Yes the industry abuses email, but these examples are not that.
As for the credit check, email is certainly not the only signal they use, but in the typical case it's an easy one to check that can provide high signal. I don't want to speak for the service provider, but this sounds like one good approach to me.
> Apple's service looks like it lacks respect for the new-norms that retailers have adopted.
Apple's service makes it impossible for retailers who respect users privacy and marketing preferences to operate the core of their business.
Thank you for taking the time to reply. Appreciate it.
> I get that you don't like spam. Neither do I! I'm very keen on anything to reduce this. What we're talking about here is not spam ... We're not talking about marketing here ... Yes the industry abuses email, but these examples are not that.
> Apple's service makes it impossible for retailers who respect users privacy and marketing preferences to operate the core of their business.
Unfortunately, while that may be true of your business, it's not true of others. You know the saying about bad apples spoiling barrels, right?
In the case of any legitimate email from third parties, your business can now be the relay for those emails. Instead of @ emailing me about a purchase from legitimateretailer.com, moving forward only *@legitimateretailer.com (and up to 9 more domains...) can email me about that purchase. And on top of that, legitimateretailer.com is required to do the bare minimum to try and reduce spoofing off their domain. Ideally DKIM and DMARC would be mandatory as well, and not just SPF!
For it to be any different, Apple would need to certify every partner in the chain used by any retailer. Every time a new partner is engaged, Apple would need to be notified and that partner certified. That seems even more onerous.
> As for the credit check, email is certainly not the only signal they use, but in the typical case it's an easy one to check that can provide high signal
KYC requirements in financial businesses are pretty strict. If losing this signal is a problem for your business, you're probably violating regulatory requirements. See previous remarks about value provided & legal requirements.
> How does the payments provider know if the customer has an outstanding balance? They use the customer’s email address.
> [...] Unfortunately this is completely ineffective for the pay-later scenario, which depends on being able to correlate user accounts.
I'm finding it hard that an organisation that is capable of doing a credit check on me (which doesn't rely on my email address) is unable to account for multiple debts without using my email address.
Infact, if they are only using my email address, that is absurd, as one email address != one person.
> Services that use dynamic domains (for example thread.foobar.com) will be unable to authenticate all of their domains.
Services that use dynamic domains (for example thread.youjustgotphished.com) will be unable to be authenticated by end users as being legitimate. Dont do it.
> Best practice for email deliverability suggests that senders should send from a different domain per category of email that they send8. This mostly applies to larger products, but 10 domains is too limiting.
Because our industry is rampant with spam, we have created new ways to try and bypass spam filters. Nope, go away.
> In the EU where GDPR restricts what companies may do with customer data, this leaves Apple’s SSO providing little to no benefit over what is already required by law.
Another layer of protection against companies that fail to abide by the law (and companies that wilfully neglect their obligations under the law) is more valuable than "little to no benefit" to end users.
Sorry to be really blunt, but these are just the highlights. As an end user, all I have for [the retailer] is a tiny violin. Retailers at large have demonstrated a fundamental lack of respect for end users. Apple's service looks like it lacks respect for the new-norms that retailers have adopted.
Good.