系统中如果要接入支付功能，目前基本上有三个大的场景。第一个场景是，接入第三方聚合支付接口，也就是说，这个聚合接口帮你搞定了支付宝，微信，银联等支付渠道的打通，在我们自己的系统中，只需要跟这个聚合接口进行交互就能实现支付功能；第二个场景是，系统直接跟支付宝，微信，银联，或者银行进行对接，此时我们需要去调试各个支付系统的接口，处理好，并对我们系统的用户包装成一个统一的支付通道，方便用户操作。
此类接口，一般是先进行各个参数的组装，参数加密，而后调用支付系统（无论是聚合，还是各个主流的支付系统）的支付接口获取到有效的支付链接；而后前台将该支付链接展示给用户，用户输入密码等，进入到各个支付系统的支付通道，此时用户进行支付操作。用户支付完成后，对应的支付系统会根据我们调用支付时传入的参数，调用我们系统的回调接口。
此时我们需要考虑一些容易出问题的点：
1.用户在对同一订单进行支付时，可能会误操作或者网关重发，这时我们需要考虑这个支付接口的幂等性，即用户调用一次和调用多次的结果应该保持一致。如果是在微服务体系下，支付模块部署了多个服务，尤其需要注意这个问题，此时我们可能需要使用一个分布式锁，保证只有一个请求能够完成这次支付处理，其余的请求不予处理。
2.回调的接口也需要考虑幂等。第三方支付系统在进行支付回调时，考虑到失败的情况，也可能会进行多次重复的回调，那么我们系统在进行处理时，也要考虑多次回调的处理结果应该保持一致。
3.如果整个支付过程是阻塞的，那么调用支付系统接口时，我们的系统可能还没有完全处理好相关的数据，比如支付订单的存储。也就是说，支付系统支付接口的调用是先于我们系统处理好支付订单的存储的，如果此时支付系统的回调已经到达我们系统，那这个时候可能回调接口会发现这个支付订单并不存在。为了避免这种问题，我们可以将发送支付请求与对应的数据进行异步处理。大多数情况下，我们可以将支付请求放入一个延时队列，当确认对应的数据准备工作完成时，这个请求再发出，此时支付系统进行回调的时间消耗即时是0ms，支付数据与订单数据也能进行正常的后续处理，整个支付动作完成。
待补充......