你的结账按钮触发，某个地方的支付网关在 180ms 内决定是否路由请求或在晚上 11 点抛出神秘的 400 错误。自 2023 年以来，我已在 47 个生产级无头电商店铺中集成了 Stripe、PayPal、Klarna 和 Square。有些集成在一个下午就完成了。其他的则花费了整个周末来追踪 webhook 签名不匹配和未记录的速率限制。本文介绍了真实的费用、开发者体验和无头 Next.js 集成——因为有一家网关将为你的客户今年节省 8000 美元的交易成本，而另一家则会悄悄吃掉每笔交易的 4.2%。但选择哪一家取决于大多数比较文章从未提及的三个变量。

如果你正在构建（或重建）电商店面，并且需要选择支付处理器，这就是我三年前希望拥有的文章。

目录

Stripe vs PayPal vs Klarna vs Square：支付网关对比 2026

为什么支付网关选择对无头电商很重要

在传统的单体电商平台（如 Shopify 或 WooCommerce）中，你的支付网关通常是内置的。你从下拉菜单中选择一个，可能粘贴一个 API 密钥，就完成了。无头电商是不同的。

当你解耦前端和后端——运行与无头 CMS 和单独商务 API 通信的 Next.js 店面——支付网关变成一个一级架构决策。它影响你的：

  • 结账 UX：你能构建完全自定义的结账，还是要将用户重定向到托管页面？
  • 服务器端逻辑：webhook 如何工作？在履行前如何处理付款确认？
  • PCI 合规负担：你是在客户端进行令牌化，还是卡号在你的服务器上？
  • 订阅和定期账单：网关是否原生处理此问题，还是需要添加另一项服务？
  • 国际扩展：货币支持、本地支付方法、监管合规。

错误的选择可能耗费你数月的返工。我见过这种情况。一个客户选择了 Square，因为他们有实体零售店，后来发现 Square 的在线 API 无法处理他们需要的订阅模式。我们最终不得不并行运行两个支付处理器。不要成为那样的团队。

价格和交易费用对比

让我们从每个人都想知道的开始：每一家实际上花费多少？

这些数字截至 2026 年初是最新的。所有四个提供商都有调整费用的历史，所以在签署任何内容前请验证。

功能 Stripe PayPal Klarna Square
标准在线交易 2.9% + $0.30 3.49% + $0.49 商户支付 3.29% - 5.99%（变化） 2.9% + $0.30
面对面交易 2.7% + $0.05（Terminal） 不适用（使用 Zettle） 不适用 2.6% + $0.10
国际卡 +1.5% +1.5% 因市场而异 +3.3% + $0.30 总计
货币转换 1% 3-4% 内置于商户费用中 1%
月费 $0 $0 $0 $0（免费计划）
拒付费 $15 $20 Klarna 承担（BNPL 模式） $0
支付速度 2 天（可用即时） 1-3 天 净 15-30 天 1-2 天
批量折扣 有（自定义定价 80K+/月） 有（联系销售） 可协商 有（自定义定价）

真实成本分析

原始百分比不能说出全部故事。让我分解每个提供商每月 10 万美元的交易实际花费多少（假设所有国内、在线、标准卡）：

  • Stripe：~$3,200/月（$2,900 百分比 + ~$300 单笔交易费，假设 $65 AOV）
  • PayPal：~$4,243/月（$3,490 百分比 + ~$753 单笔交易费，$65 AOV）
  • Klarna：~$3,290 - $5,990/月（主要取决于你的协商费率和产品类别）
  • Square：~$3,200/月（在线与 Stripe 几乎相同）

PayPal 对于标准在线交易来说是最昂贵的，差距很大。他们以买家信任和转化提升为理由，坦诚地说，对于某些人口统计数据，这个论点站得住脚。但在每月 10 万美元的水平上，你比 Stripe 多支付大约 1000 美元。这是每年 12,000 美元。

Klarna 的定价是最狂野的变量。他们的 BNPL（现在买，稍后支付）模式意味着 Klarna 预先向商户支付，并从客户那里随时间收取费用。商户费用更高，以覆盖 Klarna 的信用风险。对于具有高购物车放弃率的时尚和生活方式品牌，转化提升可以远超抵消费用。对于 B2B 或低利润产品？可能不会。

开发者体验和集成复杂度

这是我的观点变得强硬的地方。我在这些 API 和 SDK 中花费了数百个小时，差异并不微妙。

