指南
状态页面Dashboard预约演示
开始键入搜索...

分账支付市场

该功能允许商家在多个收款人之间拆分付款，这对于需要在不同卖家或利益相关者之间拆分交易的市场模式尤为有用。商家可以指定付款的分割方式，包括金额、收款人和任何适用的费用。

分批支付功能取决于所选支付提供商的支持。Yuno 只是支付的协调者，而不是处理者。在使用此功能之前，请确保您的提供商支持分批支付。

主要特点

分账支付市场的主要特点包括

  • 分割付款：定义如何在不同收款人之间分配付款总额。
  • 灵活配置：支持绝对分割。
  • 与供应商集成：支持该功能的支付提供商可执行分账。
  • 详细处理费用：系统允许对交易费用和退款的管理方式进行微调。
  • 入职转移：允许在不同接收方之间转移登机信息。

要使用此功能，您必须先将收款人加入付款分账，然后创建付款，并指定必要的信息。

1.入职

Yuno 的入驻模式旨在帮助市场无缝连接和管理其跨多个支付提供商的子商家。该系统的核心是收款人对象，它代表市场生态系统中的每个子商家。

  • 每个市场所有者在Yuno 中都是一个组织的代表。
  • 在一个组织内，可以创建一个或多个账户，每个账户都配置有自己的一套与支付提供商（如 Stripe、Adyen、dLocal）的连接。
  • 对于每个账户，市场都可以注册一个或多个收件人，这些收件人就是要加入的潜客。
  • 然后，每个收款人都会被单独链接到一个或多个连接，这取决于他们将使用哪种支付处理器。

这种架构可以

  • 统一的入职流程。
  • 对每个提供商进行独立的状态跟踪。
  • 在不同供应商之间轻松扩展子商户业务。

这种设计确保了整个入驻生命周期的灵活性、透明度和全面可追溯性。收件人endpoint用于创建和管理每个子商家档案，并触发相应的供应商特定入驻工作流程。

上岗流程

Yuno 为次级商户提供两种入职流程，可根据次级商户与支付提供商的当前状态灵活调整。

  1. 预注册账户:如果子商家已完成与特定供应商的入驻流程（如通过外部仪表板或平台），市场可提供相应的 recipient_id 在创建过程中。在这种情况下，无需进一步登录，状态将立即设置为 SUCCEEDED (onboardings.type=PREVIOUSLY_ONBOARDED).

  2. 动态入职:如果没有提供证书，Yuno 将启动所选提供商的入职流程 (onboardings.type=ONE_STEP_ONBOARDING 或 TWO_STEP_ONBOARDING).这一过程可能包括

    1. 提交表单或重定向至托管的入职页面。
    2. 上传法律或财务文件。
    3. 完成 KYC/KYB 验证步骤。

在整个入职生命周期中，收件人可能会经历各种状态，这些状态反映了流程的当前状态：

现状说明
CREATED创建后的初始状态；入职流程尚未启动。
PENDING数据提交后等待提供方审查。
SUCCEEDED收件人已完全入职并处于活动状态。
DECLINED提供商拒绝登机，无法重试。
BLOCKED由于合规问题，提供商已明确阻止入职。
CANCELED入职程序在完成之前被主动取消。
REJECTED由于数据不正确或验证失败，上机失败。
ERROR入职流程中出现技术错误。

这些状态有助于市场了解入职生命周期，并在必要时实施适当的重试、警报或后备机制。

这种灵活的方法允许市场根据其运营需求定制入驻流程，同时保持控制力和可视性。

工作流程

入驻工作流程遵循结构化流程，确保次级商家正确融入市场生态系统。下图展示了从初始设置到付款处理的完整流程。

