网页放上二维码后，订单由谁确认

个人网站实现二维码收款，最省事的做法是上传一张收款码图片，访客扫码付款。这适合访客自主决定金额、无需立即交付内容的场景。若网站卖的是固定价格的文件或服务，网页显示“支付成功”就涉及另一个问题：网站如何知道哪笔钱属于哪张订单？

静态收款码本身不会把付款结果发回网站。访客上传截图，只能表明对方提供了一张图片，不能代替到账记录。站长若收到截图就自动发货，可能遇到未付款、金额不符或重复使用截图的情况；若每笔都人工查看，订单增多后，访客也会不断询问何时开通权限。上线前把“付款后由谁确认、何时交付”写在支付入口附近，能减少这类误会。

访客已付款，网站却找不到对应订单

例如，一个提供数字资料的个人网站使用固定收款码。访客提交订单后扫码付款，回到网页上传截图，并留言“已经付了”。站长在收款记录里看见一笔相同金额的到账，但同样价格的订单不止一张，截图也没有提供足以对应订单的信息。这时直接发资料，可能把交付记录记到错误的订单上。

这个场景可先保留订单提交记录，暂停自动交付；请访客提供订单编号和支付时间，再对照收款渠道内可见的交易记录。核对时无需索取支付密码、完整账号或验证码。若现有记录仍无法对应，就告知访客暂时不能确认该订单，而不是根据截图猜测。人工处理会让交付变慢，网页上的提示也要与实际处理方式一致，别在需要人工核对时写“付款后立即获取”。

站长随后可以调整页面：让访客付款前生成订单编号，付款后回填编号，并把待核对订单集中在后台。这样仍未实现自动到账通知，但减少了留言散落在邮箱、聊天工具里的情况。若后来订单量增加，再评估接入能向网站返回支付结果的服务。

准备接入自动支付时，核对什么

自动确认订单一般要通过支付服务提供的接口或现成插件完成。访客支付后，服务方向网站发送交易结果，网站再把结果与订单编号、金额对应起来。页面跳回“支付完成”不能单独作为交付依据：访客可能关闭页面，页面地址也可能被误用。交付依据应来自可核对的交易通知或商户后台记录。

选择服务时，先查看它是否支持个人网站当前的主体类型、经营内容和交付方式，再看费用与开发维护成本。收款工具的开通条件、接口权限可能随服务方规则变化，不宜仅凭旧教程配置。若只是偶尔接受支持，人工核对或许足够；若访客付款后要即时下载，支付结果通知和订单状态更新就要一并安排。

收款码上线后，还要在手机上实际扫一次网页展示的码，核对收款方名称和付款页面；网站图片、后台账号由谁维护，也要留有记录。下一次修改支付入口时，先检查页面显示的收款码，再测试订单从提交到交付能否对应。