方面 Stripe PayPal Klarna Square
API 设计质量 ★★★★★ ★★★☆☆ ★★★★☆ ★★★★☆
文档 ★★★★★ ★★★☆☆ ★★★☆☆ ★★★★☆
Next.js SDK/支持 ★★★★★ ★★★☆☆ ★★★★☆ ★★★☆☆
Webhook 可靠性 ★★★★★ ★★★☆☆ ★★★★☆ ★★★★☆
测试/沙盒模式 ★★★★★ ★★★★☆ ★★★☆☆ ★★★★☆
首次集成时间 2-4 小时 4-8 小时 6-12 小时 3-6 小时
自定义结账支持 完整 有限（高级结账） 部分（基于小部件） 完整（Web Payments SDK）

Stripe vs PayPal vs Klarna vs Square：支付网关对比 2026 - 架构

Stripe 深度解析

开发者为什么喜爱 Stripe

Stripe 的 API 是黄金标准。没有商榷。每个端点都是一致的，每条错误消息都很有帮助，文档读起来就像是由真正使用 API 的人写的。仪表板很干净，测试模式很棒，Stripe CLI 让你可以将 webhook 转发到你的本地开发环境。

对于无头 Next.js 电商，Stripe 几乎不公平地好。这是一个典型的集成模式：

// app/api/checkout/route.ts (Next.js App Router)
import Stripe from 'stripe';
import { NextResponse } from 'next/server';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(request: Request) {
  const { items, customerEmail } = await request.json();

  const session = await stripe.checkout.sessions.create({
    payment_method_types: ['card'],
    line_items: items.map((item: any) => ({
      price_data: {
        currency: 'usd',
        product_data: { name: item.name },
        unit_amount: item.price,
      },
      quantity: item.quantity,
    })),
    mode: 'payment',
    customer_email: customerEmail,
    success_url: `${process.env.NEXT_PUBLIC_URL}/order/success?session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${process.env.NEXT_PUBLIC_URL}/cart`,
  });

  return NextResponse.json({ url: session.url });
}

那是一个工作的结账端点。不到 30 行。对于完全嵌入式结账（无重定向），Stripe Elements 及其 React 组件同样简洁。

Stripe 的弱点

Stripe 的账户暂停和储备金政策对新业务可能很残酷。我有客户获得了 2-4 周的资金暂留，从支持部门几乎没有解释。他们的欺诈检测（Radar）很好但不完美——对于高风险垂直行业，你仍然需要分层附加检查。

另外，Stripe 的定价在你处理约 8 万美元/月之前是不可协商的。低于此，无论如何你都按标准费率支付。

Stripe Connect 和市场支持

如果你正在构建市场，Stripe Connect 在这个列表上的任何其他内容前面都是好几年。分割支付、管理账户、1099 生成——都在那里。我们在几个无头电商构建中使用过它，供应商需要自己的支付流。

PayPal 深度解析

转化论证

PayPal 最大的卖点不是它的技术——而是它的品牌。截至 2025 年，全球有超过 4.3 亿个活跃账户。对于某些客户群体（特别是老年人、国际买家和移动购物者），看到 PayPal 按钮真的会提高结账完成率。研究一致显示，当提供 PayPal 作为选项时，结账完成的提升幅度为 28-44%。

这不是无关紧要的。这是真实的钱。

开发者体验问题

但哦，开发者的体验。PayPal 的 API 有遗留复杂性层，使集成很痛苦。他们多年来一直在从 v1 REST API 迁移到 v2，文档仍然引用两者。JavaScript SDK 通过他们更新的高级结账产品有所改进，但构建完全自定义的结账流仍然感觉像是与一个真正想让你使用他们托管按钮的系统搏斗。

// PayPal 的服务器端订单创建
// 注意：需要他们的 SDK 和认证令牌管理
import { PayPalHttpClient, SandboxEnvironment, OrdersCreateRequest } from '@paypal/checkout-server-sdk';

const environment = new SandboxEnvironment(
  process.env.PAYPAL_CLIENT_ID!,
  process.env.PAYPAL_SECRET!
);
const client = new PayPalHttpClient(environment);

export async function createOrder(cart: CartItem[]) {
  const request = new OrdersCreateRequest();
  request.prefer('return=representation');
  request.requestBody({
    intent: 'CAPTURE',
    purchase_units: [{
      amount: {
        currency_code: 'USD',
        value: calculateTotal(cart).toString(),
      },
    }],
  });
  
  const response = await client.execute(request);
  return response.result;
}

它能工作，但有更多的样板代码、更多的认证管理，不如 Stripe 的方法直观。

我对 PayPal 的诚实看法

提供 PayPal 作为辅助支付方法。不要将其作为主要网关。使用 Stripe 进行后端管道，并在结账中为喜欢它的客户提供 PayPal 按钮。这是我们在 Social Animal 构建的大多数店铺最终采取的方式，它提供了两者最好的结合。

