泥潭日报 uscardforum · 每日精选

太黑了Apple Pay会泄露个人隐私给商家

内容摘要

Apple Pay的recurring token机制引发隐私担忧,用户认为商家应明确同意才能绑定支付方式,Apple Pay被指未有效监督。

1. 关键信息

  • (之前已归纳) 用户Puyi反映在InKind应用中使用Apple Pay支付后,其银行卡信息(可直接结账)被InKind平台绑定并保存,Puyi最初认为显示的是完整的卡号。
  • (之前已归纳) 此情况引发了用户对Apple Pay隐私保护机制的质疑,认为其与宣传的隐私设计不符。
  • (之前已归纳) Puyi确认绑定的卡后四位是自己的,但仍对商家未经同意绑定卡片并允许免密支付表示担忧,认为这违背了Apple Pay的初衷。
  • (之前已归纳) 有用户指出,在线商家通过Apple Pay通常只能获取卡号后四位和支付令牌(token),而非完整的原始卡号。
  • (之前已归纳) 讨论倾向于认为,商家保存的是支付令牌,用于处理类似“循环支付”的后续交易,从而实现免密支付,解释了免密支付的实现方式。
  • (新增) 用户Puyi进一步澄清,其主要担忧在于InKind未经同意将Apple Pay使用的银行卡直接设置为默认支付方式,而非看到完整的原始卡号。
  • (新增) 有用户提到,商家通常会保存物理卡号的后四位(last4),方便用户对账,用户侧可能误认为保存了原始卡号。
  • (新增) 讨论指出,存在一种“单向查”机制,即实体卡号可以查询到通过Apple Pay进行的虚拟卡交易记录,但商家无法通过Apple Pay获取的虚拟卡信息反向推导出实体卡号。这可能通过银行/卡组织将消费记录发送给奖励计划实现。
  • (新增) 信用卡(包括Apple Pay产生的虚拟卡)可以反复使用以支持订阅(subscription)等服务,商家绑定的是虚拟卡号、特定授权令牌(token)和真实卡号的后四位。
  • (新增) Apple Pay在确认支付时会有区分:如果能看到金额,通常为单次使用;如果看不到金额,则可能支持多次使用。
  • (新增) 删除Apple Pay中绑定的卡片,会使商家保存的相关令牌作废,这比取消实体卡订阅更方便。
  • (新增) QAX回复Puyi,指出Apple Pay并未将完整卡号信息提供给商家,仅提供后四位,并质疑Puyi关于“直接放了用户信息给吃饭类商家太不合适”的说法,认为Puyi可能混淆了订阅服务和按需付费。
  • (新增) 用户Apocalypsor指出,问题根源在于InKind应用使用了“recurring token”(循环支付令牌),而非一次性令牌。
  • (新增) 用户Puyi认为Apple Pay不应释放“recurring token”,并将其与支付宝在用户支付一次后允许商家保存支付卡号的行为类比,认为Apple Pay在此方面存在问题。
  • (新增) 用户Apocalypsor回应称,这是程序决定的,Apple Pay仅接受指令。
  • (新增) 用户Puyi质疑Apple Pay未能监督商家滥用令牌,认为这构成安全问题,并强调Apple Pay不应直接发出令牌,应像支付宝、PayPal一样,在用户明确同意前不应传递信息。
  • (新增) QAX进一步说明,Apple Pay付款时若不显示金额,即为recurring token;若显示金额,则为一次性token。用户若不想提供recurring token,下次支付时需留意并拒绝同意。若不慎同意,可删除Apple Pay中的卡片,所有recurring token将失效。

2. 羊毛/优惠信息

3. 最新动态

