[SOLVED] [#8265] QuickPay subscription not working!

Another reason to not use Stripe here in Denmark is that they do not support MobilePay (the danish version of ApplePay), which is videly used to pay online here in Denmark - the customers need to be able to pay with that. If Stripe supported that, then it would be another storry.

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.

The scheduler_next_maturity is set to 2021-12-31 19:51:03 - so that is not triggering a payment for this year 2021, only for 2022 - so it is not working corectly.
It would be ok by me if it just triggered on 2020-12-31 - I would just have to adjust some of the user messages/mails. Right now I have only two active payments and I could set them manually in the database, but not for 500 where I have to check each one if it is recurring or not.

Could this setting have something to do with the problem ??

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..