比特币开发者指南（8)--支付流程

付款流程 付款流程包括消费者和收款人进行和接受付款以换取产品或服务的步骤。自商业启蒙以来，基本步骤没有改变，但技术已经改变。本节介绍收款人和消费者如何分别使用比特币进行请求和付款，以及如何处理拒付和定期付款等复杂情况。

比特币支付处理

上图从接收方的角度显示了使用比特币的支付处理，从新订单开始。以下小节分别描述了三个常见步骤和三个附带或可选步骤。

值得一提的是，每一步都可以使用第三方API和服务外包。

价格订单由于 satoshis 和本国货币（法定货币）之间的汇率波动，许多比特币订单都以法定货币定价，但在 satoshis，需要进行价格转换。

汇率数据可通过 Currency Exchange 提供的广泛使用的基于 HTTP 的 API 获得。一些组织还使用基于 HTTP 的 API 汇总来自多个交易机构的数据以创建索引价格。

任何使用汇率数据自动计算订单总额的应用程序都必须采取措施，以确保所报价格反映了聪的当前一般市场价值，或者应用程序可以接受太少的聪来销售产品或服务。或者，他们可以要求更多的 satoshis 并吓跑潜在消费者。

为确保最大限度地减少问题，您的应用程序可能希望从至少两个独立来源收集数据并进行比较，以了解它们之间的差异。如果差异很大，您的应用可以进入安全模式，直到人们可以评估情况。

如果汇率快速上升或下降，您可能还需要对应用程序进行编程以进入安全模式，这表明比特币市场可能存在问题，导致今天很难支付任何费用。

汇率不受比特币和相关技术的控制购买比特币怎么支付，因此没有新的或计划中的技术可以让您的程序更轻松地将订单总额从法定货币转换为聪。

由于汇率会随着时间的推移而波动，因此与法定货币挂钩的订单总额必须有一个到期时间，以防止消费者延迟付款，希望 satoshis 价格下降。目前使用最广泛的支付处理系统会在 10 到 20 分钟后过期。

更短的有效期会增加发票在收到付款之前到期的可能性，并且可能需要人工干预以请求额外付款或发起退款。较长的到期期限会增加汇款在收到付款之前大幅波动的机会。

请求付款 在请求付款之前，您的应用程序必须创建一个比特币地址，或从其他程序（如 Bitcoin Core）获取地址。比特币地址在交易部分有详细描述。该部分还描述了避免多次使用同一地址的两个重要原因，但第三个原因尤其适用于付款请求：

对于收到的每笔付款，使用单独的地址可以轻松确定哪些客户已为其付款请求付款。您的应用程序只需跟踪特定支付请求与其中使用的地址之间的关联，然后扫描区块链以查找匹配交易的地址。

以下小节详细介绍了以下四种提供消费者地址和支付金额的兼容方式。为了方便和兼容，建议您在付款请求中提供所有这些选项。

所有钱包软件都允许用户粘贴或手动输入地址并将其合并到支付屏幕中。这当然不方便 - 但它有有效的后备选项。几乎任何桌面钱包都可以与 Bitcoin:URI 相关联，因此消费者可以点击链接来预填支付屏幕。这也适用于许多移动钱包，但通常不支持基于 Web 的钱包，除非消费者安装浏览器扩展或手动配置 URI 处理程序。大多数移动钱包都支持以 QR 码编码的扫描比特币：URI，并且几乎所有钱包都可以显示它们接受付款。虽然在线订购很方便，但二维码对个人购物特别有用。最近的钱包更新支持新的支付协议，提供更高的安全性，使用 X.509 证书来验证收件人的身份，以及退款等其他重要功能。警告图标 警告：必须特别小心，以免收到的付款被盗。特别是，私钥不应存储在 Web 服务器上，支付请求应通过 HTTPS 或其他安全方法发送，以防止中间人攻击将攻击者的地址替换为比特币地址。

纯文本 要直接指定复制和粘贴的金额，您必须提供地址、金额和面额。您还可以指定优惠的到期时间。例如：

（注意：本节所有示例均使用测试网地址）

注明面额很重要。在撰写本文时，流行的比特币钱包软件默认为比特币 (BTC)、毫比特币 (mBTC) 或微比特币 (uBTC，“bits”)。广泛支持在每个单位之间进行选择，但其他软件也允许用户从以下部分或全部选项中选择面额：