4. 争议或不同意见

  • (之前已归纳) 有用户(折木奉太郎)询问显示的是否为具体卡号,以判断是否为隐私泄露。
  • (之前已归纳) 有用户(ncrystal)猜测可能并非成功使用了Apple Pay,而是其他支付方式导致的信息绑定。
  • (之前已归纳) 有用户(Wi-Fi)建议在非苹果设备上验证InKind是否仍显示完整卡信息,以确认问题。
  • (之前已归纳) 核心争议从“Apple Pay是否泄露完整卡号”转向“商家在用户使用Apple Pay后,未经明确同意绑定支付令牌并允许免密支付是否合理”,以及这种行为是否符合用户对Apple Pay隐私保护的预期。
  • (新增) 有用户认为,商家从POS机只能获得卡号后四位,除非用户手动输入或刷实体卡,因此问题在于商家未经授权绑定卡片,而非Apple Pay泄露完整信息。
  • (新增) QAX对Puyi关于“直接放了用户信息给吃饭类商家太不合适”的说法提出质疑,认为Puyi可能误解了Apple Pay的隐私保护机制,并区分了订阅服务和按需付费的场景。
  • (新增) Puyi认为Apple Pay不应释放“recurring token”,并将其与支付宝在用户支付一次后允许商家保存支付卡号的行为类比,认为Apple Pay在此方面存在问题。
  • (新增) Apocalypsor认为Apple Pay仅是接受指令,问题在于程序设计,而非Apple Pay本身。
  • (新增) QAX指出,Puyi关于“直接放了用户信息给吃饭类商家太不合适”的说法可能混淆了订阅服务和按需付费的场景,Apple Pay并未提供完整卡号。

5. 行动建议

  • (之前已归纳) 建议用户在其他设备上登录InKind账户,确认绑定的卡信息是否确实包含完整卡号并可直接支付,以进一步验证隐私泄露的程度。
  • (之前已归纳) 关注Apple Pay在第三方应用中的隐私设置和绑定机制,警惕支付信息被商家存储。
  • (之前已归纳) 用户应警惕商家在首次Apple Pay支付后,可能利用支付令牌绑定卡片并启用免密支付,即使未泄露完整卡号,也可能影响用户对支付控制的预期。
  • (新增) 理解支付令牌(token)和虚拟卡号的工作原理,以及它们与实体卡号的区别,有助于更好地管理支付隐私。
  • (新增) 对于订阅服务或需要绑定支付方式的商家,用户应了解通过Apple Pay绑定的卡片,在从设备中删除后,其对应的支付令牌会失效,这为取消订阅提供了额外的控制手段。
  • (新增) 区分Apple Pay的单次支付和多次支付(如订阅服务),并理解商家保存后四位卡号是为了方便对账,有助于更准确地评估隐私风险。
  • (新增) 建议用户在遇到类似情况时,深入理解商家使用的支付令牌类型(一次性或循环支付),并认识到Apple Pay在此过程中扮演的角色是执行指令。
  • (新增) 用户在Apple Pay付款时,应留意金额是否显示,以判断商家获取的是一次性token还是recurring token。若不想提供recurring token,需在支付时拒绝同意。若不慎同意,可删除Apple Pay中的卡片来作废所有recurring token。
原始内容
--- 第 1 楼来自 Puyi 的回复 (2026-02-11 16:08:31 PST) ---

震了震了,在InKind上用Apple Pay结账,结完整个卡号就直接绑定进去了,包含所有卡号密码等,可以直接结账

不是说苹果是隐私专家吗,当时记得说Apple Pay就是为了隐私设计的,太黑了

--- 第 2 楼来自 折木奉太郎 的回复 (2026-02-11 16:11:06 PST) ---

他给你显示点点点还是具体内容,前者可能只是一种表示方法,表示已经绑定了,但是不见得是真的有这些信息。后者是漏了。

--- 第 3 楼来自 Puyi 的回复 (2026-02-11 16:11:29 PST) ---

具体的,我可以直接结账的

--- 第 4 楼来自 Wi-Fi 的回复 (2026-02-11 16:11:47 PST) ---

你在非苹果设备上重新登录inkind看一看

--- 第 5 楼来自 Puyi 的回复 (2026-02-11 16:12:35 PST) ---

我还不知道怎么撸Pixel,有方法吗

--- 第 6 楼来自 ncrystal 的回复 (2026-02-11 16:56:39 PST) ---

大概没用成Apple pay

--- 第 8 楼来自 XP_S 的回复 (2026-02-11 17:06:42 PST) ---

应该是有协议开了免密支付吧。Hungry Panda也是用一次Apple pay或者Paypal就会把信息都记下来,下一次默认从同样的渠道刷同一张卡。

