苹果支付重复回调可通过五种方法处理：一、数据库订单号唯一索引拦截重复插入；二、Redis 幂等令牌校验确保单次处理；三、解析 original_transaction_id 二次去重；四、本地文件锁防止并发竞争；五、依据 notification_type 过滤非首次购买通知。
如果用户在 苹果 支付过程中因网络延迟或操作重复导致同一笔订单被多次提交，PHP后端 可能接收到多个相同的支付回调请求，从而引发重复扣款或订单状态异常。以下是处理苹果支付重复支付的多种方法：
一、使用唯一订单号与数据库唯一索引约束
通过在数据库订单表中对商户订单号（如order_no）设置唯一索引，可强制拦截重复插入，避免生成多条相同订单记录。
1、在 MySQL 中执行 ALTER TABLE 语句为订单表添加唯一索引：ALTER TABLE `orders` ADD UNIQUE INDEX `uk_order_no` (`order_no`)。
2、PHP 接收苹果支付回调时，在插入新订单前不进行前置查重，直接执行 INSERT 语句。
立即学习“PHP 免费学习笔记（深入）”；
3、捕获 PDOException 异常，判断错误码是否为 1062（Duplicate entry），若是，则说明该订单号已存在，直接返回成功响应并跳过后续业务逻辑。
二、基于 Redis 实现分布式幂等令牌校验
利用 Redis 的 SET 命令原子性特性，在支付回调入口处验证并消耗一次性令牌，确保同一笔交易仅被处理一次。
1、苹果客户端在调起支付前，向服务端请求一个幂等令牌（如调用 /api/v1/apple-pay/token 接口）。
2、服务端生成 UUID 作为 token，使用 Redis 执行：SET token:abc123 “used” EX 300 NX，设置 5 分钟过期且仅当 key 不存在时写入。
3、苹果支付回调到达时，先校验请求体中携带的 idempotency-key 是否已在 Redis 中存在；若存在则直接返回 HTTP 200，不再执行订单创建与支付验证。
4、若 token 存在且未过期，立即执行 DEL token:abc123 释放锁，并继续后续验签与订单处理流程。
三、解析苹果支付回调中的 original_transaction_id 做二次去重
苹果支付回调数据（receipt-data 解码后）包含 original_transaction_id 字段，同一笔原始交易的所有重试回调均共享该 ID，可用于识别并合并重复通知。
1、对 Apple Pay 回调中的 receipt-data 进行 Base64 解码并 JSON 解析，提取 latest_receipt_info 数组中每条记录的original_transaction_id。
2、查询数据库中是否已存在该 original_transaction_id 对应的有效订单（状态非“已撤销”且非“处理中”）。
3、若存在且订单状态为“已支付”，则直接返回 200 响应，不更新订单状态，不触发发货或库存扣减。
4、若存在但状态为“处理中”，则等待其完成；若超时未完成，可启动补偿查询机制调用 Apple Verify Receipt 接口确认最终状态。
四、引入本地文件锁防止并发回调竞争
在无 Redis 或数据库事务无法覆盖全部场景时，可借助文件系统锁临时阻塞同一订单号的并发处理，适用于单机部署环境。
1、根据回调中传递的 transaction_id 生成标准化锁文件路径：/tmp/apple_pay_lock_”.md5($transaction_id).”.lock。
2、使用 PHP 的 flock() 函数尝试获取独占写锁，设置非阻塞模式（LOCK_NB）。
3、若获取失败，说明另一进程正在处理该交易，当前请求立即返回成功响应，避免重复执行订单逻辑。
4、若获取成功，则执行验签、订单创建、状态更新等操作；完成后释放锁并删除锁文件。
五、在 Apple Pay 服务器通知中启用 notification_type 字段过滤
苹果支付服务器会向指定 URL 发送多种类型的通知（如 INITIAL_BUY、REFUND、RENEWAL），其中只有INITIAL_BUY 代表首次购买，其余类型不应触发新建订单。
1、解析苹果推送的 HTTP POST 请求体，提取 JSON 中的 notification_type 字段值。
2、判断该值是否严格等于 “INITIAL_BUY”；若为"DID_CHANGE_RENEWAL_PREF"、"DID_FAIL_TO_RENEW" 等其他类型，则直接返回 200，不进入订单处理分支。
3、对于沙盒环境测试，需注意苹果可能发送 TEST 类型的模拟通知，也应予以排除。
