加密货币支付收据是商户对某笔具体订单已核实付款的确认。 它应让买家知道支付了什么、对应哪次购买,以及有问题时如何联系。单凭交易哈希无法提供这些商业背景信息。
本指南为商户提供收据信息清单和可重复使用的消息结构。这些是建议采用的业务管理措施,并不表示 Yolfi 能生成可下载的收据或税务发票。法定单据要求因司法管辖区而异;请向会计师确认您的企业必须提供哪些字段和单据类型。
区分付款通知单、收据和区块链记录
付款通知单用于要求付款,收据用于确认已经核实的付款,区块链记录则记载特定网络上的交易。应将它们关联起来,但不能混为一谈。
| 记录 | 说明的内容 | 单凭该记录无法证明的事项 |
|---|---|---|
| 商业付款通知单 | 卖方、购买内容和应付金额 | 买家已付款 |
| 商户支付收据 | 已收到并计入指定订单的付款 | 所有税务单据要求均已满足 |
| 交易哈希和转账详情 | 指定网络上的资产转移 | 客户身份或结清的是哪次购买 |
| 交付确认 | 已提供商品或访问权限 | 付款金额或税务处理方式 |
支付服务商名为“Invoice”的对象也可能有技术层面的含义。在 Yolfi API Checkout 中,买家选择受支持的网络和代币后,系统才会创建 Invoice。不要假定这个技术对象就是当地法规要求的商业税务发票。
核实付款后再发送收据,不要以页面跳转为准
对于集成式支付流程,应先在服务器上验证付款通知,再将订单标记为已付款或发送已付款收据。Yolfi 的 Webhook 文档 将 payment.confirmed 列为主要的履约触发事件。invoice.created 表示付款已发起,而不是已经收到资金。
按照文档中的签名流程验证事件的真实性,将其关联到正确订单,并妥善处理重试,避免重复生成多份独立收据。测试事件不得生成正式的已付款收据。为收据保留唯一编号,重新发送同一份单据时沿用该编号。
浏览器中的成功页面、钱包截图或交易所中待处理的提现都不足以证明付款完成。如果证据尚未核实清楚,应发送付款状态更新,而不是确认订单已付款。可使用客户支持证据清单开展调查,无需索取钱包机密信息。
对于人工审核的付款,应记录由谁核查了收款地址、资产、网络、金额和确认凭证。内部流程应规定什么情况下这些证据才算充分;本文并不为所有区块链规定统一的确认次数。
提供足够信息,明确购买内容和付款情况
面向客户的收据应易于阅读,技术凭证可以作为附件提供,或保存在非公开订单记录中供查阅。买家不应需要解读代币转账日志才能认出自己的购买记录。
| 收据字段 | 建议内容 |
|---|---|
| 单据标识 | 唯一收据编号,以及注明时区的开具日期 |
| 卖方和买方 | 企业身份信息及本次交易所需的客户信息 |
| 购买编号 | 订单或商业付款通知单编号,以及简要说明 |
| 商业金额 | 原始金额和计价货币,与加密货币数量分开列明 |
| 已接收付款 | 实际核实的准确数量、资产名称和网络 |
| 付款凭证 | 支付服务商的付款编号,以及可获取的相关交易编号 |
| 款项分配 | 计入本订单的金额,以及任何剩余应付余额或尚未处理的多付款项 |
| 后续联系 | 既定客服渠道,以及联系时应提供的收据编号 |
对于代币,应在底层记录中保留已核实的合约或铸币标识符。仅凭代币代码无法唯一识别资产。如果面向客户的单据缩写了较长的地址或哈希,应在非公开凭证记录中保留完整值。
将订单价格与已接收的加密货币数量分开记录。如果展示本地货币等值金额,应注明与记录相符的估值依据和时间。不要将每笔 USDC 或 USDT 收款都描述为美元银行存款,也不要在未说明的情况下将代币数量直接视为税务申报价值。
费用也需要清楚标注。发送方支付的网络费用不一定包含在商户收到的金额中。不要根据钱包余额与付款通知单总额之间的差额臆造费用明细。
使用以下收据消息结构
以下是写作模板,不是真实客户收据。请根据已核实的记录填写每一行,而不是让语言模型编造交易标识符。
已收到付款——收据编号:您的唯一收据编号。
卖方和购买内容:您的企业身份信息、订单编号,以及客户所购内容的简要说明。
付款:已核实的加密货币数量和资产、所用网络,以及原始订单金额和计价货币。
计入本订单:已计入本次购买的金额,并明确列出任何剩余应付余额或单独审核的多付款项。
凭证:付款编号和相关交易编号,以及注明时区的付款确认时间和收据开具时间。
问题或更正:请通过既定客服渠道联系,并提供此收据编号。切勿发送私钥或助记词。
仅在业务和当地法规要求时添加买方信息、登记标识及其他必填字段。避免将客户的电子邮箱、姓名或购买详情写入公开的区块链备注。
通过需要身份验证的订单页面或本次购买已核实的客户联系方式发送收据。不要通过无访问保护的公开文档链接暴露完整订单记录。公开交易一旦与具名客户关联,仍可能泄露其财务活动。
发挥交易凭证的作用,不夸大其证明范围
一笔交易可能包含多次转账。当一个哈希对应多笔代币转移时,应在内部凭证中明确相关的那笔转账,而不是给多个订单附上同一个未经区分的哈希。
对于 EVM 代币,Ethereum 交易回执参考文档说明了交易状态和日志。执行成功本身不能证明预期数量的代币已到达商户的收款地址。应检查相关转账详情;交易最外层的接收方可能是代币合约。
如果链接到公开凭证,应使用对应网络上可信的区块链浏览器。查看公开交易不应要求连接钱包、签名或批准代币支出。收据不能变成诱导客户前往陌生钱包授权网站“验证”付款的入口。
记录部分付款和退款,不改写历史
对于部分付款,只确认已核实且已计入订单的金额。余额尚未处理清楚时,不要将整个订单标记为已付款。对于多收款项,应区分已计入订单的付款和等待审核的金额。少付与多付处理指南介绍了这些决策。
后续退款需要独立且关联的记录。保留原始收据、退款决定和已核实的转出付款凭证,不要直接把原来的收款金额改成较小的数字。向消息中提供的地址转款前,请遵循退款审核流程。
通过可追溯的更正流程修正文书错误。是否需要正式的贷项通知单、替代单据或其他调整,是取决于司法管辖区的会计问题。应保留各版本之间的关联,而不是删除早期凭证。
Yolfi 在其中的作用
Yolfi 支付链接为固定价格的商品或服务提供付款入口。API Checkout 文档区分了可重复使用的 Paylinks 和由服务器为动态订单创建的 Checkout Sessions;独立会话不需要 Paylink。
企业应自行保留订单说明和客户关系信息,再将可获取的付款编号接入自己的收据流程。自动生成单据前,应先核实当前支付流程能提供哪些字段。公开的币种页面或本文都不能证明某种具体资产与网络组合已实际可用,也不能证明具备单据导出或会计集成功能。
对于日终管理,对账清单说明了如何将订单款项分配与钱包资金变动关联起来。客户收据回答的是“我付的钱买了什么?”,每日对账回答的则是企业记录是否完整。
常见问题
交易哈希算是加密货币支付收据吗?
单凭哈希不算。它能识别某个网络上的交易,但无法证明买家身份、购买内容或款项分配到哪个订单。商户收据是在核实后补充这些商业背景信息。
转账尚在处理中时可以发送收据吗?
应发送状态更新,而不是已付款收据。只有在符合书面付款确认流程时,才确认已核实的付款。不要承诺待处理的提现会在某个固定时间到账。
加密货币收据能替代税务发票吗?
不能自动替代。付款确认与法律要求的开票可能服务于不同目的。请向具备资质的当地顾问确认企业必须保留和开具哪些信息及单据。
收据应该展示完整的钱包历史吗?
不应该。凭证仅应涉及相关付款。必要的技术详情应保存在非公开记录中,限制访问权限,并且绝不索取私钥或助记词。
结语:确认付款,保留背景信息
实用的收据应将已核实的资金与清晰可辨的购买内容关联起来,不作超出证据范围的断言。从清楚的付款说明开始,为每条已接收付款记录开具一份可追溯的确认,并保留相关的更正或退款记录,而不是改写原始销售记录。