--- 第 9 楼来自 H2TG 的回复 (2026-02-11 17:09:08 PST) ---

有没有可能,商户那里保存的卡号,并不是印刷在你实体信用卡上的那个卡号,而只是一个 Apple Pay 的 merchant token

Maintain payment information continuity over time

In addition to device-specific payment tokens used to securely complete a single Apple Pay transaction, use Apple Pay merchant tokens to securely complete automatic reload or recurring payments independent of a device. This allows for continuity across multiple devices. For example, if someone upgrades to a new iPhone, their payment information will be managed through a merchant token and remain active if they remove a card from their old device.

These tokens are also designed to help prevent or resolve billing issues by giving visibility into important payment lifecycle updates, such as account status, bank card art, and card expiration date.

--- 第 10 楼来自 timcock 的回复 (2026-02-11 17:16:20 PST) ---

因为卡号是虚拟的啊

--- 第 11 楼来自 California_joey 的回复 (2026-02-11 17:20:07 PST) ---

【引用自 折木奉太郎】:
体内容,前者可能只是一种表示方法,表示已经绑定了,但是不见得是真的有这些信息。后者是漏了。
作为商户,很负责任的告诉你,apple pay的隐私级别极高,甚至连账单地址都是隐藏的

--- 第 12 楼来自 Charles7 的回复 (2026-02-11 17:37:53 PST) ---

不会,我之前上传报销的始祖鸟的一件衣服,要receipt显示信用卡尾号后四位,联系始祖鸟结果他们给不出说因为我是apple pay付的他们给不了

--- 第 13 楼来自 Puyi 的回复 (2026-02-11 18:05:28 PST) ---

不是虚拟的卡号,跟我的一样的

--- 第 14 楼来自 H2TG 的回复 (2026-02-11 18:05:57 PST) ---

你是能看到完整的卡号,还是只有最后 4 位。

--- 第 15 楼来自 Puyi 的回复 (2026-02-11 18:09:24 PST) ---

我忘了,刚刚被吓到着急就删了,但后四位是肯定我的
【引用自 H2TG】:
这张卡的 merchant token 前台显示给用户的 identifier.
再怎么样我也没同意就把我的卡给人绑定在平台上了??然后就可以免密码付钱了,这样Apple Pay都不需要用了

--- 第 16 楼来自 H2TG 的回复 (2026-02-11 18:14:03 PST) ---

【引用自 Puyi】:
但后四位是肯定我的
肯定是你的,总不能是别人的

“InKind 会自动保存你使用过的卡” 和你指控的 “Apple Pay 会把你的卡号提供给 InKind”, 这两件事还是有区别的吧,

--- 第 17 楼来自 Define_P 的回复 (2026-02-11 18:24:11 PST) ---

所以那张卡你除了在果子 pay 里面有虚拟卡,你还往果子 pay 里手动输入了实体卡卡号和 CVV 用于自动填充?

那也不该啊,如果是走果子 pay 按理也不需要这些信息

--- 第 18 楼来自 H2TG 的回复 (2026-02-11 18:26:36 PST) ---

应该就是在 InKind app 里用 Apple Pay 之后,用于支付的那张卡会以 token 的形式保存在 inkind, 下次再刷的时候就不用 Apple Pay 刷脸/输密码了,而是视为类似 recurring payment 去处理。

--- 第 19 楼来自 pwc 的回复 (2026-02-11 18:39:39 PST) ---

online商家从apple pay拿到的info只能是卡号后四位和token

--- 第 20 楼来自 bscat 的回复 (2026-02-11 18:45:41 PST) ---

ap 不是会生成一个替代卡号吗,会把原始的泄露出去?太可怕了

--- 第 21 楼来自 timcock 的回复 (2026-02-11 19:36:09 PST) ---

技术上不可能呀

--- 第 22 楼来自 Buffet 的回复 (2026-02-11 19:41:20 PST) ---

【引用自 Charles7】:
我是apple pay付的他们给不了
虚拟卡后四位还是能给的 我artizia退款都要看我的applepay的卡的虚拟卡后四位是不是对的上

--- 第 23 楼来自 Puyi 的回复 (2026-02-11 19:51:26 PST) ---

