- La estructura que oculta el número real de la tarjeta no es una función exclusiva de Apple Pay, sino un método de pago que también usan las principales billeteras digitales como Google Pay y Samsung Pay
- La clave es la separación entre el FPAN, el número de la tarjeta física, y el DPAN, el número de pago específico de cada dispositivo; incluso con la misma tarjeta, en un iPhone y un iPad se usan DPAN distintos
- El DPAN puede dificultar el seguimiento entre comercios, pero dentro de un mismo comercio se mantiene también para transacciones posteriores, por lo que no impide el seguimiento del historial de compras de un solo comercio
- Ante una filtración de información de pago, el DPAN es más seguro que el FPAN, y solo funciona cuando se presenta junto con un paquete criptográfico único asociado a cada transacción
- Apple Pay no oculta automáticamente datos personales como nombre, correo electrónico, dirección de facturación o envío, o los productos comprados; debe asumirse que la información mostrada en la pantalla de pago se entrega al comercio
El DPAN no es una función exclusiva de Apple Pay
- Cuando se dice que Apple Pay oculta el número real de la tarjeta de crédito, el punto clave es el DPAN
- El FPAN es el funding primary account number de 15 a 18 dígitos impreso en la tarjeta física, y el DPAN es el device primary account number
- El DPAN puede entenderse de forma similar a un registro DNS
- El usuario accede a un sitio web mediante un nombre de dominio sin conocer la dirección IP real
- Si se usa la misma tarjeta con Apple Pay en un iPhone y un iPad, cada dispositivo recibe un número único y usa un DPAN distinto
- Es importante notar que, ya desde el nombre, no se trata de un “Apple Pay number”
- Google Pay y Samsung Pay, como billeteras digitales importantes en EE. UU., también ocultan el número real de la tarjeta de la misma manera
- Los botones de Amazon Pay y Shop Pay también procesan el pago a través de otras empresas, así que técnicamente no usan DPAN, pero impiden que el comercio vea el FPAN real
Los comercios y los bancos también buscan reducir la exposición del número real de tarjeta
- Si un comercio procesa directamente el número real de una tarjeta de crédito, aumenta mucho su riesgo
- Las herramientas modernas de aceptación de pagos hacen que la información de pago se recopile reduciendo al mínimo la cantidad de personas con acceso a los datos reales de la tarjeta
- La suposición de que los bancos no usarían DPAN no coincide con los casos reales
- Varios bancos como Wells Fargo, Chase y Bank of America operaron u operan sus propias billeteras digitales, y todos protegen los números de cuenta comunes mediante DPAN
- Paze, usado por grandes bancos de EE. UU., también utiliza DPAN
- Una de las principales razones que destaca Paze es: “Paze does not share your actual card number with the merchant.”
Qué seguimiento impide el DPAN y cuál no
- No es correcto decir que el DPAN cambia en cada transacción
- En transacciones sucesivas dentro del mismo comercio se usa el mismo DPAN
- Esta estructura puede crear una barrera para los data brokers que compran datos de transacciones de varios comercios para identificar los patrones de compra de una persona
- En cambio, un solo comercio puede ver el historial de transacciones de ese cliente únicamente con el DPAN proporcionado por Apple Pay
- Apple Pay no impide situaciones como el caso en que Target infirió el estado de un cliente a partir de su propio historial de compras
- Otras billeteras digitales tienen la misma limitación
La protección que ofrece el DPAN ante una filtración de datos
- En una situación en la que se filtra información de tarjetas de pago, el DPAN es más seguro que el FPAN
- En 2024, los comercios no deberían manejar directamente números de tarjetas de crédito, pero puede ocurrir que una pasarela de pagos sea hackeada y se filtren el DPAN y la fecha de vencimiento
- Un atacante no puede ejecutar un pago solo con el DPAN filtrado
- El DPAN solo funciona cuando se presenta como parte de un paquete criptográfico único para cada transacción
- Hay formas de ejecutar pagos recurrentes con tarjetas recopiladas mediante Apple Pay, pero un hacker no debería poder hacerlo
- Por eso, una filtración del FPAN es mucho más peligrosa que una filtración de los DPAN que recopilan todas las billeteras digitales
Apple Pay no oculta automáticamente los datos personales
- La idea de que Apple Pay oculta automáticamente los datos personales no es cierta
- Al ejecutar una transacción real de Apple Pay en una cuenta de comercio de prueba, los reportes a nivel de comercio muestran información como nombre, correo electrónico, dirección de facturación y domicilio
- Para pagos de productos físicos se necesita información de envío, por lo que el SDK de Apple Pay permite que el comercio elija qué datos personales solicitar al cliente
- La información del producto también se transmite a Apple Pay para mostrarle al comprador qué está comprando, y esa información también se entrega al comercio
- Debe asumirse que la información que aparece en la tarjeta de Apple Pay durante el pago se entrega al comercio
- En este sentido, Apple Pay es igual a otros métodos de pago
- El comercio elige qué datos personales necesita o quiere solicitar durante el checkout
- Otras billeteras digitales funcionan de la misma manera
La protección que realmente ofrecen las billeteras digitales
- Apple Pay es un buen medio de pago, y Apple tuvo un papel en popularizar este tipo de billetera digital
- Sin embargo, las funciones de Apple Pay no son únicas en la industria
- El DPAN ayuda a dificultar el seguimiento de las compras de una persona entre varios comercios y a reducir el riesgo para el cliente cuando se filtra información de tarjetas de pago
1 comentarios
Comentarios de Hacker News
Quisiera una explicación ELI5 de cómo funcionan realmente Apple Pay y Google Pay. Antes pensaba que simplemente le pasaban la información de la tarjeta al comercio o al procesador de pagos, y el texto original parece decir algo parecido, pero también he visto que, al usar Amex en Google Pay, algunos comercios rechazan el pago, a diferencia de cuando uso MasterCard
A veces siento que Apple/Google actúan como si fueran el procesador de pagos o incluso el medio de pago en sí. Porque recopilan datos de transacciones y parecía que las terminales de los supermercados también necesitaban soporte especial para las apps de Apple/Google Pay
Entonces me pregunto cuál es el secreto propietario de Apple/Google y por qué es difícil o imposible reemplazarlo con una alternativa open source. ¿Será porque solo Apple/Google tienen acceso completo al chip NFC en iOS/Android?
https://news.ycombinator.com/item?id=39845805
Lo importante es el valor predeterminado. Solo puede haber una billetera Visa o Mastercard predeterminada por dispositivo, y tiene ventaja la que no requiere abrir una app antes de tocar la terminal. Google Pay admite tarjetas de varios bancos, así que tiene una gran ventaja frente a la billetera HCE de un banco emisor específico
Apple/Google intervienen como intermediarios cuando se registra una tarjeta nueva en un dispositivo concreto, pero no participan en el flujo real de la transacción en el POS
El comercio todavía debe aceptar la marca de tarjeta subyacente. Las versiones modernas de Google Pay y Apple Pay no son tarjetas proxy que cambian la marca de la tarjeta, y son distintas de servicios como Curve
Las terminales físicas no necesitan soporte aparte. Mientras la terminal no tenga bugs, funciona en cualquier lugar que acepte el esquema de tarjeta subyacente. Los protocolos físicos y lógicos son los mismos que los de una tarjeta plástica, y desde el punto de vista de la terminal casi no se distinguen
En la web es diferente. El sitio de la tienda y el proveedor de servicios de pago deben admitirlo explícitamente
Por eso, en general, las terminales inalámbricas simplemente aceptaban Apple Pay y Google Pay, sin requerir mucho soporte especial. Uno de los cambios, si no recuerdo mal, fue que como estos dispositivos se consideraban más seguros, el límite de pago subió respecto de las tarjetas sin contacto
La razón por la que una implementación open source es difícil es que implementar EMV es complejo y requiere muchas pruebas y validaciones con equipos especializados. El dispositivo necesita un área segura para guardar claves privadas de forma segura, y la app debe poder garantizar la seguridad del usuario verificando que se usó autenticación biométrica o desbloqueo con PIN
Además, durante el proceso de configuración hay que integrarse con el backend del banco emisor de la tarjeta para recibir las claves y la información necesarias. Es muy probable que una implementación open source también tenga que firmar acuerdos con bancos y pasar validaciones de laboratorio a través de entidades como UL
Apple Pay, Google Pay y las apps de pago ofrecidas por bancos verifican la autorización del tarjetahabiente mediante biometría, y convierten algunos pagos en “tarjetahabiente presente”
Por eso algunos tipos de contracargos se rechazan de inmediato, y para otros también se reduce la carga de pruebas exigida al comercio
Esto forma parte de los estándares de las redes de tarjetas, y si te interesa puedes verlo en https://www.emvco.com/
No hay opciones open source porque hay que certificar la seguridad de la implementación, así que se necesita una entidad comercial que trabaje con los bancos. Además, hay que integrarse por separado con cada banco, así que son demasiados bancos con los que tratar
Hacer que una transacción end-to-end funcione correctamente para todos los esquemas de tarjetas, todos los métodos de pago y todos los dispositivos es bastante complicado. Cada esquema de tarjetas tiene distintos parámetros de “kernel de pago” y requisitos de certificación
O también puede ser un intento de ahorrar en comisiones de transacción. Amex suele ser mucho más cara para los comercios
https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...
Cuando Apple Pay empezó a usarse ampliamente por primera vez, lo revisé con bastante detalle basándome en mi experiencia en procesamiento de pagos minoristas. Lo que más me impresionó en ese momento fue lo profundamente arraigado que estaba en los estándares de la industria
Después de la comunicación inalámbrica, ninguna parte era exclusiva de Apple, y al leer este artículo parece que eso se ha mantenido hasta ahora
Recuerdo que algunos comercios que aceptaban deliberadamente tap-to-pay basado en tarjetas tuvieron que cambiar sus sistemas cuando terminaron aceptando sin querer el muy estándar tap-to-pay de Apple. CVS me viene especialmente a la mente; creo que participaba en un sistema de pago competidor y quería usar el hecho de que ese sistema funcionara en sus tiendas como un diferenciador frente a Apple Pay
Cuando recientemente empezó a surgir el mito de “esto solo lo hace Apple Pay”, me pregunté si algo habría cambiado desde la última vez que lo revisé, así que me alegra que el autor haya hecho una revisión actualizada en este contexto
Me sorprendió bastante que, aun sin soporte oficial, Apple Pay funcionara en todas partes de Australia. En Estados Unidos solo lo soportaban poquísimos comercios, pero en Australia, al estar basado en estándares, básicamente el 99% de los POS ya lo soportaban
El estado confuso de los pagos en Android también contribuyó. Samsung Pay podía referirse a NFC o a emulación de banda magnética. Google es famosa por no saber hacer branding, y entre las distintas iteraciones de Wallet y Google Pay todavía es difícil entender qué es qué
Lo que falta en estas discusiones es que las transacciones con billeteras como Apple Pay, Google Pay y Samsung Pay ahora son tan rastreables como una transacción hecha con el número de tarjeta subyacente
El DPAN es único para un dispositivo específico, pero hoy los proveedores de servicios de pago de los comercios pueden recibir de las redes de tarjetas un identificador único llamado PAR en la respuesta de autorización. Ese identificador es el mismo para todos los DPAN de una misma tarjeta, y el objetivo es que se mantenga para la misma cuenta base incluso si cambia el número de tarjeta
Con el PAR, un comercio no puede realizar cargos, así que no es un problema de seguridad, pero no hay que esperar que un pago con billetera digital sea más privado que un pago con tarjeta normal o con número de tarjeta
https://wcapra.com/payment-account-reference-capraplus-your-...
https://www.securetechalliance.org/wp-content/uploads/EMVCo-...
Al artículo de Matt Birchler se le agregó un párrafo que dice: “En una versión anterior dije que el DPAN cambiaba por comercio, pero fue un error. Fue mi culpa por escribir demasiado rápido”. Pero el resto del artículo aún parece asumir que existe un DPAN único por comercio, y no puedo encontrar evidencia de eso
La propia documentación de Apple https://support.apple.com/en-us/HT203027 también dice que el DPAN, aquí llamado Device Account Number, solo es único por dispositivo. Cuando se agrega una tarjeta a Apple Pay, se genera el DPAN de ese dispositivo, y no cambia después a menos que elimines la tarjeta y la vuelvas a agregar
Por eso, si usas la misma tarjeta en dos dispositivos, un iPhone y un Apple Watch, los DPAN serán distintos y será más difícil rastrearte, pero si usas la misma tarjeta en el mismo dispositivo en varios comercios, creo que un data broker sí podría rastrearte
No entiendo por qué el SSO y los pagos móviles no son interfaces estándar en las que cualquiera pueda crear un proveedor. En lugar de “Login with Google” o “Login with Apple”, ¿no debería existir “iniciar sesión con mi proveedor de SSO predeterminado”? Lo mismo para “pagar con mi proveedor de pagos predeterminado”.
Peor aún, muchas veces el proveedor o el sitio solo admite algunos de estos proveedores, así que el SSO en la práctica deja de ser SSO.
Seguro hay razones, pero no las he investigado a fondo. Parecería que debería existir una especificación común acordada que todos los proveedores sigan y, si no existe, es muy probable que algún día la ley obligue a que sea así.
Los estándares ya existen y, en teoría, si ingresas tu correo en un formulario de inicio de sesión o el navegador lo autocompleta, eso podría llevar al inicio de sesión OAuth de ese dominio y, si el servidor se comunica por primera vez con ese dominio, incluso podría registrar el cliente sobre la marcha. Nunca lo he visto usado en la práctica, pero estaría bueno.
[0] https://datatracker.ietf.org/doc/html/rfc7591
[1] https://datatracker.ietf.org/doc/html/rfc8414
Se pasó de ofrecer un servicio y cobrar una tarifa justa a enviar spam al usuario o recopilar datos para mandarle más spam después.
Los estándares abiertos no son lo que quieren los proveedores actuales. Porque entonces los usuarios podrían cambiarse fácilmente a otra alternativa y dejarían de “participar”.
Curiosamente, Apple Pay se lanzó en Australia después de que los grandes bancos locales impulsaran durante años el aumento del uso de pagos sin contacto. Así que cuando Apple llegó y exigió comisiones al estilo estadounidense, la infraestructura ya la habían instalado directamente los bancos.
Los grandes bancos australianos resistieron durante años dar soporte a Apple Pay, pero cuando la presión de los clientes se volvió demasiado fuerte, terminaron cediendo.
Incluso ahora todos siguen muy molestos con esto y, si el regulador obliga a abrir el chip NFC, abandonarían Apple Pay de inmediato. Pero hasta ahora ha sido difícil encontrar a alguien que simpatice con las quejas de los bancos más grandes del país.
https://www.accc.gov.au/media-release/accc-denies-authorisat...
Los bancos canadienses también intentaron ofrecer sus propios pagos sin contacto en Android, como TD Pay, pero nadie los quería. Al final se rindieron y ofrecieron Google Pay.
Creo que pasará algo parecido. Aunque Apple abra los pagos NFC, nadie usará las apps de los bancos y preferirá el soporte de primera línea como Apple Pay o Google Pay.
Basta con ver cuánta gente usa realmente Samsung Pay en comparación con Google Pay.
Algunos comercios minoristas, como CVS, desactivaron los pagos tap cuando se introdujo Apple Pay.
Me pregunto si la parte de que “el comercio puede solicitar toda la información personal que necesite en el checkout, y Apple Pay no lo impide” también ocurre en las compras presenciales.
Para comprar huevos en el supermercado no necesitan mi nombre ni mi dirección. ¿Apple/Google de verdad piden mi consentimiento cuando se comparte información que claramente no es necesaria? ¿Es un “lo aceptas o te vas” como los términos y condiciones o un EULA shrink-wrap?
Nunca he usado estos sistemas de pago.
La información adicional mencionada en el artículo solo se comparte en pagos “en línea”. Aunque eso también incluye casos en los que escaneas un código QR con el teléfono y pagas en Safari o en un App Clip, una modalidad que he visto en algunos restaurantes últimamente.
En ese caso, el restaurante recibe tanta información como haya solicitado. Puede incluir nombre, dirección e incluso correo electrónico. Normalmente parece mostrarse en la hoja de pago, pero la primera vez que lo usé en un restaurante no me di mucha cuenta.
Ahora le pido al mesero que traiga una terminal física para hacer tap, o simplemente le doy una tarjeta física.
Me salgo un poco del tema, pero todavía no entiendo por qué Apple Pay no puede mostrar en pantalla el monto actual a pagar antes de aprobar la transacción.
No parece ser un problema de experiencia de usuario, sino que el dispositivo Apple directamente no conoce ese monto. ¿Cuál será la razón?
Me tomó un tiempo entender esto. No entendía cómo funcionaba Apple Pay en modo avión, pero por supuesto que funciona. Porque una tarjeta Visa tradicional también funciona perfectamente sin conexión a internet.
En el fondo, las dos cosas son lo mismo. Por eso, si todos se comportan según el estándar, no hay nada adicional que “soportar”. Ver el comentario hermano de jjcm: https://news.ycombinator.com/item?id=39846117
Por eso creo que el lector NFC no “transmite” el monto del pago. Las tarjetas de plástico no tenían forma de procesar esa información, y el iPhone tampoco tiene forma de recibirla y decir “un momento, espera hasta que el usuario lo apruebe con un deslizamiento”.
No sé dónde dijo Gruber que “esto lo hace solo Apple Pay”. El autor señala algunos errores de Gruber o detalles que no captó con precisión, y eso parece ser todo.
[Actualización: vaya, me equivoqué. Matt Birchler, que trabaja en la industria de pagos, explicó bien cómo funciona, y quedó claro que los principales bancos y emisores de tarjetas de crédito generan números “DPAN” por comercio en las transacciones tap-to-pay. Aun así, mantengo mi afirmación de que Apple Wallet es al menos igual de segura, o más, que cualquier app de pagos digitales ofrecida por los emisores de tarjetas.]
Es el texto de Gruber, el autor original.
Gruber también reconoció su error.
Gruber es un fan declarado de Apple, pero en general solía acertar en los hechos, reconocer lo que no sabía y enlazar a expertos del área.
Pero desde las medidas de Apple por la DMA de la UE, parece haber perdido por completo la objetividad. Actúa como si entendiera mejor el texto legal que la CE, aplica un enfoque estadounidense a una forma europea de legislar muy distinta y acepta sin cuestionar las declaraciones malintencionadas de Apple.
Este cambio coincide con la actitud extrañamente hostil de Apple hacia la UE, así que quizá el problema de fondo sea que Gruber confía demasiado en Apple.
Parece que mantiene esa actitud también frente a la demanda antimonopolio del gobierno de Estados Unidos.
Para ser justos, las redes sociales están llenas de defensores de Apple que se hacen pasar por expertos legales y dicen casi todo mal, así que tal vez le resulte difícil ver posturas contrarias legítimas.
Sobre la parte de que “Apple hizo un gran trabajo popularizando estas billeteras digitales, pero lo que hacen no es algo único en la industria”, quizá recuerde mal, pero creo que Apple Pay era bastante singular cuando salió. Por eso había muy pocos lugares que lo aceptaran.
Otros sistemas de pago con teléfono, como el Samsung Pay inicial, creo que enviaban el número de tarjeta tal cual al terminal.
Curiosamente, parece que el Reino Unido todavía tiene un límite de £100, mientras que en Estados Unidos he pagado más de $2000 con pagos sin contacto desde un teléfono Android.
Quizá se lo enviaba directamente solo al banco y el comercio no lo veía, pero seguía siendo el número real. La primera vez que escuché de algo que usara DPAN fue con Apple.
Estados Unidos está muy atrasado en tecnología de pagos con tarjeta por varias razones. Cuando visité Polonia con una tarjeta que llevaba años usando en todo el mundo, al punto de venta tuvieron que aprender primero una solución especial para poder cobrarme.