订单的实体数据一般是持久化到业务侧数据库里面的，发起支付只是业务侧拿着自己订单标识到支付平台发起生成个支付交易单。。
所以，对一般的设计来说 在支付前订单 id 实体数据就落库了吧。。那么，仅是想要流转订单状态的话，或许修改业务侧订单库是不是来得快一些。。
当然，是想要验证支付链路是否能走通，那就还得要去 mock 了吧。。这样大概也不算是业务接口自动化该做的事了？

如果不是要负责全链路的自动化实现，业务的自动化或许跟随服务收敛比较好，大概只需要关注订单生成后是否有消息生产以及生产消息内容是否正确就可以了哇？毕竟消息的消费是下游链路的事，自动化收敛一些的话，对稳定性也会有些帮助吧，维护成本也比较低了。。
当然都是在建立积分发放属于会员业务而不属于订单业务的基础上了。。当然还是得具体到业务来看。。

从接口调用数据落库耗时 5 秒的 -- 这个过程都是同步的吗？还是说数据落库是异步实现？
自动化中异步查数据也不是不行吧，考虑用回调实现。。

请问 楼主 现在还在玩这个东西么？