个人网站支付解决方案，写给自己看和写给开发者看，内容不该只有一张支付流程图。用户点击付款后，网站要知道哪笔订单已经支付；用户付款失败或要求退款时，也要有人能查到记录、完成处理。动笔前，把网站实际卖什么、由谁收款写清楚，方案才有落点。

收款主体还没确定时

个人网站不代表一定能用个人身份开通所需的支付能力。不同渠道对经营主体、网站内容、结算账户及交易类型的要求可能不同，具体以申请页面和服务协议为准。方案里不要直接写“支持微信、支付宝等所有方式”，而应写明拟申请的渠道、当前具备的主体资料，以及尚待渠道确认的条件。

商品形态也会改变方案内容。卖实物商品，订单会延伸到发货和售后；卖数字内容，付款后何时开放下载权限就进入了支付流程。若目前只做少量预约服务，接入完整在线支付前，也可比较支付链接或渠道提供的收款产品是否满足使用需求，但交易记录仍要能对应到具体预约。不要把个人转账收款和网站订单支付写成同一种能力：前者即使收到了钱，网站也未必能自动识别付款对应哪位用户。

用户付款成功，页面却仍显示未支付

这一段值得在方案中写细。假设一个销售付费资料的个人网站，用户跳转到支付页面完成付款，返回网站后看到“未支付”，便再次点击付款。此时经营者面对的主要问题，不是按钮样式，而是网站依据什么确认订单状态。

支付渠道返回的页面可以给用户提示，却不宜单独作为发放资料的依据。用户可能关闭页面，返回请求也可能中断。方案中应写明：网站创建订单时保存本站订单号，并把它与支付渠道的交易标识关联；收到渠道的支付通知后，核对订单、金额和支付状态，再更新本站订单。同一笔通知可能重复送达，程序不能因此重复发放下载权限。

沿着这个情境，开发者会检查订单记录和支付通知日志，定位是通知未到、校验失败，还是订单已经更新而页面没有刷新。页面暂未显示成功时，用户端保留“查询支付结果”的入口，比直接引导再次付款更稳妥。核对结果前，资料权限暂不发放；若渠道已扣款而本站订单仍未确认，则由后台记录交易标识，留待人工处理。这里仍有一个取舍：自动查询能减少等待，但会增加开发和维护工作量，是否接入要按实际订单量确定。

方案交付前，谁处理退款和对账

支付接通后，方案还要交代钱与订单如何核对。经营者按支付渠道的交易记录与网站订单记录对账，发现“渠道成功、本站失败”的订单时，保留两边的订单号和处理记录。退款由谁发起、退款后网站权限如何变化，也要写成可执行的动作，避免后台已退款，用户却仍能使用付费内容。

个人网站规模不大，方案不必写成复杂系统设计书。交给开发者的版本，至少把下单、支付确认和异常订单处理写到能实现的程度；交给经营者自己留存的版本，则补上渠道申请条件、结算账户及人工处理入口。准备接入前，先确认拟售内容能否使用所选渠道，再用测试订单核对一次付款通知与本站订单状态是否一致。