一、支付应用连接两类记录
区块链支付应用既要处理网络中的资产转移，也要维护商品或服务的订单状态。链上记录回答某笔交易如何改变账本，订单系统回答这笔付款属于哪个请求。理解两者的关联，是理解支付应用技术结构的起点。
以太坊交易文档描述了签名交易、账户状态、费用和合约执行；比特币支付处理文档涉及支付请求、地址与订单关联等流程。两种网络的具体字段和执行规则不同，不能直接套用。
二、地址、私钥与数字签名
地址用于指定交易涉及的账户或收款目标，私钥用于生成授权签名。以太坊的签名交易包含接收目标、金额、序号和费用等信息，网络据此验证并处理状态变化。
签名证明的是相应密钥对交易的授权，不能单凭它确认收款方的现实身份。支付界面因此需要清楚呈现接收目标与操作内容，帮助用户理解授权对象。
三、交易状态与手续费
在以太坊中，交易需要广播并纳入经过验证的区块。Nonce是账户交易的递增序号；Gas衡量执行所需的计算资源，Gas上限与每单位Gas的费用上限是不同参数。
金额与手续费属于不同支出，支付应用应分别展示。提交请求、进入区块和执行成功也属于不同状态：界面显示“已提交”，只能说明流程已推进到相应阶段，不能直接作为订单完成的依据。
四、转账与智能合约调用
以太坊交易可以转移ETH，也可以调用合约。合约调用的数据按ABI规则编码，用来指定函数及参数，因此接收地址和转账金额并不足以表达所有操作。
涉及合约的支付界面，需要解释调用内容。单纯展示一串十六进制数据，难以让用户判断授权含义；可读摘要应与实际签署的数据对应。
五、支付请求与订单对账
比特币支付请求可通过地址和金额表达，也可使用BIP21 URI，并编码成二维码。为不同付款请求分配不同地址，有助于将收到的交易关联到订单；金额还需要明确单位。
二维码是请求信息的载体，扫码本身不代表支付完成。对账需要结合关联地址和链上交易记录判断；支付请求中的说明文字，也不能一概视为写入区块链的订单凭证。
六、适用条件与常见问题
是否所有区块链支付都需要智能合约？不需要，普通资产转移也能构成支付流程，是否调用合约取决于业务和网络机制。
是否可以直接照搬旧支付协议示例？需要区分协议状态。比特币支付处理文档已将BIP70标记为弃用，不能把其中的历史功能介绍理解为当前通用支持情况。应用设计应分别核实网络规则、钱包兼容性与订单处理需求。