你的本意就是用户支付成功后不要马上把资金划拨给商家，这个你可以看现在的微信支付，所有的支付他们都是有一个结算时间节点的，比如次日凌晨结算前一日的支付成功资金，其实即使这样子做也会存在退款问题，这个是避免不了的。
因此，其实等于不等都会存在退款问题...清楚了这一点，实现起来就清楚多了。当然退款问题在本次回答中暂不表，如果你有需要可以单独提问或私信。

你的这个问题说下点就是把资金通过第三方渠道划拨给商家，说大了是经分问题。

在技术实现上，通常可以采用缓存+消息队列+持久化存储并最终数据一致性的方案，当然系统越大、越复杂涉及到的技术门槛相对就高些...同时要保证数据最终一致性的难度就越高。
如果你每分钟也就几单，或者更大些每分钟小于100单，我个人的思路还是采用MySQL直接存储支付订单就好，这个量不大...这样子技术单一，便于排查。至于订单支付后你几小时后需要进行结算，可以使用 quartz 定时任务来解决，比如每半小时处理一次需要清算的订单... 这个时间你可以根据你们实际业务来定。这样子可以完全实现解耦，支付和结算给商家的互相不干扰，方案简单。
当然如果想玩技术，那也未尝不可，可以引入消息队列，然后利用消息队列中的延迟队列特性来解决。这个目前大部分开源的消息队列都支持这个功能，比如AMQ（ActiveMQ）、RocketMQ、RabbitMQ 等等等，就不列举了。处理思路基本都是用户支付成功后把数据一份写入数据库持久化、同时可以异步或者同步写一份到MQ中...当然如果用户退款了、取消订单等也需要同步的把消息推送到MQ、这样子利用MQ的延迟队列的能力你自己去写你的处理逻辑就好了...
当然越复杂的系统需要考虑的事情就越多，其原理大同小异。