#支付宝 如何修改周期扣款时间?

每次周期扣款时间是根据周期规则period_rule_params（周期管控规则参数）的execute_time和周期时间结合设置。

但是如果由于扣款失败、业务需求等需要修改周期扣款时间，可通过【alipay.user.agreement.executionplan.modify（周期性扣款协议执行计划修改接口）】实现。

注意：扣款失败的情况建议商户在周期允许的范围内重试，一直失败则停服务，不建议失败后修改扣款时间拉长重试周期。

一、参数说明

1、agreement_no（必传）：支付宝签约协议号。

用户签约周期扣款成功后，支付宝返回的签约协议号，查询方式详见【如何查询agreement_no】。

2、deduct_time（必传）：商户下一次扣款时间

商户需要将周期扣款时间修改为deduct_time时间。

3、memo（选填）：具体修改原因。

二、注意事项 1、修改周期扣款次数？

由于一对多模式，同一个商户下，同一个用户最多可签约10套周期扣款协议。

一套周期扣款协议，最多只能修改10次，即【alipay.user.agreement.executionplan.modify（周期性扣款协议执行计划修改接口）】只能调用10次成功修改协议（失败不计）。

2、deduct_time取值范围？

deduct_time只能往后推 不能往前提：扣款失败保持不变，扣款成功往后推1个周期。

注意：如果扣款周期类型为天，则无限制；如果扣款周期为自然月，只能延期到（1-28号）。

例：period_type=MONTH，period=1，execute_time=2019-07-05

在此例中每个自然月的5号发起扣款，2019年7月5日首次执行。

（1）在7月5日之前下次扣款时间：2019-07-05，可执行扣款时间：2019-07-02至05，deduct_time 取值范围为2019-07-06之后任意时间（除每月的29、30、31号不可设置）。

（2）在7月5日扣款时间点扣款失败或者没有扣款，同上不变。

（3）在7月5日扣款时间点扣款成功，下次扣款时间：2019-08-05，可执行扣款时间：2019-08-02至05，deduct_time取值范围为2019-08-06之后任意时间（除每月的29、30、31号不可设置）。

3、是否全部时间修改？

周期扣款的【alipay.user.agreement.executionplan.modify（周期性扣款协议执行计划修改接口）】修改推迟扣款时间后，是只推迟该次周期时间，还是全部时间都推迟？该修改时间是全部时间都修改推迟。

例：period_type=MONTH，period=1，execute_time=2019-07-05

正常情况下每月5日为约定扣款日，可提前3天发起扣款，也就是每月2日-5日。

调用修改接口deduct_time指定为2019-7-10后，每月10日为约定扣款日，可提前3天发起扣款，也就是每月7日-10日。

4、如何查询修改后的扣款时间？

修改周期扣款的扣款时间后，没有渠道查询，需商户自己保存数据记录。

如果商户未保存数据，或者保存数据丢失：

（1）建议商户联系用户从用户钱包代扣协议服务详情中看到下一次什么时间扣款。

（2）如果无法获取，建议商户取消该周期扣款协议，重新签约继续业务操作。

5、修改时间后，用户是否感知？

修改周期扣款后，支付宝是不会发送通知给用户的，因此用户端是不会感知的。

但是用户如果需要知道下次扣款时间，可以根据钱包代扣的“服务详情”查看。

如果商户需要通知用户修改了周期扣款协议，可通过【阿里云短信通知方案】自定义信息发送给用户。

6、“服务详情”的扣款时间是否修改？

（1）会根据扣款情况进行修改，用户可以从钱包代扣协议“服务详情”中看到下一次什么时间扣款。

案例：period_type=MONTH，period=1，execute_time=2020-04-02。

服务详情扣款时间：2020-04-02，扣款成功后服务详情扣款时间显示：2020-05-02。

或者协议修改接口设置：execute_time=2020-04-10，修改成功后服务详情扣款时间显示：2020-04-10。

（2）本期扣款一直失败，或者忘记扣款，在“服务详情”中扣款时间不会改变，仍然为当期时间。

案例：period_type=MONTH，period=1，execute_time=2020-04-02。

本期商户忘记扣款，结果时间到了2020-04-03，但是服务详情扣款时间仍为：2020-04-02。

原因及处理方案：

本期没有扣款，“服务详情”中约定扣款日始终停留在本期， 到下一期约定扣款日发起扣款会报：不在扣款时间范围内。

周期扣款产品的设计是为了满足每期都有扣款需求的业务， 一期扣一期不扣的业务场景不在射程范围内。

代码逻辑上是这么设计的：必须要上一期扣款成功才会转入下一期，否则商户应该停服务。