【引用自 H2TG】:
下次再刷的时候就不用 Apple Pay 刷脸/输密码了
那这不很不安全吗?在商家端用一次AP,对面就能够保存我的不管是token还是卡号,直接就能charge

我们用AP就是为了不想注册对方的账号或者怎么样直接结账啊

--- 第 24 楼来自 Puyi 的回复 (2026-02-11 19:52:43 PST) ---

【引用自 Define_P】:
你还往果子 pay 里手动输入了实体卡卡号和 CVV 用于自动填充
没有设置或者保存过自动填充

--- 第 25 楼来自 H2TG 的回复 (2026-02-11 20:00:18 PST) ---

至少要有一个 default payment method 这似乎是 InKind 的设定,所以你应该是怪 InKind 未经你同意,而保存了你只想用一次的付款方式,Apple Pay 本身我没觉得有什么错。

--- 第 26 楼来自 69yyds 的回复 (2026-02-11 20:01:41 PST) ---

你结完账,餐厅给你的Receipt是怎样的?Receipt会显示后四位吧我记得,还是只会显示inkind付款?

--- 第 27 楼来自 Define_P 的回复 (2026-02-11 20:03:05 PST) ---

那无论如何它不会有你的实体卡卡号之类的信息

--- 第 28 楼来自 cr400bfc5145 的回复 (2026-02-11 20:06:35 PST) ---

我去年9月在伦敦用apple pay刷CSR坐地铁,因为换乘站没打换乘标记所以第二天自己上网补登

当时在发愁apple pay的卡号是虚拟的,但没想到输入实体卡号直接就显示了行程

不知道和楼主的是不是一样的情况,所以商家其实能找到背后的实体卡,还是地铁公司和银行有什么特殊的协议?

--- 第 29 楼来自 ze3kr 的回复 (2026-02-11 20:09:17 PST) ---

以及商家那边能看到physical card 的 last4,通常还会保存下来。商家那边会显示一个 XXXX 1001,用户侧看起来就像存了原始卡号。这个 feature 的好处是方便用户对帐的时候知道是哪张卡。(当然 AmEx 的 last4 意义可能没那么大 )

--- 第 30 楼来自 H2TG 的回复 (2026-02-11 20:09:41 PST) ---

【引用自 cr400bfc5145】:
但没想到输入实体卡号直接就显示了行程
【引用自 cr400bfc5145】:
所以商家其实能找到背后的实体卡
我不知道你是如何从上一段推导到下一段的。前者是指能用原卡关联到同一张卡在 apple pay 的交易,但这不代表商家能从他拿到的 Apple Pay 信息获取到原卡的信息。

--- 第 31 楼来自 nkc 的回复 (2026-02-11 20:10:28 PST) ---

mbta也一样,我觉得是可以单向查,实体卡号可以查询虚拟卡号,不能反过来

--- 第 32 楼来自 cr400bfc5145 的回复 (2026-02-11 20:10:41 PST) ---

明白了,所以其实是
【引用自 nkc】:
可以单向查

--- 第 33 楼来自 nkc 的回复 (2026-02-11 20:11:33 PST) ---

比如最简单的实现就是 虚拟卡号=hash(实体卡号+商户编号)

--- 第 34 楼来自 ze3kr 的回复 (2026-02-11 20:11:56 PST) ---

【引用自 cr400bfc5145】:
想到输入实体卡号直接就显示了行程
各种 dining reward program 也是这个道理,你在那边绑定实体卡号,消费的时候哪怕用 Apple Pay 也能 track 上,这种是银行/卡组织直接把消费记录发给 reward program 了

--- 第 35 楼来自 H2TG 的回复 (2026-02-11 20:16:26 PST) ---

除非用户自己 manually 输入卡号或者刷实体卡的磁条,不然商家能从 POS 得到的卡面上的信息就只有 last 4 了。

所以是楼主觉得商户拿到了 last 4 就认为商户能看到卡面的全部信息,然后因为 InKind 默认保存了 Apple Pay 用于交易的卡,就觉得 Apple Pay 有问题

--- 第 36 楼来自 Puyi 的回复 (2026-02-11 20:24:59 PST) ---

