4.12通知接口

通知规范：

交互完成，基础营销平台通过通知接口将结果消息通知给商户。

例如：优惠券核销成功，基础营销平台通过通知接口将核销成功消息通知给商户。
注意：

• 同样的通知可能会多次发送给商户系统。商户系统必须能够正确处理重复的通知。 推荐的做法是，当商户系统收到通知进行处理时，先检查对应业务数据的状态，并判断该通知是否已经处理。如果未处理，则再进行处理；如果已处理，则直接返回结果成功。在对业务数据进行状态检查和处理之前，要采用数据锁进行并发控制，以避免函数重入造成的数据混乱。

• 通知存在不稳定性，不能保证每一笔通知都能成功通知，如果在所有通知频率后没有收到基础营销平台侧回调，商户应调用查询接口确认结果。例如，交易完成后如果没有收到结果通知，可调用交易查询接口查询交易状态

特别提醒：商户系统对于开启结果通知的内容一定要做签名验证，并校验通知的信息是否与商户侧的信息一致，防止数据泄露导致出现“假通知”，造成资金损失。

通知规则

业务交互完成后，基础营销平台会把相关结果和信息发送给商户，商户需要接收处理该消息，并返回应答。

通知频率：

对后台通知交互时，如果平台收到商户的应答不符合规范或超时，平台认为通知失败，会通过一定的策略定期重新发起通知，尽可能提高通知的成功率，但平台不保证通知最终能成功。通常情况如非特殊说明，

通知频率为15s/15s/30s/3m/10m/20m/30m/30m/30m - 总计 2h4m

通知报文

结果通知是以POST 方法访问商户设置的通知url，通知的数据以JSON 格式通过请求主体（BODY）传输。通知的数据包括了加密的结果详情。

（注：由于涉及到回调加密和解密，商户必须先设置好加密秘钥后才能解密回调通知，秘钥设置文档指引详见应用设置指引）

参数解密

下面详细描述对通知数据进行解密的流程：

1、在商户平台上设置加密密钥，记为key；

2、针对resource.algorithm中描述的加密方式；

3、使用key根据不同的加密算法，对数据密文resource.data进行解密，得到JSON形式的资源对象；

通知签名

加密不能保证通知请求来自基础营销平台。基础营销平台会对发送给商户的通知进行签名，并将签名值放在通知的HTTP头。商户应当验证签名，以确认请求来自基础营销平台，而不是其他的第三方。签名验证同接口签名规范的返回验签规范。

返回参数:

SUCCESS 或者 FAIL

4.12.1活动状态变更通知

4.12.2核销完成/核销回退完成通知

通知处理说明:

场景1：权益正常核销，过一段时间后撤销交易或者全额退款。

核销成功时机构会收到一笔核销通知（notify_type=try）,use_traces里都是核销的权益明细（use_type=try）;

交易撤销或者全额退款时，机构会收到一笔核销撤销的通知(notify_type=cce),use_traces里是核销撤销的权益明细（use_type=cce）;

两笔通知时间间隔较长（取决于交易退款时间），两笔通知的交易单号不一致。

场景2：权益核销成功后最终交易失败（例如权益核销完后，银行返回卡余额不足）。

核销成功时机构会收到一笔核销通知（notify_type=try）,use_traces里都是核销的权益明细（use_type=try）;

交易失败后，营销平台会回退已核销权益，机构会收到一笔核销撤销的通知(notify_type=cce),use_traces里是核销撤销的权益明细（use_type=cce）;

两笔通知时间间隔较短（一般几百毫秒至30秒之间，取决于银行交易结果返回），两笔通知的交易单号（trxid）一致，权益撤销（cce）那笔trxid和fatrxid一致。

场景3：权益核销成功后权益处理失败（例如远端权益核销后，营销平台判断活动预算不足，实时回退权益）

机构会收到一笔失败的核销通知(notify_type=fail)，use_traces同时包含核销的权益明细(use_type=try)和撤销的权益明细（use_type=cce），并且一一对应。

其中UseTrace字段如下