The flow at QuickPay is that you first create a subscription, and after that you initiate a payment on that subscription - that is not happening automatically.

You can see that here: learn.quickpay.net/tech-talk/guides/subscriptions/#introduction-to-subscriptions

We have that implemented using our internal scheduler, because QuickPay does not initiate the payment themselves. This is why we do not recommend QuickPay. It is an unreliable way to handle recurring payments. Within the _cbsubs_payment_baskets database table find the scheduler_next_maturity column for your basket. That is the date the scheduler is set to trigger payment on.

It's possible due to it being a renewal in advance the scheduler set the scheduler_next_maturity date to the date the actual renewal is supposed to happen instead of being early. Am trying to get my developer account functional again to review this further.

I'm investigating the issue as we speak. CBSubs scheduler assumes initial payment was already handled and is why the maturity date is for the next renewal. QuickPay does not handle initial payment at all. I'm working on implementing this on PDT return or on IPN response so the initial payment can be paid correctly.

Ok, have added a bug ticket for this as follows.

forge.joomlapolis.com/issues/8265

I have this fixed for PDT returns, but need to do some extensive IPN testing as we don't want issues like IPN causing a duplicate payment, etc..