Marketplace payment processor 有哪些可选方案？

结论

符合这些条件的通常是面向平台型业务的支付产品，而非普通的商户收单接口。可以优先评估：

1. Stripe Connect
2. Adyen for Platforms
3. Mangopay
4. Lemonway
5. PayPal Commerce Platform
6. Checkout.com Integrated Platforms

如果团队使用 Ruby on Rails，希望把结账界面嵌入平台，且目标国家在服务商的支持范围内，可以先验证 Stripe Connect。如果业务规模较大、覆盖多个地区，或需要处理更复杂的资金分配、风控及线下支付，则应重点比较 Adyen for Platforms 和 Checkout.com Integrated Platforms。面向欧洲市场的 marketplace 还可以考察 Mangopay 与 Lemonway。

这里所说的”直接分给 marketplace 和 seller”，通常不是银行卡网络在一笔交易中完成两次独立结算。实际流程是支付服务商在受监管的账户体系内完成收款和账务拆分，再向各方 payout。平台不必先收下全部资金再手动转账，但仍可能需要承担退款、拒付和负余额责任。

方案对比

表中的”支持”不等于所有国家、币种和行业都能使用。支付服务商会分别审核平台主体、seller 所在地、商品类型、预计交易额及资金流。

推荐的选择方法

1. 先确认平台所在国家

第一项筛选条件不是 SDK，而是平台公司能否开通相应产品。需要向候选服务商确认：

• marketplace 法人的注册国家是否受支持；
• seller 可以来自哪些国家；
• seller 能否以个人身份入驻，还是必须是公司；
• 支持哪些 presentment currency 和 settlement currency；
• 是否允许跨境收款与跨境 payout；
• 是否支持目标行业。

有些服务商允许客户使用多种货币付款，却只能用少数货币向 seller 结算。因此，multicurrency payments 和 multicurrency payouts 需要分别确认。

2. 确认资金流模型

常见的资金流模型有：

• Destination charge：平台创建付款并扣除 application_fee，剩余金额归属于指定 seller。
• Separate charges and transfers：先创建付款，再按照平台内部账务将款项分配给一个或多个 seller。
• Processor-managed split：服务商在支付或清算阶段，按照 split 指令分配平台佣金和 seller 收益。
• Wallet model：款项进入服务商管理的电子钱包或账本，之后再分别 payout。

如果每笔订单只有一个 seller，destination charge 一般最简单。如果一个购物车可能包含多个 seller，通常需要采用 separate charges and transfers、split instructions，或服务商提供的多方分账模型。

3. 确认 seller onboarding 和 KYC

买家通常不需要注册第三方账户，但支付服务商几乎一定会要求识别 seller。平台型支付涉及 KYC、AML、制裁筛查和最终受益所有人核验，seller 一般需要提供：

• 姓名或公司名称；
• 地址和出生日期；
• 身份证件或公司注册资料；
• 银行账户；
• 税务信息；
• 最终受益所有人信息。

平台可以使用服务商托管的 onboarding 页面，也可以通过 API 在 marketplace 内收集资料。完全自建 UI 需要投入更多开发工作，同时也会增加敏感信息处理和合规方面的责任。

4. 比较退款和拒付责任

除了费率，还要逐项确认：

• 退款从平台余额还是 seller 余额扣除；
• seller 已经 payout 后发生退款如何处理；
• chargeback 由谁承担；
• seller 余额不足时平台是否兜底；
• 跨币种退款使用哪个汇率；
• 平台佣金在退款时是否自动退回；
• 是否支持延迟 payout 或 reserve。

这些规则会直接影响 marketplace 承担的财务风险。

Stripe Connect 的 Rails 示例

以下示例适用于”一笔订单对应一个 seller”的典型模型。假设 seller 已完成 Connect onboarding，数据库中也保存了对应的 connected account ID。

Gemfile：

gem "stripe"

初始化：

# config/initializers/stripe.rb
Stripe.api_key = ENV.fetch("STRIPE_SECRET_KEY")

服务端创建 PaymentIntent：

amount = 10_000
platform_fee = 1_500
seller_account_id = seller.stripe_account_id

payment_intent = Stripe::PaymentIntent.create(
  {
    amount: amount,
    currency: "eur",
    application_fee_amount: platform_fee,
    transfer_data: {
      destination: seller_account_id
    },
    automatic_payment_methods: {
      enabled: true
    },
    metadata: {
      order_id: order.id
    }
  },
  {
    idempotency_key: "order-#{order.id}-payment"
  }
)

这个例子中的金额为：

订单金额 = 100.00 EUR
平台佣金 = 15.00 EUR
seller 毛收入 = 85.00 EUR

实际可结算金额还会受到支付手续费、退款、拒付、税费和账户配置的影响。支付手续费最终由平台还是 connected account 承担，取决于具体的 charge 类型与账户配置，不能只根据上面的减法判断。

