使用场景:
在实际发起支付之前,通过查询卡余额查询接口判断卡中余额是否足够用于支付,如果卡余额不足则在POS端直接提示,阻断后续使用该卡发起实际支付,相当于支付之前的前置校验。
另一方面,卡余额查询接口还兼有解密卡号的作用。因为POS端直接获取的是卡的磁道信息(行业标准是二磁道),二磁道信息的具体内容是商户写入的,所以只有商户知道磁道信息的解析规则。一般通过卡信息查询接口解密磁道信息,并将会员卡的卡号传给上游,后续的支付接口也使用该解密好的卡号进行支付。
使用场景:
在卡余额接口返回卡状态正常,余额足够之后,便可以基于该卡发起支付。用于支付的卡号一般是卡余额接口中返回的解密后的卡号。
使用场景:
对前一次支付发起撤销,使用场景为:使用卡支付时候没有明确获得支付成功的结果(比如由于系统超时的情况),这个时候很可能实际已经支付成功,也可能没有支付成功。正因为这种不确定情况,所以为保证用户不出现多次支付的情况,在发起下一次支付之前首先要确保这笔卡支付的钱没有实际支付,这个时候就需要对这笔支付发起冲正(撤销)。 所以冲正的语义为:1. 如果支付成功将钱全额退回 2. 如果未找到支付单据(比如超时了没有请求道商家去),返回固定错误码,即设置errorCode为 “DEDUCTION_RECORD_NOT_FOUND” 3. 如果重复的撤销直接返回撤销成功,返回结果保持和第一次撤销成功一致
使用场景:
基于支付的请求号outTradeNo查询该笔支付的状态,如:未支付、支付成功(DEDUCTED )、冲正成功(CANCELED)。目前POS端并不会主动发起查询,而是作为支付平台的一种优化,在支付或者冲正返回未决状态时会有支付平台主动发起查询判断支付或者冲正的结果。
使用场景:
退款和冲正都是将用户的钱返回回去,不同之处在于 冲正一般是系统触发而非用户的选择,在无法确认支付的真正结果时,为确保用户资金安全主动对支付进行撤销。 而退款则是用户的主动行为,是用户在完成支付之后(一定是支付成功才可以发起的退款),对交易不满意,退回货物并要求返还支付资金的行为。 所以退款发生在明确支付成功的时候。 退款接口是否需要实现依赖业务的需求,目前基本上所有的商家都不要求从卡中原路退款,而是通过比如现金等的方式退款,然后同步记录退款映射关系。