苹果支付重复回调可通过五种方法处理：一、数据库订单号唯一索引拦截重复插入；二、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类型的模拟通知，也应予以排除。