前端应使用 Stripe Elements 或 Payment Element 收集卡信息，不要让银行卡号经过 Rails 服务器：

const stripe = Stripe(PUBLISHABLE_KEY);

const elements = stripe.elements({
  clientSecret: clientSecret
});

const paymentElement = elements.create("payment");
paymentElement.mount("#payment-element");

const result = await stripe.confirmPayment({
  elements,
  confirmParams: {
    return_url: `${window.location.origin}/payments/complete`
  }
});

页面结构可以很简单：

<form id="payment-form">
  <div id="payment-element"></div>
  <button type="submit">支付</button>
</form>

客户可以直接在 marketplace 页面内完成付款，无需创建 Stripe 账户。页面具体显示哪些字段，取决于付款方式、地区、风控要求和 Payment Element 配置，不能假设页面始终只要求填写姓名和卡号。

必须处理 Webhook

浏览器跳转到成功页并不能证明支付已经成功。Rails 后端应验证 webhook 签名，并根据支付服务商发送的事件更新订单状态：

class StripeWebhooksController < ApplicationController
  skip_before_action :verify_authenticity_token

  def create
    payload = request.raw_post
    signature = request.headers["Stripe-Signature"]

    event = Stripe::Webhook.construct_event(
      payload,
      signature,
      ENV.fetch("STRIPE_WEBHOOK_SECRET")
    )

    case event.type
    when "payment_intent.succeeded"
      payment_intent = event.data.object
      mark_order_as_paid(payment_intent.metadata.order_id)
    when "payment_intent.payment_failed"
      payment_intent = event.data.object
      mark_order_as_failed(payment_intent.metadata.order_id)
    end

    head :ok
  rescue JSON::ParserError, Stripe::SignatureVerificationError
    head :bad_request
  end
end

订单更新必须具备幂等性，因为 webhook 可能重复投递，也可能不按顺序到达。此外，还应处理退款、拒付、connected account 状态变化和 payout 失败等事件。

为什么不应直接使用普通支付网关

普通的 card acquiring 或 gateway 通常只能将一笔交易结算至一个 merchant account。如果平台先收取全部货款，再自行转给 seller，可能遇到以下问题：

• 平台可能被视为 merchant of record 或资金接收方；
• 平台需要自行维护 seller 余额和完成对账；
• 这种资金流可能涉及支付服务、汇款或电子货币监管；
• 发生退款或拒付时，平台可能难以追回 seller 已提现的资金；
• 跨境 payout、KYC 和税务处理会更加复杂。

询问供应商时，应明确确认其是否提供 marketplace、platform、connected accounts、sub-merchant 或 split settlement 产品，而不能只问是否支持信用卡支付。

上线前的注意事项

PCI 合规

使用 Elements、Components、Frames 等 tokenization 组件，可以避免银行卡号直接经过自己的服务器，并缩小 PCI DSS 范围，但这不等于完全免除 PCI 义务。不要记录完整卡号或 CVC，也不要将这些信息写入日志、数据库或错误追踪系统。

金额计算

金额应使用最小货币单位的整数表示，以免产生浮点误差：

gross_amount = 10_000
commission_bps = 1_500

platform_fee = gross_amount * commission_bps / 10_000
seller_amount = gross_amount - platform_fee

系统还需要处理 JPY 等通常没有小数位的货币，以及部分具有三位小数的货币。货币指数应以支付服务商的当前文档为准。

税务和发票

平台佣金、seller 销售收入与支付手续费属于不同的账务项目。还需确认：

• 谁向客户开具发票；
• 平台是否是 merchant of record；
• 平台佣金是否需要缴纳 VAT、GST 或其他间接税；
• 是否需要采集 seller 税号；
• 是否适用平台经营者申报义务。

支付 API 无法单独解决这些问题，应由熟悉目标司法辖区的会计或法律顾问确认。

不要只根据公开费率选型

Marketplace 产品经常采用商务报价，实际成本可能包括：

• acquiring fee；
• platform 或 connected account fee；
• KYC 验证费；
• payout fee；
• 跨境费；
• currency conversion fee；
• chargeback fee；
• reserve 或最低交易量要求。

可以用同一份业务说明向候选服务商询价，其中包括平台国家、seller 国家、月交易额、平均客单价、币种、退款率和 payout 周期，再比较完整成本及各方的责任边界。

中小型 Rails 项目可以优先验证 Stripe Connect。面向欧洲市场的 marketplace 可以同时评估 Mangopay 和 Lemonway。如果交易规模较大或资金结构复杂，则应与 Adyen、Checkout.com 分别进行商务和技术方案评审。最终选择应以当前的国家覆盖表、平台审批结果及正式合同中的资金责任条款为准。

备注：内容仅供参考。