苹果内购验证中，receipt-data须Base64编码原始收据并校验格式，password需从环境变量安全获取且仅在21004时提交，支持HMAC签名增强完整性，并依status自动切换沙盒/生产验证地址。
如果您在对接苹果内购（In-App Purchase）时需向 Apple 验证服务器提交 receipt-data，该字段必须为 Base64 编码的原始收据数据，且在涉及自动续订订阅时还需携带 password 参数——该参数本身不加密，但其值需与 App Store Connect 中配置的共享密钥严格一致。以下是实现苹果支付参数准备与传输安全处理的多种方法：
一、receipt-data 的 Base64 编码与校验
receipt-data 是苹果客户端生成的原始收据二进制数据，服务端接收后不可直接使用明文传输，必须进行标准 Base64 编码以满足 Apple 验证接口要求；同时需前置校验长度与格式，防止空值或截断数据引发 21002 错误。
1、使用 file_get_contents 或 POST 原始体获取客户端传入的 receipt-data 字符串（注意：部分 SDK 可能已 Base64 编码一次，需确认是否重复编码）。
2、执行 trim() 去除首尾空白，并使用 base64_decode() 尝试解码一次，验证是否为合法 Base64 格式。
立即学习“PHP免费学习笔记（深入）”；
3、若解码成功且长度大于 20 字节，则视为有效原始收据，再执行一次 base64_encode() 得到最终提交用的 receipt-data 值。
4、若原始输入非 Base64 编码（如十六进制或 JSON 封装），需先按实际格式解析出原始二进制字节流，再统一 Base64 编码。
二、password 参数的安全传递与匹配
password 字段用于自动续订订阅验证，其值为 App Store Connect 中“App Information → In-App Purchases → Shared Secret”所配置的 32 字符十六进制字符串。该值虽不加密传输，但必须严格保密、禁止硬编码、且仅在验证响应返回 21004 时才参与重试请求。
1、将共享密钥通过环境变量注入 PHP 运行环境，例如设置 APPSTORE_SHARED_SECRET=5a7f2c9e1b3d4f6a8c0e2b7d9a1f4c6e。
2、在验证逻辑中读取该环境变量：getenv('APPSTORE_SHARED_SECRET')，并仅当首次验证返回 status=21004 时才将其作为 password 字段加入请求体。
3、禁止将 password 直接写死在代码中，禁止记录或日志输出该值，禁止通过 URL 参数传递。
4、若系统支持多应用，应按 bundle_id 动态映射对应 shared secret，避免密钥混用。
三、使用 OpenSSL 对 receipt-data 进行可选签名封装（增强完整性）
虽然 Apple 接口不要求对 receipt-data 本身签名，但在高安全要求场景（如代理转发、多级网关）下，服务端可在提交前对 receipt-data + timestamp + nonce 组合进行 HMAC-SHA256 签名，供自身中间层校验防篡改，此操作不影响 Apple 官方验证流程。
1、拼接待签名字符串：base64_encoded_receipt . '|' . time() . '|' . bin2hex(random_bytes(8))。
2、使用服务端私有密钥（如从 KMS 获取）调用 hash_hmac('sha256', $data, $secret_key) 生成签名。
3、将签名值附加至请求头 X-Receipt-Signature 或请求体扩展字段 x-signature，供后续中间件验证。
4、Apple 验证接口忽略该签名字段，仅由本系统内部消费，不改变 receipt-data 主体内容。
四、沙盒与生产环境自动切换的 receipt 提交策略
Apple 要求沙盒收据必须提交至 sandbox.itunes.apple.com，生产收据提交至 buy.itunes.apple.com；但客户端无法可靠标识环境，需服务端根据响应 status 自动降级重试，避免因 endpoint 错误导致 21007/21008 类错误。
1、默认优先向生产 endpoint 发起验证请求。
2、若响应中 status = 21007（收据来自沙盒，但发往生产），则立即使用同一 receipt-data 向 sandbox endpoint 重发请求。
3、若响应中 status = 21008（收据来自生产，但发往沙盒），则终止流程并记录异常，表明客户端环境标识严重错乱。
4、两次请求均需携带相同 password（如适用），且第二次请求必须复用首次解码后的原始 receipt-data，禁止二次 base64 编码。