工作流程步骤：

  1. 组织和账户设置：市场所有者在 Yuno 中创建一个组织，并配置与支付提供商连接的账户。

  2. 创建收件人：对于每个子商家，市场会使用创建收件人 API endpoint 创建收件人，并指定其中之一：

    • provider_recipient_id 用于预先登船的潜水员
    • 新入网的提供商连接详情

  3. 入职执行：

    • 预登机:状态立即变为 SUCCEEDED
    • 新人入职:Yuno 启动针对医疗服务提供者的流程，状态从 CREATED → PENDING → SUCCEEDED

  4. 创建付款:一旦收件人成功登录 (SUCCEEDED 状态），市场可以用 split_marketplace 反对

  5. 分账处理：支付提供商根据定义的分配执行分账，将资金转入每个收款人指定的份额。

2.付款分账整合

在本节中，我们将探讨 split_marketplace 对象用于划分一个 payment 在多个收款人之间分配。该对象是一个数组，每个条目指定一个收款人及其相应的付款份额。

ℹ️

在此步骤中，请参考步骤 1（入职）中创建的收件人。

对于 type = PURCHASE 或 MARKETPLACE包括 recipient_id 该收件人的。

对于 PAYMENTFEE, VAT 和 COMMISSION, recipient_id 是可选的。

现场

类型

说明

强制性

示例值

recipient_id

string

中收件人的唯一标识符。

在以下情况下使用步骤 1（入职）中创建的收件人 ID type 是 PURCHASE 或 MARKETPLACE.

有条件

rec_test123

provider_recipient_id

string

付款提供商提供的收款人 ID（如适用）。

有条件

prov_rec_abc

请注意：

您必须提供 recipient_id 或 provider_recipient_id.

对于市场业主 (type=COMMISSION), provider_recipient_id 如果提供方不要求，则为可选项。

type*

enum

交易明细项目类型。选项包括 PURCHASE, PAYMENTFEE, VAT, COMMISSION, MARKETPLACE.

recipient_id 对于 PURCHASE 和 MARKETPLACE.

有条件

PURCHASE

请注意：

传播方面的考虑

  • 只有当提供方支持传输详细信息时，才会向其发送项目

  • 这些类型不会影响资金支付，在提供方允许的情况下，它们只是提供信息而已


merchant_reference

string

支付交易的标识符。这是可选项。如果未指定，所有拆分交易都将使用主支付的商户编号。(最多 255 个字符；最少 3 个字符）。

没有

AAB01-432245

amount*

struct

指定分割的金额。

是

    value*

number

拆分的货币价值（例如，7500 换 75.00）。

是

7500

    currency*

enum

付款所用货币（ISO 4217，3 个字符）。

是

COP

liability

struct

有关收件人费用和扣款责任的信息（如适用）。

没有

    processing_fee

enum

指定由谁承担交易费： MERCHANT, RECIPIENT, SHARED.

没有

MERCHANT

    chargebacks

boolean

表示收款人是否对扣款负责 (true 如果他们有责任的话）。

没有

false


{
  "split_marketplace": [
    {
      "provider_recipient_id": "recipient_123",
      "type": "PURCHASE",
      "amount": {
        "value": 750,
        "currency": "EUR"
      }
    },
    {
      "type": "COMMISSION",
      "amount": {
        "value": 30,
        "currency": "EUR"
      }
    }
  ]
}
{
  "split_marketplace": [
    {
      "recipient_id": "4b31a9b8-4cd2-4e47-93cf-03729241bd68",
      "type": "PURCHASE",
      "amount": {
        "value": 750,
        "currency": "EUR"
      }
    },
    {
      "recipient_id": "9104911d-5df9-429e-8488-ad41abea1a4b",
      "type": "COMMISSION",
      "amount": {
        "value": 30,
        "currency": "EUR"
      }
    }
  ]
}

3.入职转移

该流程的目标是以可控和可逆的方式在接收者之间转移登机牌。

该过程分为几个阶段。首先，创建初始收件人，并进行入职（前一步）。之后，当需要转账时，按照步骤创建新收件人、使用转账服务，并在需要时进行反向操作。

  1. 收件人和入职（在任何转账之前）：创建接收人，然后创建上机。
📘

这一步骤在创建新的收件人并指定其加入时提前进行。这不是转账本身的一部分。

如果您决定将入职转给另一个接收者，请继续流程：

  1. 创建新收件人和上线：使用创建收件人和创建上机 endpoints 来设置接收转账的收件人和上机。

  2. 转移上机：使用转接上机，包括

    • recipient_id：目标收件人 ID
    • onboarding_id负责部门：入职到转岗

    入职信息将转给新的接收者。

  3. 反向传输（可选）:使用 反向入职 恢复以前的转让，条件是同样的 recipient_id 和 onboarding_id.

"(《世界人权宣言》) onboarding 对象包括一个 history 元素，可存储入职的完整可追溯性。该历史记录不仅包括对象的更新，还包括与接收者之间转移相关的事件，从而确保整个生命周期的可视性。

验证

在本节中，我们将概述确保成功拆分支付所需的验证。

  • 所有分账总额必须与总付款额一致。
  • 每次分账时，必须为每个参与者发送一个对象，确保金额总和等于付款总额。
  • 在不需要市场所有者直接提供收件人 ID 的情况下（如 Adyen），可使用 type 字段可作为标记（例如："......"）、 COMMISSION) 来表示市场所有者的份额，从而使 provider_recipient_id 对于特定的分割来说是可选的。
  • 要么 recipient_id 或 provider_recipient_id 必须包括分割，但不能同时包括。
  • 如果缺少任何必填字段或字段无效，请求将出错。
  • 如果使用多个付款提供商进行拆分付款，我们建议使用收款人对象，因为它允许为每个收款人定义多个提供商。

涉及的应用程序接口endpoints

本节列出了管理分批支付所涉及的 APIendpoints 。

  • 创建收件人: 职位: https://api-sandbox.y.uno/v1/recipients
  • 创建上岗培训: 职位: https://api-sandbox.y.uno/v1/recipients/{recipient_id}/onboardings
  • 继续入职培训: 职位: https://api-sandbox.y.uno/v1/recipients/{recipient_id}/onboardings/{onboarding_id}/continue
  • 创建payment: 职位: https://api-sandbox.y.uno/v1/payments
  • 捕获授权: 职位: https://api-sandbox.y.uno/v1/payments/{id}/transactions/{transaction_id}/capture
  • 退款支付: 职位: https://api-sandbox.y.uno/v1/payments/{id}/transactions/{transaction_id}/refund
  • 取消或退还付款: 职位: https://api-sandbox.y.uno/v1/payments/{id}/cancel-or-refund
  • 取消或退还交易付款: 职位: https://api-sandbox.y.uno/v1/payments/{id}/transactions/{transaction_id}/cancel-or-refund
  • 转岗上岗: 职位: https://api-sandbox.y.uno/v1/recipients/{recipient_id}/onboardings/{onboarding_id}/transfer
  • 反向登机转移: 职位: https://api-sandbox.y.uno/v1/recipients/{recipient_id}/onboardings/{onboarding_id}/reverse-transfer

3 个月前已更新