付款后要自动交付，先确认接入身份

用户搜索“个人收款API接口”，往往已经能用收款码收到钱，卡住的是下一步：付款完成后，网站怎样知道哪笔订单到账，并自动发货或开通权限。

先区分“能收款”和“能通过接口管理订单”。个人收款码面向转账或当面收款；支付接口涉及创建订单、接收支付结果通知、查询交易和处理退款。收款页面显示成功，不代表收款方拿到了可用于自动交付的订单信息。支付机构或服务平台提供哪些能力、接受什么主体接入，要以其当前的申请条件和接口文档为准。

挑选接入方式时，把业务过程讲清楚：付款人从哪里下单，系统何时交付，发生退款由谁处理。若平台要求商户身份，不能因为名称里有“个人收款”，就默认个人二维码也支持同样的接口能力。

页面显示已付款，系统却没有发货

例如，假设一位开发者销售数字资料，原来靠用户提交付款截图后手动发送下载链接。订单增加后，他准备接入一个声称支持“个人收款回调”的服务，让系统收到通知就自动发链接。测试时，付款页面显示成功，网站偶尔却等不到通知；重复刷新页面后，又出现同一订单被交付两次的风险。

此时不宜直接用“用户返回了成功页”作为发货依据。用户关闭页面、网络中断，都可能影响页面跳转；服务端通知也可能延迟或重复送达。开发者先向服务方确认：通知由谁发出，能否查询原始交易，通知中的订单号怎样对应自己创建的订单。若服务方无法提供可核对的交易记录，仅转发设备上的收款消息，自动交付就缺少稳定依据。

实现上，订单保持“待付款”状态，直到服务端收到通知并核验签名，再核对订单号和金额。签名用于判断通知是否来自约定的服务方，不能代替订单核对。同一笔通知重复到达时，系统只完成一次交付；没有等到通知的订单，通过平台提供的查询能力补查，而不是让用户反复付款。前提是接入方确实提供这些能力，并允许该业务使用。

这位开发者仍需确认数字资料能否在所选通道销售。若现有服务无法回答交易查询和退款处理问题，手动交付虽然占用时间，却比放开不可靠的自动发货更可控。

接口接通后，对账和退款还要有人处理

接口测试成功，只覆盖了顺利付款的一段过程。实际运行中，用户付款后可能立即关闭页面，通知可能晚到；退款完成后，已发出的内容也未必能够收回。订单表至少要保留平台交易号、本站订单号及状态变化，便于核对一笔钱对应哪次交付。不要把支付凭证截图当作唯一依据，也不要为了排查问题长期保存与交易无关的用户信息。

对接第三方服务时，还要问清资金进入谁的账户、后台能查看什么记录、服务停止后怎样导出订单。使用抓取收款短信、监听通知或模拟登录来识别付款的方案，可能受设备状态和页面变化影响；涉及账户凭证时，风险也会扩大。仅凭服务方展示的“回调演示”，无法确认长期可用性。

准备上线前，拿一笔测试订单走完付款、通知和查询，再模拟重复通知，检查系统是否只交付一次。随后核对平台的主体要求与业务范围；缺少明确答复的环节，先保留人工确认，不把它接进自动发货。