本文主要讨论PC端的用户付款接口
1，支付宝网页对接原理
-
用户输入支付宝账号密码及确认支付等操作，都是在支付宝域下进行。
-
网站将业务信息通过类似于重定向的方式提交到支付宝。
以下截图：第一个是网站自己的，第二个是支付宝的。用户在第一个页面点击'立即支付'，请求会发到网站后台，网站后台输出上面所说的html，浏览器会新开页并跳转至第二个页面。
-
在支付宝域下确认支付后，网站会收到支付宝交易结果通知，分为同步和异步。同步由浏览器发送（通过支付宝页面的JS执行），异步由支付宝后台主动发送直到收到网站的返回或者发送次数用完。同步通知，可以很方便地进行本地测试，但同步发起只有一次，而且浏览器可能被关闭，所以不能依赖于同步，对于异步通知，可以通过内网穿透工具（推荐natapp）进行模拟测试。
2，out_trade_no的生成规则
out_trade_no是网站对外的订单编号，采用‘用户订单编号'+'支付方式'的规则，这样对于同一笔订单同一种支付方式，无论用户在网站发起几次请求，out_trade_no始终唯一，可以避免重复扣款。
曾经注册了一号店、优酷、迅雷等网站，测试发现他们的out_trade_no规则主要包括2种：
1）：直接使用原订单号，这样可以防止重复支付，但是不适合我们网站，因为我们网站的网银支付走的也是支付宝的接口，这样如果用户从支付宝支付切回网银支付时，支付宝会报错：交易已存在，意思就是说你已经提交过支付请求。如果网站的网银支付走的是银联接口，这种方式没有任何问题。
2）：一笔订单每次提交支付请求时，out_trade_no都会变化。对于网站的同一笔订单，每次请求out_trade_no不一样的话，支付宝就会当成一笔新的交易，这样极易出现重复支付。但话说回来，现在用户一点都不傻。
3，注意事项
-
异步回调有次数限制，为防止异常情况下没有收到支付宝的交易通知，必须辅以支付宝的另一接口"单笔交易查询"，可以主动去查询交易结果。为了原路退款，同时需要开发“批量退款接口”。
-
支付宝的每一笔交易是以“支付宝流水号”唯一确定的，为保证数据及逻辑的一致性，网站数据库需要使用唯一索引，应用层级需要使用事务（事务：登记支付宝流水信息，更新订单支付状态等）。
-
支付宝的交易通知可能多次，如果网站已经处理过，须直接返回或忽略。如果发现是异常扣款（后面介绍），可能需要执行退款等业务操作。
-
防止串号，一定要保证测试环境发给支付宝的out_trade_no跟生产环境不一样，一般会通过设置订单编号的前缀来区分，比如测试时都以“T”打头。
4，异常支付处理
这里说的"异常支付"不是系统或代码异常，特指在支付宝接口开发中违背业务逻辑的需全额退款的支付。
主要包括以下2种情况：
4.1 重复扣款
重复扣款：网站的一笔订单，客户支付两次。
发生概率：很低
产生场景：客户选择了支付宝支付，由于网站订单状态未更新，客户以为未支付成功，又选择网银等其他支付方式；另一种情况是客户选择了支付宝支付并登录成功但未确认支付，回到网站又选择了其他支付方式并支付成功，但支付宝的账单记录还在那放着，有效期内客户又不小心点了确认支付。
说明：由于out_trade_no 设计根据订单编号+支付类别唯一生成，所以不会出现同一支付渠道下的重复扣款。
4.2 商户订单状态不对
发生概率：很低
产生场景：用户在支付成功后立马去“取消订单”，由于网络延迟或其他原因，网站没有收到支付结果通知，就主动去调用“单笔交易查询”接口，但是调用又出现系统异常，这个时候只能将订单状态置为已取消。待网站最终收到支付通知时，发现订单已取消了，那当前支付就是无效的。即便网站最终收不到该笔支付结果通知，客户也会投诉为什么没收到退款。
PS: 即时到账接口曾经支持“网银支付”，就是说不用登陆支付宝, 用户直接登陆网银, 但2016年支付宝已经下架了“网银通道”（老用户可以继续用一段时间)。想实现网银支付的朋友们，请联系银联, 或者找第三方代理机构.