> ## Documentation Index
> Fetch the complete documentation index at: https://docs.li.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# 告别手动对账

> 让任何人都能用任意链上的任意资产付款，收款方收到发票金额，无需人工核对差额。

决定一款加密支付产品能否规模化的因素有两个：有多少付款方能完成付款，以及事后有多少笔付款需要人工处理。LI.FI 能同时改善这两点。付款方可以用自己持有的任何资产付款，而报价是从收款方必须收到的金额反向计算的，因此发票金额是一项保证，而不是一个估算值。

## 这为你的产品带来什么改变

> **对账工作不再随交易量增长**
>
> 从结算金额出发报价，收款方收到的金额至少等于你开具的发票金额。少付和多付从源头上就不再出现，因此你原本需要为处理这些问题而增加的人手也不再需要。

> **更多付款方能够付款**
>
> 在大多数集成中，付款方在错误的链上持有错误的资产就意味着一笔丢失的付款。在这里，它只是一笔普通的付款，这扩大了能够完成结账的人群。

> **更少的结账放弃**
>
> 兑换、转账和付款合并为一个流程，而不是三个独立的用户操作，每减少一个步骤，就少一个让用户流失的环节。

> **守住你的利润空间**
>
> 在以美元计价的资金流中，每一跳的损耗往往就是全部的利润空间，而且每次再平衡时都要再付一次。[Stablecoin 1:1](https://docs.li.fi/enterprise/stablecoin-1-1.md) 会按平价为符合条件的等价兑换定价，而不是依据资金池深度定价。

![正向报价从左向右展示，结算优先报价从发票金额出发从右向左展示](https://mintcdn.com/lifi/PmU0d85L8IwCXHK-/images/use-cases/settlement-first-quoting.png?fit=max\&auto=format\&n=PmU0d85L8IwCXHK-\&q=85\&s=559ec9230c86e920139f7d6264dba121)

发票是输入，付款方的金额是输出。

## 为什么正向报价会让你付出代价

商户在一条链上开具固定金额的发票。付款方在别的链上持有别的资产。常见的集成方式要求付款方先兑换、再转账、最后付款，而每一个步骤都可能让这笔付款被放弃。

正向报价让情况更糟。如果报价从付款方的余额出发，到账金额就取决于费用和滑点，于是商户会收到少付或多付的款项，需要人工处理差额。一天一笔付款时，这只是个小麻烦。一天一千笔时，就需要一个团队来处理。

> **正向报价**
>
> 你指定付款方发送的金额。收款方以少收款项的形式承担滑点，每一笔少付和多付都需要人工对账。

> **结算优先报价**
>
> 你指定收款方收到的金额。付款方在报价内承担差额，发票金额就是有保证的最低金额。

## 从结算金额出发

LI.FI 采用反向报价。你指定必须到账的金额，响应会告诉你付款方需要发送多少。中间的一切，包括转账费用和滑点，都会在付款方看到数字之前计入路由价格。路由会按照让收款方至少收到你指定金额的标准来确定规模，因此这个数字就是结算下限。预期到账金额通常会高于它，因为报价包含滑点缓冲，所以你的账本应预期出现不超过该缓冲的多付，而不是完全匹配。

对于基于求解器网络构建的流程，[LI.FI Intents](https://docs.li.fi/lifi-intents/introduction.md) 以订单的形式表达同样的思路：固定输出金额，由求解器计算交付该金额所需的输入。当目标金额至关重要时，请使用这种模式，而在支付场景中，目标金额始终至关重要。

> [!NOTE]
>
> 并非每笔付款都以一个地址为终点。为账户入账、铸造收据、释放托管资金：这些都以一次合约调用结束，只有该调用也执行了，这笔付款才有意义。LI.FI 可以在同一个流程中转移资金，并在目标链上执行你的调用。对于同链付款，转账和调用在同一笔交易中执行，因此任何一方都不会单独落地。对于跨链付款，目标链调用会在跨链桥结算之后运行，因此请在账本中把这两个阶段视为不同的状态，并根据转账的[状态](https://docs.li.fi/introduction/user-flows-and-examples/status-tracking.md)来驱动它们。

当一笔付款需要串联多个链上操作时，[Composer](https://docs.li.fi/composer/overview.md) 会在步骤之间进行校验并依次执行，消除那些让对账成本高昂的半完成状态。

## 导致付款流失的摩擦

以美元计价的转账需要与交易不同的路由默认设置。对波动性交易对来说合理的滑点容差，在付款中是不可接受的，而通用默认设置会在不告知任何人的情况下收取这部分差额。[稳定币预设](https://docs.li.fi/api-reference/presets/stablecoin.md)应用专为这种场景设计的默认设置：成本优先的排序、千分之一的滑点、价格冲击上限，以及一份经过审核、适用于稳定币转移的转账路径候选清单。凡是你自行设置的值，仍以你的设置为准。

> [!WARNING]
>
> 覆盖预设中的某个排除列表会替换该列表，而不是在其基础上扩展，因此部分覆盖可能会在不知不觉中重新启用预设已排除的路径。

另外两项较小的改进可以补上剩余的缺口。

> **[收款方无需冷启动](https://docs.li.fi/guides/gas-subsidy.md)**
>
> 对于首次在某条链上收款的收款方，可以随付款一同发送原生 gas，让他们之后能够转移资金，而不必提交支持工单。

> **[可嵌入的结账界面](https://docs.li.fi/widget/overview.md)**
>
> Widget 为你提供一个只需调整样式、无需从头构建的支付界面，可以让首次上线提前数周。

如果付款方没有原生代币是障碍所在，通过 [LI.FI Intents](https://docs.li.fi/lifi-intents/introduction.md) 提交订单不会让他们承担任何链上费用。为订单注资仍然是一项需要他们付费的链上操作。

## 上线前需要决定的事项

有两种结算结果需要在上线前做出决定，而且两者都是正常情况。

> **收款方收到的是相关资产，而不是发票所列资产**
>
> 这种情况发生在目标链兑换无法安全执行时。这是一笔成功的转账，只是附带的资产不同，因此你的发票逻辑需要在已付款和失败之间增加第三种状态。[中间代币](https://docs.li.fi/guides/intermediate-tokens.md)列出了会出现哪些资产以及何时出现。

> **转账退款给付款方**
>
> 资金会退回给付款方，始终不会到达收款方。发票应保持未结状态。仅凭一笔源链交易就将其标记为已付款，是一个日后发现时代价高昂的假设。

> **向付款方展示怎样的费用明细**
>
> 请基于报价自身的估算来构建费用明细，而不是把响应中的每一项费用数字相加。这些数组存在重叠，把它们相加会向你请求签名的人夸大总费用。

## 从哪里开始

结算优先报价与标准集成只差一个接口，因此最快见效的构建方式，是端到端地跑通一张从另一条链付款的发票。转账跑通后再添加目标链合约调用，然后是对账状态，最后是预设。

> **[精确金额报价](https://docs.li.fi/api-reference/get-a-quote-for-a-token-transfer-1.md)**
>
> 从必须到账的金额出发报价。

> **[跨链合约调用](https://docs.li.fi/api-reference/perform-multiple-contract-calls-across-blockchains-beta.md)**
>
> 将付款直接结算到一次合约调用中。

> **[稳定币预设](https://docs.li.fi/api-reference/presets/stablecoin.md)**
>
> 为可预测的稳定币执行调优的路由默认设置。

> **[快速开始](https://docs.li.fi/introduction/integrating-lifi/getting-started)**
>
> 选择一种集成方式，发起你的第一次调用。

> **[联系 LI.FI 团队](https://docs.li.fi/introduction/integrating-lifi/partnership-opportunities.md)**
>
> 告诉我们你的结算资产、链以及典型的付款规模。我们会确认符合条件的交易对，并确定商务条款。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.