比特币：URI

BIP21 中定义的比特币：URI 方案消除了面额混淆，并使消费者免于复制和粘贴两个单独的值。它还允许支付请求为消费者提供一些额外的信息。一个例子：

只需要地址，如果唯一指定，钱包会预先填写付款请求，然后让付款人输入指定的金额。金额始终为十进制比特币（BTC）。

其他两个参数得到广泛支持。 label 参数通常用于向钱包软件提供收款人的姓名。 message参数通常用于描述消费者的支付请求。标签和消息通常由卖家的钱包软件存储，但不会添加到实际交易中，因此其他比特币用户无法看到它们。标签和消息都必须是 URI 编码的。

所有四个参数一起使用，并带有适当的 URI 编码，如下面的包装示例所示。

可以扩展 URI 方案，如下面的支付协议部分所示，以包括新的可选参数和必需参数。在撰写本文时，除了上述四个之外，唯一广泛使用的参数是支付协议 r 参数。

接受任何形式的 URI 的程序必须在付款前征求用户的许可，除非用户明确禁用提示（小额支付可能就是这种情况）。

QR 码 QR 码是一种流行的比特币交换方式：个人、图像或视频之间的 URI。大多数移动比特币钱包应用程序和一些桌面钱包都支持扫描二维码以预填充其支付屏幕。

下图显示了相同的 Bitcoin:URI 在四个不同级别的纠错中编码为四个不同的比特币二维码。二维码可以包含标签和消息参数以及任何其他可选参数 - 但这里省略了可选参数，以使二维码更小，易于使用不稳定或低分辨率的移动摄像头扫描。

比特币二维码

纠错与校验和相结合，以确保比特币二维码免受数据丢失或无法成功解码意外更改，因此您的应用应根据可用空间选择适当的纠错级别来显示二维码。当空间有限时，低级损伤校正效果很好，四分位损伤校正有助于确保在高分辨率屏幕上显示时快速扫描。

支付协议 Bitcoin Core 0.9 支持新的支付协议。支付协议为支付请求添加了许多重要的特性： 不需要诸如“mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN”之类的无意义地址，但要求消费者提供来自接收方的 X.509 证书的支付通用名称 (CN) 描述，例如“ ”。

要使用支付协议请求支付，您可以使用扩展（但向后兼容）比特币：URI。例如：

支付协议除了 r 之外不需要上述任何参数，但您的应用程序可能会将它们包含在钱包程序中 其尚未处理的支付协议的向后兼容性。

r 参数指示支付协议感知钱包程序忽略其他参数并从提供的 URL 获取 PaymentRequest。浏览器、二维码阅读器或其他处理 URI 的程序会在 URI 上打开消费者比特币钱包程序。

BIP70 支付协议

支付协议在 BIP70、BIP71 和 BIP72 中有深入描述。开发人员示例支付协议小节中提供了示例 CGI 程序和可在支付协议中使用的所有参数的描述。在本小节中，我们将简要介绍支付协议通常如何以故事形式使用。

Charlie 客户，购买了 Bob 的商家运营的网站。 Charlie 在购物车中添加了一些商品，然后单击“使用比特币结帐”按钮。

Bob 的服务器会自动将以下信息添加到他的发票数据库中：将所有信息添加到数据库后，Bob 的服务器会显示 Charlie 的比特币：点击付款的 URI。

Charlie 在浏览器中单击 Bitcoin:URI。他的浏览器的 URI 处理程序将 URI 发送到他的钱包程序。钱包知道支付协议，因此它会解析 r 参数并向该 URL 发送 HTTP GET，以查找 PaymentRequest 消息。

返回的 PaymentRequest 消息可能包含私人信息，例如查理的电子邮件地址，但钱包必须能够在不使用先前身份验证的情况下访问它，例如 HTTP cookie，因此通常使用公开可用的防猜测组件 要访问的 HTTPS URL。为支付请求创建的唯一公钥可用于创建唯一标识符。这就是为什么在上面的示例 URI 中，PaymentRequest URL 包含 P2PKH 地址：

在收到对上述 URL 的 HTTP GET 后，Bob 的 Web 服务器上生成 PaymentRequest 的 CGI 程序从 URL 中获取唯一标识符，并在数据库中查找相应的详细信息。然后，使用以下信息创建 PaymentDetails 消息：

