不能。Payment Request API 不处理资金结算，仅标准化收集用户已存的支付信息并安全中转至后端，需配合 Stripe、支付宝等网关完成扣款；调用 show() 前必须满足 HTTPS（localhost 除外）、用户已同步支付凭证、methodData 至少含一个浏览器支持的支付方式三个硬性前提。
Payment Request API 能否直接替代传统支付表单？
不能。它不处理资金结算，只是标准化地收集用户已存的支付信息（如卡号、地址），把数据交给你后端去调用 Stripe、支付宝或银行接口完成扣款。浏览器不碰私钥、不发请求，只做“安全中转”。如果你期待点一下就到账，那得配好后端支付网关，否则 paymentRequest.show() 会失败或被拒绝。
调用 show() 前必须校验哪些条件？
三个硬性前提缺一不可，否则直接抛 NotSupportedError 或 SecurityError：
- 页面必须运行在 HTTPS（
localhost除外） - 用户必须已与浏览器同步过支付凭证（Chrome/Edge 中打开
chrome://settings/payments可查） -
PaymentRequest构造时传入的methodData至少含一个浏览器支持的支付方式，比如"basic-card"；若写成"https://example.com/pay"这种自定义方式，需提前注册 Payment Handler
常见错误现象：Uncaught TypeError: Failed to construct 'PaymentRequest': The provided value is not a valid enum value —— 多半是 methodData[0].supportedMethods 拼错了，比如写成 "basid-card"。
如何适配不同国家用户的银行卡格式与币种？
PaymentRequest 本身不校验卡号合法性，但会按 currency 和 countryCode 过滤可用卡片。例如：
立即学习“前端免费学习笔记（深入）”；
<pre class="brush:php;toolbar:false;">const request = new PaymentRequest([
{
supportedMethods: "basic-card",
data: {
supportedNetworks: ["visa", "mastercard", "amex"],
supportedTypes: ["credit", "debit"]
}
}
], {
total: { label: "Total", amount: { currency: "USD", value: "99.99" } },
// 这里设为 "JPY"，用户保存的 Visa 卡若未标注支持日元，就不会出现在选择列表中
requestPayerEmail: true,
requestShipping: true
});
注意：requestShipping: true 会触发地址收集，但返回的 <code>shippingAddress 是只读对象，且字段名（如 recipient、phone）不保证所有浏览器都返回——Safari 目前不返回 phone，别假设它一定存在。
用户取消或支付失败后怎么处理？
show() 返回 Promise，成功时 resolve 一个 PaymentResponse，失败时 reject 一个 DOMException。关键不是 catch 错误，而是区分用户行为：
-
response.details.cardNumber永远为空字符串 —— 浏览器绝不会暴露完整卡号，只给 token 化后的cardNetwork和cardLastFour - 如果 reject 的原因是
name === "AbortError"，说明用户点了“取消”或切走了标签页 - 如果 reject 的原因是
name === "NotAllowedError"，大概率是没在用户手势（如 click）回调里调用show()，比如绑在setTimeout里就会被拦截
真正容易被忽略的是：响应对象里的 response.complete('success') 必须调用，且只能调一次。不调，UI 会一直显示“处理中”；调两次，会报错并中断流程。这个动作是你告诉浏览器“我已收到数据，可以收起弹窗了”，和后端是否扣款成功无关。
