简介这份资源面向需要在WordPress站点接入PayPal与Stripe支付的开发者与站长重点解决内嵌支付与跳转支付两种模式的落地问题。内容围绕支付网关配置、插件集成与自定义功能展开适合具备一定WordPress与PHP基础、希望提升在线交易效率的中高级用户。压缩包共15个文件约49KB以9个php文件为核心承载支付接口逻辑与配置另含1个js、1个css及woff/woff2字体文件用于前端交互与样式呈现2个png可作界面示意或图标素材。目前已有1270人学习下载说明该方案在支付集成场景中具备一定参考价值。读者可从中获取PayPal与Stripe的接入思路、内嵌与跳转两种支付流程的实现参考以及支付状态跟踪等常见问题的处理方向便于按文档快速完成站点支付功能搭建与调试。1. 从一次支付掉单说起WordPress 上 PayPal 与 Stripe 的两种接法去年帮一个做独立站的朋友排查订单问题后台显示已付款PayPal 后台却查不到对应交易折腾半天才发现是「跳转模式」下用户点了支付又手动关掉页面回调没回来。这类玄学掉单八成是支付模式选错了。WordPress 上接 PayPal 和 Stripe绕不开两个核心选择内嵌Embedded / Elements还是跳转Redirect / Checkout。内嵌把支付表单直接渲染在你自己的结账页里用户不离开站点转化率高但需要处理前端 SDK 加载、卡片校验和 3D Secure 验证跳转则把用户送到支付网关的托管页面省心、合规压力小代价是跳出率略高、回调逻辑必须写扎实。这份资源包把两种模式、两个通道的完整实现都拆开了适合正在给 WooCommerce 或自建结账页接支付的开发者也适合想搞懂「为什么我的回调老丢」的运维。下面按「先跑通再优化」的顺序把配置、代码和坑一条条过一遍。2. 环境准备与密钥体系把两套凭证先理清楚2.1 沙箱账号与 API 密钥的获取路径PayPal 和 Stripe 都提供独立的测试环境千万别拿生产密钥调试。Stripe 的测试密钥在 Dashboard 的 Developers → API keys 里分 Publishable key前端用pk_test_ 开头和 Secret key后端用sk_test_ 开头。PayPal 则要去 Developer Dashboard 创建 Sandbox App拿到 Client ID 和 Secret再在 Sandbox Accounts 里生成一个买家账号和一个商家账号测试时用买家账号登录付款。这里有个容易混的点PayPal 的 Client ID 是公开的可以出现在前端Secret 只能留在服务端。Stripe 同理pk 可以进 JSsk 绝不能进浏览器。我一般会在 wp-config.php 里定义常量而不是硬编码进主题文件// wp-config.php 中定义避免密钥进版本库 define(STRIPE_PK, pk_test_xxxxxxxx); define(STRIPE_SK, sk_test_xxxxxxxx); define(PAYPAL_CLIENT_ID, ATxxxxxxxx); define(PAYPAL_SECRET, ELxxxxxxxx); define(PAYPAL_MODE, sandbox); // 上线改 live逻辑说明把密钥抽到配置文件主题更新时不会丢PAYPAL_MODE 控制 API 基址切换sandbox 走 api-m.sandbox.paypal.comlive 走 api-m.paypal.com。参数上Stripe 的 sk 用于服务端创建 PaymentIntentPayPal 的 Secret 用于换取 access_token两者都不能出现在任何前端请求里。2.2 插件方案与纯代码方案的取舍资源包里同时给了插件配置和纯代码两套路径。如果你用的是 WooCommerce官方有 WooCommerce PayPal Payments 和 WooCommerce Stripe Gateway 两个插件装完填密钥就能跑内嵌和跳转在插件设置里勾选即可。但插件的问题是黑匣子——回调逻辑、订单状态流转被封装了出问题只能看日志猜。纯代码方案适合自建结账页或需要深度定制订单流的场景。核心就三件事前端加载 SDK、后端创建支付意图、Webhook 接收异步通知。我一般建议先用插件跑通全流程确认账号和密钥没问题再换成代码方案做定制。这样排错时能分清是「账号配置问题」还是「代码逻辑问题」省掉大量来回试的时间。提示切换 sandbox 和 live 时密钥、Webhook 端点、商品价格都要同步换漏一个就会出现「测试通过、上线失败」的经典翻车。3. 内嵌模式实战Elements 与 PayPal Buttons 的落地3.1 Stripe Elements 的前后端配合内嵌模式的核心是「前端收集支付信息后端确认扣款」。Stripe 用 PaymentIntent 串起整个流程后端创建 Intent 拿到 client_secret前端用这个 secret 初始化 Elements 并确认支付。先看后端创建 PaymentIntent 的接口// 注册一个 REST 路由供前端调用 add_action(rest_api_init, function () { register_rest_route(shop/v1, /create-intent, [ methods POST, callback create_stripe_intent, permission_callback __return_true, ]); }); function create_stripe_intent($request) { $amount intval($request-get_param(amount)); // 单位分 \Stripe\Stripe::setApiKey(STRIPE_SK); $intent \Stripe\PaymentIntent::create([ amount $amount, currency usd, automatic_payment_methods [enabled true], ]); return [clientSecret $intent-client_secret]; }逻辑说明amount 必须用最小货币单位美元是分传 1999 代表 19.99 美元传错单位是新手最常见的翻车点。automatic_payment_methods 打开后Stripe 会根据用户地区自动展示卡、Apple Pay、Google Pay 等不用自己判断。client_secret 返回给前端是安全的它只能用于确认这一笔 Intent。前端部分// 初始化 Elements 并挂载到页面容器 const stripe Stripe(STRIPE_PK); const elements stripe.elements({ clientSecret }); const paymentElement elements.create(payment); paymentElement.mount(#payment-element); // 提交时确认支付 async function handleSubmit(e) { e.preventDefault(); const { error } await stripe.confirmPayment({ elements, confirmParams: { return_url: window.location.origin /order-success }, }); if (error) showError(error.message); }参数说明clientSecret 从后端接口拿return_url 是 3D Secure 验证完成后跳回的地址必须是你站点内的合法 URL否则 Stripe 会拒绝。confirmPayment 会自动处理需要额外验证的卡片用户会看到一个弹窗或跳转这是正常流程不是 bug。3.2 PayPal Buttons 的内嵌渲染PayPal 的内嵌用 JS SDK 的 Buttons 组件createOrder 回调里调后端创建订单onApprove 里捕获并确认。paypal.Buttons({ createOrder: async () { const res await fetch(/wp-json/shop/v1/paypal-create, { method: POST }); const data await res.json(); return data.id; // PayPal 订单 ID }, onApprove: async (data) { await fetch(/wp-json/shop/v1/paypal-capture, { method: POST, body: JSON.stringify({ orderID: data.orderID }), }); window.location.href /order-success; } }).render(#paypal-button-container);后端 create 和 capture 两步分别对应 PayPal Orders API 的创建和捕获。注意 capture 才是真正扣款的动作createOrder 只是锁定金额和商品。如果只 create 不 capture钱不会动订单会停在 CREATED 状态。这个设计是为了让你在 capture 前做库存校验、风控判断。3.3 内嵌模式的订单状态同步内嵌模式下前端确认成功不等于订单已入库。正确做法是前端拿到成功回调后只负责跳转真正的订单状态更新由 Webhook 驱动。Stripe 监听 payment_intent.succeededPayPal 监听 PAYMENT.CAPTURE.COMPLETED。这样即使前端跳转失败、用户关页面Webhook 仍会把订单标记为已支付避免掉单。4. 跳转模式实战Checkout Session 与 PayPal Redirect4.1 Stripe Checkout 的会话创建跳转模式最省事的是 Stripe Checkout后端创建一个 Session返回 URL前端直接跳。function create_checkout_session($request) { \Stripe\Stripe::setApiKey(STRIPE_SK); $session \Stripe\Checkout\Session::create([ mode payment, line_items [[ price_data [ currency usd, product_data [name 年度会员], unit_amount 9900, ], quantity 1, ]], success_url home_url(/order-success?id{CHECKOUT_SESSION_ID}), cancel_url home_url(/order-cancel), ]); return [url $session-url]; }参数说明mode 为 payment 是一次性付款订阅要改成 subscription 并配 price_id。success_url 里的 {CHECKOUT_SESSION_ID} 是 Stripe 的占位符会替换成真实会话 ID用它去后端查订单状态最可靠别只信 URL 上的自定义参数。cancel_url 是用户主动取消时回跳的地址建议在这里提示「订单未完成」并保留购物车。4.2 PayPal Redirect 的订单流PayPal 跳转用 Orders API 的 approve 链接// 创建订单后取 approve 链接 $response wp_remote_post(https://api-m.sandbox.paypal.com/v2/checkout/orders, [ headers [ Authorization Bearer . $access_token, Content-Type application/json, ], body json_encode([ intent CAPTURE, purchase_units [[ amount [currency_code USD, value 99.00], ]], application_context [ return_url home_url(/paypal-return), cancel_url home_url(/paypal-cancel), ], ]), ]);逻辑说明intent 为 CAPTURE 表示创建后立即准备捕获。返回体里 links 数组中 rel 为 approve 的 href 就是跳转地址。用户付款后回到 return_url你在那里调 capture 接口完成扣款。注意 return_url 只是「用户回来了」不代表「钱到了」必须再调一次 capture 确认。4.3 两种模式的回调差异与幂等处理跳转模式的回调比内嵌更容易出问题因为用户可能中途关页面、网络中断、重复刷新 return_url。幂等处理是必须的每次处理 Webhook 或 capture 前先查订单当前状态已支付就直接返回成功不重复扣款、不重复发货。function mark_order_paid($order_id, $txn_id) { $order wc_get_order($order_id); if ($order-is_paid()) return; // 幂等已支付直接跳过 $order-payment_complete($txn_id); $order-add_order_note(支付完成交易号 . $txn_id); }这段逻辑看着简单但少了 is_paid 判断重复 Webhook 就会重复发货是真实踩过的坑。5. 避坑与排查支付回调里最容易翻车的五件事5.1 Webhook 签名验证失败现象Stripe 后台显示 Webhook 返回 400日志里写 signature verification failed。原因通常是用了错误的 Webhook Secret或者服务器读取原始请求体时被框架改动了。WordPress 里要用 php://input 读原始 body不能用 $_POST。$payload file_get_contents(php://input); $sig_header $_SERVER[HTTP_STRIPE_SIGNATURE] ?? ; try { $event \Stripe\Webhook::constructEvent($payload, $sig_header, STRIPE_WEBHOOK_SECRET); } catch (\Exception $e) { http_response_code(400); exit; }解决确认 Webhook Secret 是端点对应的那个每个端点独立并确保读的是原始 body。5.2 金额单位传错导致扣款异常现象测试时扣了 19.99 美元实际应该扣 1999 美元或者反过来扣了 0.19。原因Stripe 用分PayPal 用元两者单位不同。解决在代码里统一用「分」做内部计算调 PayPal 前再除以 100 转成字符串且保留两位小数。5.3 沙箱与生产环境混用现象测试全过上线第一单就失败。原因密钥没换、Webhook 端点还指向测试地址、商品价格是测试价。解决上线前做一张检查清单逐项核对密钥前缀pk_live / sk_live、API 基址、Webhook URL、货币代码。5.4 3D Secure 验证中断导致订单悬挂现象用户完成验证后没回到站点订单停在 pending。原因return_url 配置错误或用户手动关闭了验证页。解决依赖 Webhook 而非前端跳转来更新订单状态前端跳转只做展示。5.5 重复 Webhook 造成重复发货现象同一笔订单发了两次货。原因支付网关会重试 Webhook你的处理逻辑没有幂等判断。解决如 4.3 所示处理前先查订单状态已支付直接返回 200。6. 进阶技巧用 Webhook 日志反推支付链路跑通基础流程后真正提升排错效率的是把 Webhook 日志结构化。我习惯在数据库里建一张表记录每次回调的事件类型、订单号、原始 payload 和处理结果出问题时按订单号一查就知道卡在哪一步。CREATE TABLE wp_payment_webhook_log ( id BIGINT AUTO_INCREMENT PRIMARY KEY, gateway VARCHAR(20), event_type VARCHAR(60), order_id BIGINT, payload LONGTEXT, status VARCHAR(20), created_at DATETIME DEFAULT CURRENT_TIMESTAMP );写入时用 $wpdb-insertstatus 记 success / failed / duplicate。这样当用户说「我付了但没发货」你先查这张表如果连 Webhook 记录都没有说明网关没回调去检查端点可达性如果有记录但 status 是 failed看 payload 里的错误码如果是 duplicate说明幂等生效了订单其实已处理。验证方法上Stripe 提供 CLI 工具可以在本地转发 WebhookPayPal 有 Webhook Simulator 可以手动触发事件。上线前我一般会把所有事件类型各模拟一遍确认每种都能正确落库。还有一个习惯每次改完支付相关代码强制走一遍「沙箱下单 → 回调 → 订单状态核对 → 退款」全流程不跳过任何一步。支付这东西测试时偷的懒上线后都会以掉单的形式还回来。希望帮到你。本文还有配套的精品资源点击获取