Equívocos sobre como o Apple Pay funciona
(birchtree.me)- A estrutura que oculta o número real do cartão não é um recurso exclusivo do Apple Pay; é um método de pagamento usado também pelas principais carteiras digitais, como Google Pay e Samsung Pay
- O ponto central é a separação entre o FPAN, que é o número do cartão físico, e o DPAN, que é o número de pagamento específico do dispositivo; mesmo com o mesmo cartão, iPhone e iPad usam DPANs diferentes
- O DPAN pode dificultar o rastreamento entre diferentes lojistas, mas dentro do mesmo lojista ele é mantido em transações posteriores, então não impede o rastreamento do histórico de compras por um único lojista
- Em caso de vazamento de dados de pagamento, o DPAN é mais seguro que o FPAN, e só funciona quando enviado junto com um pacote criptográfico exclusivo anexado a cada transação
- O Apple Pay não oculta automaticamente informações pessoais como nome, e-mail, endereço de cobrança ou entrega, nem os itens comprados; deve-se assumir que as informações exibidas na tela de pagamento são repassadas ao lojista
DPAN não é um recurso exclusivo do Apple Pay
- Quando se diz que o Apple Pay esconde o número real do cartão de crédito, o ponto central é o DPAN
- FPAN é o funding primary account number de 15 a 18 dígitos impresso no cartão físico, e DPAN é o device primary account number
- O DPAN pode ser entendido de forma parecida com um registro DNS
- O usuário acessa um site por um nome de domínio sem precisar saber o endereço IP real
- Mesmo com o mesmo cartão, se você usar o Apple Pay no iPhone e no iPad, cada dispositivo recebe um número próprio e usa um DPAN diferente
- É importante notar que o nome não é “Apple Pay number”
- Google Pay e Samsung Pay, como grandes carteiras digitais dos EUA, também ocultam o número real do cartão da mesma forma
- Os botões Amazon Pay e Shop Pay também fazem o pagamento passar por outra empresa, então tecnicamente não são DPAN, mas ainda assim impedem que o lojista veja o FPAN real
Lojistas e bancos também querem reduzir a exposição do número real do cartão
- Quando o lojista processa diretamente o número real do cartão de crédito, a exposição ao risco aumenta
- Ferramentas modernas de aceitação de pagamentos coletam as informações de pagamento de modo a reduzir ao máximo a quantidade de pessoas com acesso aos dados reais do cartão
- A suposição de que bancos não usariam DPAN não bate com os casos reais
- Wells Fargo, Chase, Bank of America e vários outros bancos operaram ou operam suas próprias carteiras digitais, todas protegendo o número normal da conta com DPAN
- O Paze, usado por grandes bancos dos EUA, também utiliza DPAN
- Um dos principais argumentos do Paze é: “Paze does not share your actual card number with the merchant.”
O que o DPAN impede de rastrear e o que não impede
- Não é correto dizer que o DPAN muda a cada transação
- Em transações sucessivas com o mesmo lojista, o mesmo DPAN é usado
- Essa estrutura pode criar uma barreira para corretores de dados que compram dados de transações de vários lojistas para mapear os hábitos de compra de uma pessoa
- Por outro lado, um único lojista ainda consegue ver o histórico de transações daquele cliente apenas com o DPAN fornecido pelo Apple Pay
- O Apple Pay não impede situações como o caso em que a Target inferiu o estado de clientes com base no próprio histórico de compras
- Outras carteiras digitais têm a mesma limitação
A proteção que o DPAN oferece em caso de vazamento de dados
- Em situações de vazamento de dados de cartão de pagamento, o DPAN é mais seguro que o FPAN
- Em 2024, um lojista não deveria estar lidando diretamente com números de cartão de crédito, mas ainda pode haver casos em que um gateway de pagamento seja invadido e o DPAN com a data de validade vaze
- Um invasor não consegue fazer pagamentos apenas com o DPAN vazado
- O DPAN só funciona quando é enviado como parte de um pacote criptográfico exclusivo de cada transação
- Existem formas de executar cobranças recorrentes com cartões capturados via Apple Pay, mas isso não é algo que um hacker deveria conseguir fazer
- Por isso, um vazamento de FPAN é muito mais perigoso do que um vazamento de DPAN coletado por carteiras digitais
O Apple Pay não oculta automaticamente informações pessoais
- A ideia de que o Apple Pay mascara automaticamente informações pessoais não corresponde aos fatos
- Ao executar uma transação real com Apple Pay em uma conta de lojista de teste, relatórios no nível do lojista exibem informações como nome, e-mail, endereço de cobrança e endereço residencial
- Em pagamentos de produtos físicos, as informações de entrega são necessárias, então o SDK do Apple Pay permite que o lojista escolha quais dados pessoais deseja solicitar ao cliente
- As informações do produto também são enviadas ao Apple Pay para que o comprador veja o que está comprando, e essas informações também são repassadas ao lojista
- Deve-se assumir que as informações exibidas no cartão do Apple Pay durante o pagamento são repassadas ao lojista
- Nesse ponto, o Apple Pay é igual a outras formas de pagamento
- O lojista escolhe e solicita, no checkout, as informações pessoais que precisa ou deseja
- Outras carteiras digitais funcionam da mesma forma
A proteção que as carteiras digitais realmente oferecem
- O Apple Pay é um bom meio de pagamento, e a Apple teve um papel em popularizar esse tipo de carteira digital
- Ainda assim, os recursos do Apple Pay não são exclusivos no setor
- O DPAN é útil para dificultar o rastreamento das compras de uma pessoa entre vários lojistas e para reduzir o risco ao cliente em caso de vazamento de dados de cartão de pagamento
1 comentários
Comentários do Hacker News
Gostaria de entender, em termos ELI5, como o Apple Pay e o Google Pay realmente funcionam. Antes eu achava que eles simplesmente repassavam as informações do cartão ao comerciante ou ao processador de pagamentos, e o texto original também parece sugerir algo parecido, mas já vi alguns comerciantes recusarem pagamentos quando uso Amex no Google Pay, diferentemente de quando uso MasterCard
Às vezes parece que Apple/Google atuam como se fossem o processador de pagamentos ou até o próprio meio de pagamento. Isso porque elas coletam dados de transações e porque os terminais de supermercado também pareciam precisar de suporte especial para os apps Apple/Google Pay
Então fico curioso sobre qual é o segredo proprietário da Apple/Google, e por que seria difícil ou impossível substituí-lo por uma alternativa open source. Será porque, no iOS/Android, só Apple/Google têm acesso completo ao chip NFC?
https://news.ycombinator.com/item?id=39845805
O importante são os padrões. Só pode haver uma carteira Visa ou Mastercard padrão por dispositivo, e leva vantagem aquela que não exige abrir um app separado antes de encostar. Como o Google Pay dá suporte a cartões de vários bancos, ele tem uma grande vantagem em relação à carteira HCE de um banco emissor específico
Apple/Google participam como intermediárias quando um novo cartão é registrado em um dispositivo específico, mas não entram no fluxo real da transação no POS
O comerciante ainda precisa aceitar a bandeira do cartão subjacente. As versões modernas do Google Pay e do Apple Pay não são cartões proxy que trocam a bandeira do cartão, e são diferentes de serviços como Curve
Terminais offline não precisam de suporte separado. Desde que o terminal não tenha bugs, funciona onde a rede de cartões subjacente é aceita. Os protocolos físico e lógico são os mesmos de um cartão plástico e, do ponto de vista do terminal, quase não há diferença
Na web é diferente. O site da loja e o provedor de serviços de pagamento precisam oferecer suporte explícito
Por isso, em geral os terminais sem fio simplesmente aceitavam Apple Pay e Google Pay, sem precisar de muito suporte especial. Uma das mudanças, se bem me lembro, foi que esses dispositivos passaram a ser considerados mais seguros, então o limite de pagamento ficou mais alto do que o dos cartões contactless
O motivo de uma implementação open source ser difícil é que implementar EMV é complexo e exige muitos testes e validações com equipamentos especializados. O dispositivo precisa de uma área segura para armazenar chaves privadas com segurança, e o app precisa conseguir garantir a segurança do usuário confirmando que foi usada autenticação biométrica ou desbloqueio por PIN
Além disso, durante a configuração, é preciso integrar-se ao backend do banco emissor do cartão para receber as chaves e informações necessárias. Uma implementação open source provavelmente também teria de fechar contratos com bancos e passar por validação em laboratório por entidades como a UL
Apple Pay, Google Pay e apps de pagamento fornecidos por bancos confirmam a autorização do titular do cartão por biometria, transformando alguns pagamentos em “portador do cartão presente”
Com isso, alguns tipos de chargeback são recusados imediatamente, e em outros tipos a exigência de comprovação por parte do comerciante fica menor
Isso faz parte dos padrões das redes de cartões e, se tiver interesse, você pode ver em https://www.emvco.com/
O motivo de não haver opção open source é que é necessário certificar a segurança da implementação, então é preciso uma entidade comercial para trabalhar com os bancos. Além disso, é preciso integrar separadamente com cada banco, e há bancos demais para lidar
Fazer uma transação ponta a ponta funcionar corretamente em todas as bandeiras, todos os métodos de pagamento e todos os dispositivos é algo bastante complicado. Cada rede de cartões tem parâmetros de “kernel de pagamento” e requisitos de certificação diferentes
Ou pode ser uma tentativa de economizar em taxas de transação. A Amex geralmente é muito mais cara para o comerciante
https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...
Quando o Apple Pay começou a ser amplamente usado, eu o examinei com bastante detalhe com base na minha experiência em processamento de pagamentos no varejo. O que mais me impressionou na época foi o quanto ele estava profundamente enraizado em padrões do setor
Nenhuma parte depois da comunicação sem fio era exclusiva da Apple e, lendo este artigo, parece que isso continua assim até hoje
Lembro que, na época, alguns comerciantes que aceitavam tap-to-pay baseado em cartão de propósito tiveram que mudar seus sistemas quando acabaram aceitando, sem querer, o tap-to-pay bastante padronizado da Apple. A CVS me vem especialmente à cabeça; acho que ela participava de um sistema de pagamento concorrente e queria usar o fato de esse sistema funcionar nas lojas como um diferencial em relação ao Apple Pay
Quando recentemente começou a surgir o mito de que “isso só o Apple Pay faz”, fiquei me perguntando se algo havia mudado desde a última vez que eu tinha olhado; por isso, foi bom ver o autor fazer uma revisão atualizada nesse contexto
Mesmo sem suporte oficial, foi bem surpreendente ver que o Apple Pay funcionava em qualquer lugar na Austrália. Nos EUA, pouquíssimos comerciantes davam suporte, mas na Austrália, por ser baseado em padrões, 99% dos POS já eram compatíveis
O estado confuso dos pagamentos no Android também contribuiu. Samsung Pay podia significar NFC ou emulação de tarja magnética. O Google é famoso por não saber fazer branding e, entre várias iterações de Wallet e Google Pay, ainda é difícil entender o que é o quê
Um ponto que fica de fora dessas discussões é que transações feitas com carteiras como Apple Pay, Google Pay e Samsung Pay hoje são tão rastreáveis quanto transações feitas com o número do cartão subjacente
O DPAN é único para um dispositivo específico, mas hoje o provedor de serviços de pagamento do comerciante pode receber, na resposta de autorização da rede de cartões, um identificador único chamado PAR. Esse identificador é o mesmo em todos os DPANs do mesmo cartão e tem como objetivo permanecer o mesmo para a mesma conta básica mesmo que o número do cartão mude
Como o comerciante não consegue fazer cobranças usando o PAR, isso não é um problema de segurança, mas não se deve esperar que pagamentos por carteiras digitais sejam mais privados do que pagamentos com cartão comum ou número de cartão
https://wcapra.com/payment-account-reference-capraplus-your-...
https://www.securetechalliance.org/wp-content/uploads/EMVCo-...
O artigo de Matt Birchler adicionou um parágrafo dizendo: “uma versão anterior dizia que o DPAN mudava para cada comerciante, mas isso foi um erro. Escrevi com pressa demais, culpa minha”. Porém o restante do artigo ainda parece partir da ideia de que existe um DPAN único por comerciante, e não consigo encontrar base para isso
A própria documentação da Apple https://support.apple.com/en-us/HT203027 também diz que o DPAN, chamado ali de Device Account Number, é único apenas por dispositivo. Quando um cartão é adicionado ao Apple Pay, o DPAN daquele dispositivo é criado e, a menos que você remova o cartão e o adicione novamente, ele não muda depois disso
Portanto, se você usa o mesmo cartão em dois dispositivos, como iPhone e Apple Watch, os DPANs são diferentes e isso dificulta o rastreamento; mas, se usar o mesmo cartão no mesmo dispositivo em vários comerciantes, acredito que data brokers consigam rastrear
Não entendo por que SSO e pagamentos móveis não são interfaces padrão nas quais qualquer um possa criar um provedor. Em vez de “Login with Google” ou “Login with Apple”, não deveria haver um “entrar com meu provedor de SSO padrão”? O mesmo vale para “pagar com meu provedor de pagamento padrão”
Pior ainda, muitas vezes o fornecedor ou o site só aceita alguns desses provedores, então o SSO na prática deixa de ser SSO
Deve haver um motivo, mas não investiguei a fundo. Acho que deveria existir uma especificação comum acordada que todos os fornecedores sigam e, se não existir, é bem provável que em algum momento isso seja imposto por lei
Os padrões já existem e, em teoria, ao digitar um e-mail no formulário de login, ou quando o navegador preenche automaticamente, isso levaria ao login OAuth daquele domínio; se o servidor estiver se comunicando com aquele domínio pela primeira vez, poderia até fazer o registro do cliente na hora. Nunca vi isso sendo usado na prática, mas seria bom se existisse
[0] https://datatracker.ietf.org/doc/html/rfc7591
[1] https://datatracker.ietf.org/doc/html/rfc8414
Ela saiu do modelo de oferecer um serviço e cobrar um preço justo para o modelo de mandar spam ao usuário ou coletar dados para mandar ainda mais spam depois
Padrões abertos não são o que os provedores atuais querem. Porque isso permitiria que o usuário migrasse facilmente para alternativas e deixasse de “se engajar”
Curiosamente, o Apple Pay foi lançado na Austrália depois que os grandes bancos locais passaram anos impulsionando o aumento do uso de pagamentos por aproximação. Então, quando a Apple entrou e exigiu tarifas ao estilo dos EUA, a infraestrutura já tinha sido instalada diretamente pelos bancos
Os grandes bancos australianos resistiram por anos a oferecer suporte ao Apple Pay, mas acabaram cedendo quando a pressão dos clientes ficou grande demais
Até hoje todos estão muito insatisfeitos com isso e abandonariam o Apple Pay imediatamente se os reguladores obrigassem a abertura do chip NFC. Mas, até agora, tem sido difícil encontrar alguém que simpatize com as reclamações dos maiores bancos do país
https://www.accc.gov.au/media-release/accc-denies-authorisat...
Os bancos canadenses também tentaram pagamentos por aproximação próprios no Android, como o TD Pay, mas ninguém queria usar. No fim, desistiram e passaram a oferecer Google Pay
Acho que algo parecido deve acontecer. Mesmo que a Apple abra os pagamentos por NFC, ninguém vai usar app de banco e as pessoas vão preferir suporte de primeira classe como Apple Pay ou Google Pay
Basta ver quantas pessoas de fato usam Samsung Pay em comparação com Google Pay
Alguns varejistas, como a CVS, desativaram pagamentos por aproximação quando o Apple Pay foi lançado
Fico curioso se a parte em que “o comerciante pode solicitar, no checkout, quantas informações pessoais quiser, e o Apple Pay não impede isso” também acontece em compras presenciais
Para comprar ovos no mercado, meu nome e endereço não são necessários. A Apple/Google certamente pedem meu consentimento ao compartilhar informações que também não são necessárias? É algo do tipo aceitar ou ir embora, como termos de uso ou uma EULA shrink-wrap?
Nunca usei esses sistemas de pagamento
As informações adicionais mencionadas no texto só são compartilhadas em pagamentos “online”. Porém isso também inclui casos em que se escaneia um QR code com o celular e se paga pelo Safari ou por um App Clip, um método que tenho visto em alguns restaurantes ultimamente
Nesse caso, o restaurante recebe quantas informações tiver solicitado. Pode incluir nome, endereço e até endereço de e-mail. Em geral, acho que isso aparece na tela de pagamento, mas na primeira vez que usei em um restaurante não percebi bem
Agora peço ao garçom que traga uma maquininha de verdade para eu aproximar o celular, ou simplesmente entrego um cartão físico
Fugindo um pouco do assunto, mas ainda não entendo por que o Apple Pay não consegue mostrar na tela o valor que está prestes a ser pago antes da aprovação da transação.
Não parece ser um problema de experiência do usuário; parece que o dispositivo da Apple simplesmente não sabe esse valor. Por quê?
Demorei um pouco para entender isso. Eu não entendia como o Apple Pay funcionava no modo avião, mas é claro que funciona, já que cartões Visa tradicionais também funcionam sem conexão com a internet.
Fundamentalmente, os dois são a mesma coisa. É por isso também que, se todos seguem o padrão, não há nada extra a “dar suporte”. Veja o comentário irmão de jjcm: https://news.ycombinator.com/item?id=39846117
Então acho que o leitor NFC não “transmite” o valor da compra. Cartões de plástico não tinham como processar essa informação, e o iPhone também não tem como recebê-la e dizer “espere, aguarde até o usuário aprovar com um gesto de deslizar”.
Não sei onde o Gruber disse que “só o Apple Pay faz isso”. O autor aponta alguns erros do Gruber ou pontos em que ele não acertou exatamente os detalhes, e parece ser só isso.
[Atualização: ops, eu estava errado. Matt Birchler, que trabalha no setor de pagamentos, explicou bem como isso funciona, e ficou claro que os principais bancos e empresas de cartão de crédito geram números “DPAN” por estabelecimento em transações de tap-to-pay. Ainda assim, mantenho meu argumento de que o Apple Wallet é pelo menos tão seguro quanto, ou mais seguro que, qualquer app de pagamento digital oferecido por emissores de cartão.]
É o texto do próprio Gruber, o autor original.
O próprio Gruber reconheceu o erro.
Gruber é um fã declarado da Apple, mas em geral costumava acertar os fatos, admitir quando não sabia algo e linkar especialistas da área.
Mas, desde as medidas da Apple em relação ao DMA da UE, ele parece ter perdido completamente a objetividade. Finge entender a redação jurídica melhor que a Comissão Europeia, aplica uma abordagem americana a uma forma europeia de legislar muito diferente e aceita sem questionar declarações mal-intencionadas da Apple.
Essa mudança combina com a postura estranhamente hostil da Apple em relação à UE, então o problema de fundo talvez seja o excesso de confiança de Gruber na Apple.
Parece que ele mantém essa postura também no processo antitruste do governo dos EUA.
Para ser justo, as redes sociais estão cheias de apoiadores da Apple fingindo ser especialistas jurídicos e errando praticamente tudo, então talvez seja difícil para ele encontrar uma visão contrária legítima.
Sobre o trecho “A Apple fez um ótimo trabalho ao popularizar essas carteiras digitais, mas o que ela faz não é algo único no setor”, posso estar lembrando errado, mas acho que, quando o Apple Pay foi lançado, ele era bastante singular. Por isso havia pouquíssimos lugares com suporte.
Outros sistemas de pagamento por celular, como o Samsung Pay inicial, acho que enviavam o número do cartão diretamente ao terminal.
Curiosamente, parece que o Reino Unido ainda tem um limite de £100, enquanto nos EUA já paguei valores acima de US$ 2000 com pagamento por aproximação em um celular Android.
Talvez enviasse diretamente apenas ao banco, de modo que o comerciante não visse, mas ainda assim era o número real. A primeira vez que ouvi falar de uso de DPAN foi com a Apple.
Os EUA estão muito atrasados em tecnologia de pagamentos com cartão por vários motivos. Quando visitei o país vindo da Polônia com um cartão que já usava havia anos ao redor do mundo, tive até de aprender uma forma especial de contorno para que o caixa conseguisse processar o pagamento.