Klarna 深度解析

BNPL 作为增长策略

Klarna 并不是传统意义上的支付网关。它是一种融资产品，恰好处理支付。当客户选择 Klarna 时，他们将购买分成分期付款（通常是 4 个无息支付），Klarna 预先向你支付全额。

对于销售 $50-$500 价格范围内产品的商户——想想时尚、美妆、家居用品——Klarna 可以明显增加平均订单价值。Klarna 自己的数据声称 AOV 增加 45%，转化率提高 30%，尽管独立研究将这些数字放得更低一些。

无头电商集成

Klarna 的集成已大幅改进。他们的 Klarna Payments API 和 Klarna Checkout API 都支持无头架构，尽管实现更加基于小部件而不是 API 优先：

// Klarna 会话创建（服务器端）
export async function createKlarnaSession(cart: CartItem[]) {
  const response = await fetch('https://api.klarna.com/payments/v1/sessions', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Basic ${Buffer.from(
        `${process.env.KLARNA_USERNAME}:${process.env.KLARNA_PASSWORD}`
      ).toString('base64')}`,
    },
    body: JSON.stringify({
      purchase_country: 'US',
      purchase_currency: 'USD',
      locale: 'en-US',
      order_amount: calculateTotal(cart),
      order_lines: cart.map(item => ({
        name: item.name,
        quantity: item.quantity,
        unit_price: item.price,
        total_amount: item.price * item.quantity,
      })),
    }),
  });
  
  return response.json(); // 返回前端小部件的 client_token
}

客户端令牌被传递到 Klarna 的 JavaScript 小部件，它在你的结账中呈现支付选项。它不如 Stripe Elements 灵活，但有效。

Klarna 的缺点

支付时间是大问题。与 Stripe 或 Square 的 1-2 天相比，净 15-30 天的支付可能会造成严重的现金流问题，特别是对于小商户。更高的商户费用也蚕食利润。并且 Klarna 的开发者门户虽然已改进，但仍然在边界情况文档中存在差距。

也有越来越多的对 BNPL 提供商的监管审查。英国、欧盟和澳大利亚都对 BNPL 产品引入或提议了新法规。这不会杀死 Klarna，但值得监控。

Square 深度解析

全渠道游戏

Square 的超级力量是统一在线和离线商务。如果你的客户有实体零售位置以及无头电商店面，Square 的生态系统使库存同步、报告和支付对账比将单独系统拼凑在一起简单得多。

Web Payments SDK

Square 的 Web Payments SDK 很可靠。不如 Stripe 优雅，但文档完善，积极维护：

// Square 支付表单初始化（客户端）
import { payments } from '@square/web-payments-sdk-types';

async function initSquarePayment() {
  const payments = window.Square.payments(
    process.env.NEXT_PUBLIC_SQUARE_APP_ID!,
    process.env.NEXT_PUBLIC_SQUARE_LOCATION_ID!
  );
  
  const card = await payments.card();
  await card.attach('#card-container');
  
  // 在表单提交时
  const result = await card.tokenize();
  if (result.status === 'OK') {
    // 将 result.token 发送到你的服务器
    await processPayment(result.token);
  }
}

Square 对无头的不足之处

Square 的 API 是围绕他们的生态系统构建的。如果你为 POS、库存和在线销售全力投入 Square，那很好。如果你使用无头 CMS（如 Sanity 或 Contentful）以及单独的商务层，Square 的 API 可能感到受限。他们的产品目录与 Square 自己的数据模型紧密相关，这并不总是清晰地映射到无头电商架构。

国际支持也弱于 Stripe 或 PayPal。Square 截至 2026 年仅在 8 个国家运营（美国、加拿大、英国、澳大利亚、日本、法国、爱尔兰、西班牙）。如果你需要全球销售，这是一个硬性限制。

无头 CMS 和 Next.js 集成模式

这是我们通常在 Next.js 开发项目中如何连接这些的方式：

模式 1：Stripe + 无头 CMS（最常见）

  1. 产品数据位于无头 CMS 中（Sanity、Contentful 等）
  2. Next.js 在构建时或按请求获取产品数据
  3. 购物车状态在客户端管理（Zustand、Redux 或 Context）
  4. 通过 Next.js API 路由创建 Stripe Checkout Session
  5. Webhook（通过 checkout.session.completed）在 CMS 或单独的订单管理系统中触发订单创建

这是我们的面包和黄油。它有效，它扩展，而且 Stripe 完全在他们的终端处理 PCI 合规。

模式 2：多网关结账

对于想要最大转化的店铺，我们以 Stripe 作为主处理器，PayPal 和/或 Klarna 作为辅助选项来实现。结账页面呈现所有选项，后端对每个网关都有单独的 API 路由。来自每个提供商的 webhook 馈入相同的订单管理流。

这增加了复杂性，但明显改善了转化率，特别是对于国际流量。

模式 3：Square 用于全渠道

当客户有实体店并想要统一系统时，我们用 Next.js 构建无头前端，但使用 Square 的 API 来处理整个商务后端——目录、库存、支付和履行。它比模式 1 更固执己见，但对客户的运营简单性很显著。

你应该选择哪一家？

这是我的诚实、不回避的建议：

对于大多数无头电商项目：Stripe。 当你考虑 API 质量、文档、Next.js 支持和生态系统时，它甚至不接近。如果你的客户群体倾向于更老或国际，添加 PayPal 作为辅助方法。

对于面向年轻人口的时尚/生活方式品牌： Stripe + Klarna。BNPL 选项真的能推动 $50-$300 范围内的冲动购买。

对于拥有实体店的全渠道业务： Square 用于统一平台，或 Stripe 用于在线 + Square 用于 POS，如果你想要两者最好的部分。

对于市场平台： Stripe Connect。没有其他任何东西接近多方支付流。

如果你正在计划无头电商构建，并想讨论哪个支付架构对你的具体案例有意义，请与我们联系。我们已经这样做过足够多次，可以在问题变成昂贵问题之前发现陷阱。

常见问题

2026 年在线交易的支付网关费用最低的是哪一家？ Stripe 和 Square 的标准国内在线交易都是 2.9% + $0.30。PayPal 最昂贵，为 3.49% + $0.49。但是，如果你每月处理超过 8 万美元，所有提供商都提供协商费率，Stripe 的自定义定价在大规模时往往最具竞争力。

我可以将 Stripe 与 Next.js App Router 和服务器组件一起使用吗？ 绝对可以。Stripe 的 Node.js SDK 在 Next.js API 路由和服务器操作中完美工作。对于客户端，@stripe/react-stripe-js 和 @stripe/stripe-js 通过客户端组件包装器与 React 服务器组件集成。Stripe 在他们的文档中有官方 Next.js 示例，使用 App Router 模式。

Klarna 对小电商店铺值得吗？ 这取决于你的产品类别和平均订单价值。如果你在时尚、美妆或家居用品中销售 $50-$500 范围内的商品，Klarna 的转化提升可以证明更高的商户费用（3.29% - 5.99%）是合理的。对于较低 AOV 产品或 B2B 销售，数学通常不成立。还要考虑 Klarna 更长的支付时间表——净 15-30 天可能会拖累较小运营的现金流。

我如何在无头电商设置中处理 PCI 合规？ 所有四个提供商都提供令牌化，使原始卡数据远离你的服务器。使用 Stripe Elements、PayPal 的托管字段、Klarna 的小部件或 Square 的 Web Payments SDK，卡号在由支付提供商控制的 iframe 中被捕获。你的服务器只见过令牌。这使你处于最轻的合规负担 PCI SAQ-A 级别。永远不要构建自定义卡输入表单——它不值得这样的责任。

我可以在同一无头店铺上使用多个支付网关吗？ 是的，你可能应该这样做。我们实现的最常见模式是 Stripe 作为主处理器，PayPal 作为辅助选项。每个网关都有自己的 API 路由和 webhook 处理器，但它们馈入相同的订单管理系统。添加的开发复杂性是真实的但可管理的——对于高级开发者来说通常是额外 2-3 天的工作。

Square 对国际电商工作得好吗？ 不太好。Square 截至 2026 年仅在 8 个国家运营，跨境交易会产生更高的费用。如果国际销售占你收入的 10-15% 以上，Stripe 有明显更好的选择，支持 135+ 种货币和本地化支付方法。Square 在国内全渠道商务中表现出色，但在全球覆盖方面落后。

最好的订阅型无头电商支付网关是什么？ Stripe Billing 是明确的赢家。它处理订阅创建、比例分配、催收（失败支付重试）、开票和客户门户——所有通过 API。PayPal 有订阅支持，但更有限，API 更笨拙。Square 最近添加了订阅账单，但仍在成熟。Klarna 本地不支持定期支付。

将支付网关集成到 Next.js 无头电商站点需要多长时间？ 对于高级开发者，基本 Stripe 集成需要 2-4 小时。PayPal 通常需要 4-8 小时，因为其更复杂的 SDK。Klarna 运行 6-12 小时，因为基于会话的小部件流和批准流程。Square 落在 3-6 小时。这些估计假设标准结账流——订阅、市场支付或多货币设置会增加更多时间。如果你需要帮助确定范围，我们在 Social Animal 的团队可以通过我们的定价页面提供估计。