在TP5.1项目中接入PayPal NVP/SOAP API，核心在于正确使用USER、PWD、SIGNATURE这三样凭证。SIGNATURE是PayPal后台生成的签名字符串，需要原样进行URL编码，再按字母顺序拼接所有参数，最后进行双重编码。常见的签名失败原因包括凭证混用、SIGNATURE中隐藏了不可见字符、服务器时间戳偏差，以及遗漏了VERSION=124.0参数。
当您的TP5.1项目需要接入PayPal支付接口，且不使用官方SDK，而是走传统的NVP/SOAP API（例如DoExpressCheckoutPayment这类接口），那么签名加密环节必须严格处理。它与OAuth等新型认证方式不同，属于老一代的认证做法，但许多跨境商户仍在沿用，需要手动构造签名请求。
PayPal NVP签名加密的核心三要素
PayPal NVP接口每次请求都需要三个认证参数：USER、PWD、SIGNATURE。其中SIGNATURE是核心，由PayPal后台生成的“API签名字符串”，经过URL编码后参与请求签名计算。它不是您自己生成的密钥，也不能直接使用MD5或SHA进行哈希。
- 登录PayPal商户后台，依次进入【Profile】→【API Access】→【Request API Signature】，获取USER、PWD、SIGNATURE三元组
- SIGNATURE是一长串包含特殊字符的Base64-like字符串，必须原样保留，URL编码后传入（例如空格变为%20，+变为%2B）
- 所有请求参数（包括USER/PWD/SIGNATURE）需按字母升序拼接成k=v&k=v形式，再进行URL编码 + 请求体拼接，最后用
curl或file_get_contents发送POST到https://api-3t.paypal.com/nvp（沙箱环境为https://api-3t.sandbox.paypal.com/nvp）
TP5.1中构造签名请求的实操要点
ThinkPHP 5.1自带了thinkHttp和thinkUrl，但NVP协议对参数顺序、编码、签名没有框架封装，需要手动处理。关键在于：所有参数键名统一转为小写（PayPal要求），例如method=doexpresscheckoutpayment，不能使用大写Method。使用urlencode()对每个value单独编码，再拼接&，例如：method=DoExpressCheckoutPayment&token=EC-xxx&payerid=P-xxx。拼接完成后，再对整个query string整体做一次urlencode()，即双重编码，特别是在参数包含中文或特殊符号时。推荐封装一个buildNvpString($params)方法：排序 → 小写键 → 单值urlencode → join & → 最终urlencode。
常见签名失败原因与调试建议
返回Security header is not valid或Invalid Security Header，请放心，多半不是签名算法写错了，而是格式细节上出了纰漏。
- USER/PWD/SIGNATURE混用了沙箱和生产环境凭证（务必核对API endpoint和对应凭据）
- SIGNATURE字符串里隐藏了换行或不可见空格（复制时容易带入，建议粘贴后执行trim + str_replace(["r","n"," "], '', $sig)）
- 时间戳未同步：PayPal要求请求时间与服务器时间误差不超过15分钟，TP5.1中可用
date('Y-m-dTH:i:sZ')生成UTC时间戳（注意Z表示UTC，非+08:00） - 未设置
VERSION=124.0（当前兼容最低版本），且必须放在请求最前面（虽非签名字段，但影响解析）
安全与合规提醒（跨境商户特别注意）
PayPal对中国境内主体接入NVP接口已逐步收紧，2024年起多数新注册账户不再提供API Signature选项，仅开放REST v2。若您正在维护旧系统，需要警惕以下几点：
- 确认您的PayPal账户类型为Business Account（企业账户），个人账户无法开通API权限
- 确保域名已完成PayPal的Website Payments Preferences → Website Payment Certificate绑定（否则回调可能被拒）
- 所有敏感参数（如PWD、SIGNATURE）严禁硬编码或记录日志，建议存于Env配置（
.env）并设为只读 - 回调地址（
RETURNURL/CANCELURL）必须是HTTPS，且域名与PayPal后台备案一致