PaymentDetails 消息放置在 PaymentRequest 消息中。支付请求允许 Bob 的服务器使用服务器的 X.509 SSL 证书对整个请求进行签名。 （支付协议的设计是为了在未来允许使用其他签名方法。）Bob 的服务器向 Charlie 的钱包发送支付请求以响应 HTTP GET。

显示经过验证的付款请求的比特币核心

Charlie 的钱包接收到 PaymentRequest 消息，检查其签名，并将其从 PaymentDetails 消息 Details 中显示给 Charlie。 Charlie 同意付款，因此钱包构建了一个服务器来支付 pubkey 脚本提供的 Bob。与传统的比特币支付不同，查理的钱包不一定会自动将这笔支付广播到网络。相反，钱包构造了一条支付消息并将其作为 HTTP POST 发送到 PaymentDetails 消息中提供的 URL。其中： 支付信息包含： Bob 的服务器接收到支付消息，验证交易是否将请求的金额支付到提供的地址，然后将交易广播到网络。它还向 HTTP POSTed Payment 消息回复 PaymentACK 消息，其中包括来自 Bob 的服务器的可选备忘录，感谢 Charlie 的赞助，并提供有关订单的其他信息，例如预计到达日期。

Charlie 的钱包看到 PaymentACK 并通知 Charlie 付款已发送。 PaymentACK 并不意味着 Bob 已经验证了 Charlie 的付款 - 请参阅下面的验证付款部分，但它意味着 Charlie 可以在交易被确认后执行其他操作。在 Bob 的服务器从区块链验证 Charlie 的交易已被确认后，它会授权发送 Charlie 的订单。

如果发生争议，Charlie 可以根据各种签名或其他认证信息生成经过加密认证的收据。

如果需要退款，Bob 的服务器可以安全地支付 Charlie 提供的退款至 pubkey 脚本。有关详细信息，请参阅下面的退款部分。

验证付款 如交易和区块链部分所述，将交易广播到网络并不能确保收款人获得付款。恶意消费者可以创建一个支付给接收者的交易，以及另一个将相同输入支付给自己的交易。这些交易中只有一个会被添加到区块链中，没有人能确定它会是哪一个。

花费相同输入的两个或多个交易通常称为双重支出。

一旦一笔交易被包含在一个区块中，如果不修改区块链历史来替换该交易，就不可能进行双重支付，这是相当困难的。使用该系统，可以根据需要修改比特币协议以替换交易数量，为每笔交易提供更新的置信水平。对于每个区块，交易都会获得一次确认。由于修改区块非常困难，因此较高的确认分数表示更好的保护。

Bitcoin Core 提供了多个 RPC，它们可以为您的程序提供钱包中交易或任意交易的确认分数。例如，listunspent RPC 提供了一个包含每个 satoshi 的数组，您可以将其与确认分数一起使用。

虽然大多数时候确认提供了出色的双花保护，但至少在三种情况下需要进行双花风险分析：

当一个程序或其用户不能等待确认而想要接受未确认付款的情况下。如果程序或其用户接受高价值交易并且不能等待至少六次或更多确认。在长期实施漏洞或攻击比特币的情况下，使系统的可靠性不如预期。通过连接大量比特币对等方来跟踪交易和区块，可以获得一个有趣的双花风险分析来源。一些第三方 API 可以为您提供此类服务。

例如，可以在所有连接的节点之间比较未确认的交易，以查看是否在多个未确认的交易中使用了任何 UTXO，这表明尝试了双花，在这种情况下，可以拒绝付款，直到确认。还可以根据交易费用对交易进行排名，以估算它们被添加到区块之前的时间。

另一个例子可能是在多个对等点报告相同块高度之间的不同块头哈希时检测分叉。如果分叉延伸超过两个块，程序可以进入安全模式，表明区块链可能存在问题。有关详细信息，请参阅检测分叉小节。

双重支持保护的另一个良好来源是人类智能。例如，欺诈者的行为可能与合法客户不同，让精明的商家手动将其标记为高风险。您的程序可以提供一种安全模式，在全球或每个客户的基础上停止自动付款接受。

发起退款 偶尔使用您的应用程序的收件人将需要退款。非常不安全地执行此操作的明显方法是将 satoshis 返回到它们来自的 pubkey 脚本。例如：