【引用自 ze3kr】:
用户侧看起来就像存了原始卡号
不是这个意思,而是我的payment method里面直接顶掉AP那我的卡做default payment了

--- 第 37 楼来自 Puyi 的回复 (2026-02-11 20:26:11 PST) ---

【引用自 H2TG】:
InKind 默认保存了 Apple Pay 用于交易的卡,就觉得 Apple Pay 有问题
这个难道没问题吗?我用AP付了一次钱,没有输入卡号,第二次付钱时候默认的payment method是我没加的卡

--- 第 38 楼来自 H2TG 的回复 (2026-02-11 20:28:32 PST) ---

【引用自 Puyi】:
第二次付钱时候默认的payment method是我没加的卡
我没太懂“是我没加的卡”这部分,所以这张卡是你上一次用 Apple Pay 支付的卡吗?

如果是的话,那就是 InKind 默认把你 Apple Pay 支付的卡作为默认支付方式保存下来了,那这有没有问题另说,问题肯定怪不到 Apple Pay 上,InKind 也没有你的卡号,只有你这张卡的 token, 便于下次结算。

如果不是的话,意味着你上次用 Apple Pay 刷了卡 1, 然后卡 2 出现在了 InKind 里,那这个确实超出我的认知了

--- 第 39 楼来自 jnnksn 的回复 (2026-02-11 20:32:37 PST) ---

Mark一下

--- 第 40 楼来自 QAX 的回复 (2026-02-11 20:39:37 PST) ---

信用卡(包括apple pay产生的虚拟卡)可以反复用这很正常呀,不然要怎么做subscription?绑定的并不是你真正的卡号+cvv/过期时间,而是apple pay里的虚拟卡号+某个一次性token(一次性是指专门为这次授权生成的,并不是说只能用一次)+真实卡号的后4码(方便你知道是哪张卡)。

其实apple pay是有区分的,在apple pay里确认的时候如果能看到金额,就是只能用一次,如果apple pay里确认的时候看不到金额,那就可以用多次(只是可以反复用,并不一定商家会保存下来反复用)

即便是可以反复用的token,一旦你把这张卡从你当时授权用的设备的apple pay里删掉,就会作废。所以要取消subscription还是比真的卡号方便得多。

--- 第 41 楼来自 Puyi 的回复 (2026-03-02 18:05:06 PST) ---

我确认了下看不到整个卡号,只有后四位,但还是觉得很危险

--- 第 42 楼来自 gaozhao 的回复 (2026-03-02 18:11:30 PST) ---

当它不记住后四位卡号,而你有多张卡的时候,你又会觉得很麻烦根本认不得是哪张卡

--- 第 43 楼来自 Puyi 的回复 (2026-03-02 18:12:26 PST) ---

我觉得商家不应该保存用户账号,这就是用户没有自己输卡号而是用Apple Pay的原因

--- 第 44 楼来自 Pericles 的回复 (2026-03-02 18:12:46 PST) ---

完了完了,我网购,竟然连自己家地址都暴露了,网购太黑了

--- 第 45 楼来自 Puyi 的回复 (2026-03-02 18:13:31 PST) ---

如果有个中间gateway当然不希望被保存,我理解下的AP就是这个gateway

--- 第 46 楼来自 gaozhao 的回复 (2026-03-02 18:17:09 PST) ---

所以不应该是InKind的问题吗?你这标题严重碰瓷欸

--- 第 47 楼来自 Puyi 的回复 (2026-03-02 18:17:32 PST) ---

我的意思是AP不应该把这个信息就给InKind呀,就跟支付宝一样,商家也不知道我的卡号,必须要通过支付宝授权才能放钱,但是AP直接把放钱权限送给了InKind

--- 第 48 楼来自 Canva 的回复 (2026-03-02 18:18:05 PST) ---

Apple pay现在支持recurring付费了,之前在doordash刷dd pass,到期前忘了取消直接再次扣钱

--- 第 49 楼来自 Puyi 的回复 (2026-03-02 18:19:06 PST) ---

Recurring也就算了,而且用户也是知道这个recurring,但是直接放了用户信息给吃饭类商家太不合适了

--- 第 50 楼来自 李十三 的回复 (2026-03-02 18:20:37 PST) ---

