调用PayPal API修订订阅时提示JSON请求格式错误排查
问题原因及解决方案
核心问题:重复设置Content-Type引发请求解析异常
你的代码同时在options根节点设置了contentType: "application/json",又在headers里重复定义Content-Type: application/json,这会导致UrlFetchApp发送的请求头出现字段冲突,加上你手动用JSON.stringify()包裹payload,最终造成双重序列化(发送的是JSON字符串的JSON表示),PayPal因此无法正确解析请求体。
修复后的代码示例
方案一:使用UrlFetchApp自动序列化(推荐)
移除headers中的Content-Type,保留根节点的contentType配置,直接传入对象作为payload:
var url = "https://api.paypal.com/v1/billing/subscriptions/" + subID + "/revise"; var bearer = "XXXXXXXXX"; var options = { "method": "POST", "contentType": "application/json", "headers": { "Authorization": "Bearer " + bearer }, "payload": { "plan_id": "X-XXXXXXXXXXXXXXXXXXX" } }; var response = UrlFetchApp.fetch(url, options); Logger.log(response);
方案二:手动序列化并仅在headers中设置Content-Type
如果需要手动控制序列化流程,移除根节点的contentType,仅在headers中定义Content-Type,同时用JSON.stringify()处理payload:
var url = "https://api.paypal.com/v1/billing/subscriptions/" + subID + "/revise"; var bearer = "XXXXXXXXX"; var options = { "method": "POST", "headers": { "Content-Type": "application/json", "Authorization": "Bearer " + bearer }, "payload": JSON.stringify({ "plan_id": "X-XXXXXXXXXXXXXXXXXXX" }) }; var response = UrlFetchApp.fetch(url, options); Logger.log(response);
额外检查点
- 核对
plan_id格式:PayPal订阅计划ID通常以P-开头,你的示例中是X-开头,建议确认PayPal后台的实际计划ID是否正确。 - 确认
subID为Live环境有效订阅ID,避免混淆Sandbox与Live环境的ID。
内容的提问来源于stack exchange,提问作者Denis Spiritelli
相关产品推荐
相关产品推荐