这似乎应该可行，但 Alice 使用的集中式多用户网络钱包不会为每个用户提供唯一地址，因此无法知道 Bob 的退款是否适用于 Alice。现在购买比特币怎么支付，退款是对集中钱包背后公司的无意捐赠，除非 Alice 打开支持票并证明这些 satoshis 是给她的。

这使收款人只有两种正确的退款方式： 注意：如果在原始付款后很长时间退款，最好直接与发件人联系。这使您可以确保用户仍然可以访问refund_to 地址的一个或多个密钥。

支付收入（限制外汇风险） 许多收款人担心他们的 satoshis 在未来会比现在更值钱，这就是所谓的外汇（外汇）风险。为了限制外汇风险，许多收款人选择在收到新收据后立即付款。

如果你的应用程序提供了这个业务逻辑，你需要先选择输出。有几种不同的算法会导致不同的结果。

合并避免当接收者在输出中收到 satoshis 时，支出者可以（粗略地）跟踪接收者如何花费这些 satoshis。但是，只要接收方在每笔交易中使用唯一地址，消费方就无法自动看到其他消费者支付给接收方的其他 satoshis。

但是，如果接收方在同一笔交易中从两个不同的消费者那里花费了 satoshis，那么这些消费者中的每一个都可以看到另一个付款人的付款。这称为合并，接收者合并其输出的次数越多，外部人员就越容易跟踪接收者获得、消耗和保存了多少 satoshis。

避免合并意味着试图避免在同一交易中花费不相关的输出。对于希望将交易数据保密的个人和企业来说，这可能是一项重要的策略。

粗略的避免合并策略是尝试始终以最小的输出支付您要求的金额。例如，如果您有四个输出要持有，100、200、500 和 900 satoshis，您将支付 300 satoshis t2 > 500-satoshi 输出。这样，只要您的输出大于帐单，您就可以避免合并。

更高级的合并避免策略在很大程度上取决于对支付协议的增强，这将允许付款人通过在多个输出之间智能分配付款来按接收方进行合并。

后进先出 (LIFO) 输出甚至可以在确认之前接收一次。由于最近的输出是双倍的最大风险，因此在较旧的输出之前花费它们可以让花费者保留较旧的输出，这不太可能是双倍的。

LIFO 有两个密切相关的缺点：

在任何一种情况下，第二笔交易的接收者都会看到传入的交易通知消失或变成错误信息。

由于 LIFO 将二级交易的接收方作为一级交易的接收方，双花风险作为接收方，所以最好在二级接收方不关心风险的情况下使用，例如无论您使用旧输出还是新输出，都必须等待六次确认的交换或其他服务。

当重大交易的受益人的声誉可能面临风险时，例如在支付员工工资时，不应使用 LIFO。在这种情况下，最好在使用这些交易进行付款之前等待交易完全验证（请参阅上面的验证器）。

先进先出 (FIFO) 最旧的输出是最可靠的，因为它们接收的时间越长，需要修改的块就越多以使它们双花。然而，仅仅几个区块之后，就达到了收益迅速递减的点。假设攻击者拥有网络中总哈希算力的 30%，原始比特币论文预测攻击者将能够修改旧块的机会：

FIFO 在交易费用方面确实有一点优势，因为对于运行默认比特币核心代码库的矿工来说，较旧的输出可能有资格包含在 50,000 字节中，用于不需要的高优先级交易。然而，由于交易费用如此之低，这并不是一个显着的优势。

FIFO 的唯一实际用途是让收款人将其全部或大部分收入花在几个区块中，并希望减少他们的付款意外无效的可能性。例如，每笔付款的收款人持有六次确认，然后在两小时内向供应商和储蓄账户进行 100% 验证付款。

定期付款 去中心化比特币无法自动进行定期付款。即使钱包支持自动发送不可逆的付款，用户仍然需要在指定时间启动程序，或者保持程序不加密运行。

这意味着自动重复的比特币支付只能由代表消费者处理 satoshis 的中心化服务器进行。事实上，希望以法币形式定价的接收方还必须让同一个中心化服务器选择合适的汇率。

可以通过与信用卡定期付款相同的机制来管理非自动重新结算：联系付款人并要求他们再次付款 - 例如，通过发送 PaymentRequest 比特币：URI。

未来，支付协议的扩展和新的钱包功能可能允许某些钱包程序管理重复交易列表。支出者仍需要定期激活该计划并授权付款 - 但是，通过点击电子邮件发票，付款更容易、更安全，从而增加了收款人按时获得付款的机会。