如果你只能理解支付宝,那这个就相当于是支付宝的免密支付

--- 第 51 楼来自 Puyi 的回复 (2026-03-02 18:21:33 PST) ---

但是AP没有告知用户我用了AP付款以后,商家可以自动fill我的账号保存在他们的网络里

--- 第 52 楼来自 QAX 的回复 (2026-03-02 20:27:52 PST) ---

【引用自 Puyi】:
Recurring也就算了,而且用户也是知道这个recurring
【引用自 Puyi】:
直接放了用户信息给吃饭类商家太不合适了
AP没有把卡号信息给商家呀,只是给了后四位。没看懂你在说什么。

你的意思是说,只有每月固定费用的subscription是ok的。如果是按需使用付费的,那不能算作subscription吗?

--- 第 53 楼来自 Puyi 的回复 (2026-03-02 21:28:46 PST) ---

【引用自 QAX】:
如果是按需使用付费的,那不能算作subscription吗?
也就是说你拿着了你的苹果手机去一家饭店吃饭,吃完饭你用Apple Pay付钱了,然后第二次再去,店家说你吃完了对吧,那就拿你上次的尾号1234的Visa付钱了吧?

听到这里你觉得非常好没问题?

--- 第 54 楼来自 Credit_Relay 的回复 (2026-03-02 21:49:38 PST) ---

线下POS 拿到的是 DPAN + 当次动态码,饭店并不能凭上一次的动态码扣钱。

和在App/会员系统里的绑定授权是两码事。

--- 第 55 楼来自 Puyi 的回复 (2026-03-02 21:51:44 PST) ---

【引用自 Credit_Relay】:
绑定授权
这就是问题呀,我做的操作不是授权绑定,而是单笔的饭店付款而已,但是AP直接给了InKind我的信用卡token

--- 第 56 楼来自 Credit_Relay 的回复 (2026-03-02 21:54:06 PST) ---

是啊,那不是你的卡号,你的卡号不会离开你的设备。

--- 第 57 楼来自 Puyi 的回复 (2026-03-02 22:53:27 PST) ---

但这个支付token存在的价值就跟知道我卡号一样啊。就像我上面举的饭店吃饭例子
【引用自 Puyi】:
你拿着了你的苹果手机去一家饭店吃饭,吃完饭你用Apple Pay付钱了,然后第二次再去,店家说你吃完了对吧,那就拿你上次的尾号1234的Visa付钱了吧?

--- 第 58 楼来自 Apocalypsor 的回复 (2026-03-02 23:54:36 PST) ---

难道你还没明白这是inkind的问题吗,inkind没给一次性的token而是给了recurring token

--- 第 59 楼来自 Puyi 的回复 (2026-03-02 23:57:00 PST) ---

我觉得这是AP问题,他就不应该释放出我的recurring token啊

就跟支付宝不应该在我支付过一次以后就允许商家保存我的支付卡号

--- 第 60 楼来自 Apocalypsor 的回复 (2026-03-02 23:58:07 PST) ---

这是程序来决定的,apple pay只是接受指令而已

--- 第 61 楼来自 Puyi 的回复 (2026-03-02 23:59:59 PST) ---

AP没法监督商家是否滥用?这样得是多大的安全问题

我输信用卡的时候,商家都得问一句我是否想要save to account

AP倒好直接给出去了,当然也有InKind问题,但我觉得如果AP站在消费者这里就不应该给出去这个token

就跟支付宝PayPal一样,咋能付一次钱,对面直接拿到了我的信息

--- 第 62 楼来自 Apocalypsor 的回复 (2026-03-03 00:04:55 PST) ---

这有啥问题,你paypal也能绑定账号多次付款啊,信用卡cvv给出去了也能重复扣款啊

你要是还想不明白自己掏出swift写个demo app就明白区别了

--- 第 63 楼来自 QAX 的回复 (2026-03-03 19:12:56 PST) ---

AP付款的时候如果没有显示金额,那就是recurring tokn。如果有显示金额,那就是一次性token。如果你不想给网站recurring token,那下次不要同意。如果不小心同意了,就把卡从apple pay删掉(所有的recurring token就都废了)然后重新加