notDigits: '-16001' must contain only digits

Hi,

unfortunately, I can not reproduce this issue. Could you make a screenshot of your product’s settings?

Kind regards,

Matthias

I forgot to metion that I use it with subscription product from woo.

Product setting is basic: simple subscription; virtual product;

Did you set any negative value on your subscription settings? I’ve tested subscriptions and still can’t reproduce this issue ??

I am facing the same problem. I have WordPress installed locally and am testing the Paymill plugin. I have XDebug installed and Eclipse and configured such that I can step through the PHP code. Anything I should look at to help debug this? I am not yet an experienced PHP developer, but more than willing to help out!

One curious bit of information: My purchases actually went through, despite this error! I can see them in the Paymill dashboard.

No. There’s no negative value in the settings.

BTW, what is also very disturbing is that all my test Subscription purchases actually appeared in the Paymill backend! So this error must happen after contacting the Paymill server. IMHO, if the payment actually went through, the plugin should /never/ display any error for anything and suggest to the user that nothing indeed happened. Users will just try again and then set up multiple subscriptions before giving up.

After upgrading to 3.7.1 the error disappeared.

big thx for the notice about that fix with upgrading! So I’ll stop investigating until the issue occurs again.

Ahhh. It seems it’s not gone forever.

But I think I know how you can reproduce it.
The error seems to occur only if I create a new user.
When I checkout with admin user it’s ok.

So set up Woo as this:
Allow registration on the checkout page: yes
Register using the email address for the username: yes

Also the error now is “-16015” instead of ‘-16001’.

I was already using 3.7.1 when I reported seeing the error. I am also not a fan of “oh, it magically went away, let’s forget it”. The problem needs to be fully understood. We are talking about a product with which real users pay real money.

Hi Stippi,

as I’m currently working on a totally rewritten payment process, this issue could be fixed automaticly on next release.

I’ll check the issue as I’ve got new information about this bug from mkdev which could make it reproducable.

Kind regards,

Matthias

Ok, thank you very much for keeping me in the loop! When you design the new payment process, try to think of possible points of failure and how to minimize them. IMHO, after the Paymill server has been successfully contacted, it should not be possible for anything to go wrong anymore, except perhaps for power outage or server reboot. For example, the database entries for the order should be made preliminarily, so that they already exist before contacting Paymill. And if contacting Paymill failed, there should be a roll-back. Placing the order should work like an all or nothing transaction. I don’t know if that’s even possible in the Woocommerce workflow of hooks that all sorts of plug-ins can insert themselves… but one can dream. Alternatively, if points of failure after placing the order at Paymill can not be eliminated, perhaps there is an API for revoking the order there? That should then be incorporated into a general roll-back flow.

In short: If the order technically went through, the user should never see an error, or if that is not possible, the payment needs to be cancelled if an error happens after it is placed at Paymill.

Hi Stippi,

thank you for your feedback ?? I’m happy that the plugin is growing and get’s more and more powerusers. I’ll take care that the plugin will not confirm any order except there is a 100% guarantee for successful payment.

I’m looking forward making the payment process more robust.

Kind regards,

Matthias

Hi,

the issue has been solved with v1.5.1

Kind regards,

Matthias