Stripe vs PayPal vs Klarna vs Square:支付网关对比 2026
我已将这些支付网关中的每一个都集成到生产环保无头商务商店中。有些是一种享受。其他的让我在周五凌晨2点质疑我的职业选择。这不是从营销页面提取的表面级功能对比——这是针对2026年Stripe、PayPal、Klarna和Square的深入、有主见的对比分析,特别是从无头商务和Next.js开发的角度来看。
如果你正在构建(或重建)电子商务店面,需要选择支付处理商,这就是我三年前希望拥有的文章。
目录
- 为什么支付网关选择对无头商务很重要
- 价格和交易费用对比
- 开发者体验和集成复杂性
- Stripe 深入分析
- PayPal 深入分析
- Klarna 深入分析
- Square 深入分析
- 无头CMS和Next.js集成模式
- 你应该选择哪一个
- 常见问题

为什么支付网关选择对无头商务很重要
在Shopify或WooCommerce这样的传统整体电子商务平台中,你的支付网关通常是内置的。你从下拉菜单中选择一个,也许粘贴一个API密钥,就完成了。无头商务则不同。
当你将前端与后端解耦时——运行一个与无头CMS和单独商务API通信的Next.js店面——支付网关成为一个一流的架构决策。它会影响你的:
- 结账用户体验:你能构建完全自定义的结账流程,还是需要将用户重定向到托管页面?
- 服务器端逻辑: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天 |
| 交易量折扣 | 是的(8万+/月自定义定价) | 是的(联系销售) | 可协商 | 是的(自定义定价) |
真实成本分析
原始百分比不会说明全部情况。让我分解$100,000/月交易在每个提供商实际成本是多少(假设所有国内、在线、标准卡):
- Stripe:约$3,200/月($2,900百分比 + 约$300交易费,假设$65平均订单价值)
- PayPal:约$4,243/月($3,490百分比 + 约$753交易费,$65平均订单价值)
- Klarna:约$3,290 - $5,990/月(取决于你协商的费率和产品类别)
- Square:约$3,200/月(在线情况下与Stripe几乎相同)
PayPal在标准在线交易中价格最高,幅度很大。他们用买家信任和转换提升来证明这一点,坦诚地说,对于某些人群,这个论点是站得住脚的。但在$100K/月时,你比Stripe多支付约$1,000。那是$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 深入分析
为什么开发者喜欢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自己的数据声称平均订单价值增加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的缺点
支付时间是大问题。净15-30天的支付与Stripe或Square的1-2天相比,特别是对较小的商户来说,可能会产生严重的现金流问题。更高的商户费用也会蚕食利润。Klarna的开发者门户虽然改进了,但在边缘案例文档中仍有差距。
全球还有Klarna面临越来越多的监管审查。英国、欧盟和澳大利亚都为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是围绕他们的生态系统构建的。如果你全力投入Square进行POS、库存和在线销售,这很棒。如果你使用Sanity或Contentful这样的无头CMS和单独的商务层,Square的API会感觉受限。他们的产品目录深深绑定到Square自己的数据模型,这并不总是能够干净地映射到无头商务架构。
国际支持也比Stripe或PayPal弱。截至2026年,Square仅在8个国家运营(美国、加拿大、英国、澳大利亚、日本、法国、爱尔兰、西班牙)。如果你需要全球销售,这是一个硬性限制。
无头CMS和Next.js集成模式
这是我们通常如何在我们的Next.js开发项目中连接这些的:
模式1:Stripe + 无头CMS(最常见)
- 产品数据位于无头CMS中(Sanity、Contentful等)
- Next.js在构建时或按请求获取产品数据
- 购物车状态在客户端管理(Zustand、Redux或Context)
- 通过Next.js API路由创建Stripe Checkout Session
- 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 + POS用Square。
对于市场平台: Stripe Connect。对于多方付款流程,没有其他东西接近。
如果你正在规划无头商务构建,想讨论哪个支付架构对你的特定情况有意义,请与我们联系。我们已经做过足够多次,能够在问题变成昂贵的问题之前发现陷阱。
常见问题
2026年哪个支付网关在线交易费用最低? Stripe和Square在标准国内在线交易中持平,均为2.9% + $0.30。PayPal最贵,为3.49% + $0.49。但是,如果你每月处理超过8万美元,所有提供商都提供协商费率,Stripe的自定义定价往往在规模上最有竞争力。
我能将Stripe与Next.js App Router和Server Components一起使用吗?
绝对可以。Stripe的Node.js SDK在Next.js API路由和Server Actions中完美运行。对于客户端,@stripe/react-stripe-js和@stripe/stripe-js通过客户端组件包装器与React Server Components集成。Stripe在其文档中有使用App Router模式的官方Next.js示例。
Klarna对小电子商务商店值得吗? 取决于你的产品类别和平均订单价值。如果你在时尚、美容或家居用品类别中销售$50-$500范围内的商品,Klarna的转换提升可能证明更高的商户费用(3.29% - 5.99%)是合理的。对于较低平均订单价值的产品或B2B销售,数学通常不成立。还要考虑Klarna的更长支付时间表——净15-30天可能会给较小的运营造成现金流压力。
我如何使用无头商务设置处理PCI合规? 所有四个提供商都提供令牌化,将原始卡数据保留在你的服务器之外。对于Stripe Elements、PayPal的托管字段、Klarna的小部件或Square的Web Payments SDK,卡号在由支付提供商控制的iframes中捕获。你的服务器只会看到令牌。这使你处于PCI SAQ-A级别,这是最轻松的合规负担。永远不要构建自定义卡输入表单——不值得责任。
我能在同一个无头商店上使用多个支付网关吗? 是的,你可能应该这样做。我们实现最常见的模式是Stripe作为主要处理器,PayPal作为辅助选项。每个网关都有自己的API路由和Webhook处理器,但它们流入相同的订单管理系统。添加的开发复杂性是真实的,但可管理的——对于资深开发人员来说,通常需要额外2-3天的工作。
Square对于国际电子商务效果好吗? 不是很。截至2026年,Square仅在8个国家运营,跨境交易产生更高的费用。如果国际销售占你收入的10-15%以上,Stripe是有显著优势的选择,支持135+种货币和本地化的支付方法。Square擅长国内全渠道商务,但在全球覆盖方面落后。
最适合基于订阅的无头商务的支付网关是什么? Stripe Billing是明显的赢家。它处理订阅创建、按比例分配、催收(失败付款重试)、发票和客户门户——全部通过API。PayPal有订阅支持,但更受限,API更笨拙。Square最近添加了订阅账单,但仍在成熟中。Klarna原生不支持经常性付款。
将支付网关集成到Next.js无头商务站点需要多长时间? 对于资深开发人员,基本Stripe集成需要2-4小时。PayPal由于其更复杂的SDK通常需要4-8小时。Klarna运行6-12小时,因为基于会话的小部件流和审批流程。Square落在3-6小时。这些估计假设标准结账流程——订阅、市场付款或多货币设置添加了明显更多时间。如果你需要帮助范围确定这个,我们在Social Animal的团队可以通过我们的定价页面提供估计。