1 problem and 2 questions about subscription support ( 1 fix)

1) Please take a look into the Maintenance tab in Paymill Plugin settings. Seems webhooks are not properly configured or deactivated.

2) Payment status for subcriptions is usually switched from on-hold to processing through webhooks.

3) As discounts for subscriptions are not supported, I cannot give you a valid answer here. Last testing of this feature is a while ago and therefor any answers would be out-of-date. I would ask you to test the behavior on your own. As far as I remember, discounts on setup fee should be possible, but not on subscription fee.

4) Big thanks for providing that fix! ??

Hi,

1) The webhooks hint pushed me in the right direction (Thanks!!). In the end, it was even simpler. I excluded Paymill from loading on specific pages – that made it impossible for the plugin to receive the incoming information.

3) Regarding the coupons:
Coupons that are applied at any payment work. Coupons that are only applied for the first payment won’t work. You could build a workaround where you do not create a subscription at paymill, but one regular payment + a subscription after the first term has ended. However, this would definitely by a bigger issue. Maybe it’s easier if Paymill adds more coupon functionality.

5) There is one more strange behavior that I’ve noticed. Somehow, at recurring payments, woocommerce creates 2 (or more) new orders when paymill is used.
How it should work:
a) Subscription order + Paymill payment
b) Payment is processed and the order is created
c) Recurring payment
d) Woocommerce adds a new order for the recurring payment (connected to the original one)
e) and so on
How it acutally works:
a) Subscription order + Paymill payment
b) Payment is processed and the order is created
c) Recurring payment
d) Woocommerce adds a new order for the recurring payment
e) Recurring payment
f) Woocommerce adds a new order for the recurring payment
g) Woocommerce adds a second new order for the recurring payment. However, it is only considered once at Paymill level.

I believe that either Paymill sends two responses for recurring payments or the plugin sends two jobs to woocommerce – one for every existing (sub-)order. I will further investigate this. Maybe there’s another reason for this.

6) I found one more “bug”:
If I delete clients or offers at Paymill, next time I order something with this client or select one of the offers, I get an error “client not found” or “offer not found”. This is, because the plugin stored the information about the client and offer in the database and checks if the information exist at Paymill when I place a new order.
That’s not really a bug, but I was wondering why it gives me an error instead of simply creating a new client/offer like it is done when there is no client/offer at both, the database and Paymill. I’m not sure if maybe this only happens in test mode – if not, it would be a good idea to change it.

Best,
Jens

Short update regarding (5):
It keeps behaving as observed. With every new term it becomes one more additional order.
And: The new orders get added with a time difference of 1 hour.
So maybe there is a cron job running every hour and adds a recurring order for each main (but also sub) order?

3) Did you tried a Subscription with a setup fee? Coupon may be applied to setup fee and setupfee could be used for first subscription intervall. Subscription test period can be set to that first subscription intervall.

5) I am aware of this bug, but didn’t was able to solve it so far, as it cannot be reproduced on a proper way so far. The bug occured on a user’s dev installation, but once switched to live on a fresh install and account, it disappeared. If you have any success in your investigation, I’d love to get information of these.

6) There should be no reason to delete a client on Paymill in LIVE mode, but I understand that this could be synced a bit better. I’ll put that on my todo, but with lower priority.

Hi,

3) No. I did not use a setup fee. This would be another logic. My use case: A coupon that works for both, products and subscriptions will apply for the first term of the subscription (but not for the following) and not affect a setup fee (at least that’s the woocommerce logic). But this issue should not get any high priority imho.

5) I just switched from test keys to live keys in order to run a new test. Will come back with further findings.

6) You’re right. It’s only a little annoying while testing ?? – but not such a big deal.

Hi,

I did a lot of further checks and tests.
First, have a look at my log. It really seems that the webhook simply gets triggerd twice (or even more often). So, there is no problem in handling the webhook or processing the payment within woocommerce. The process simply gets startet multiple times.

########################################################################################################################

Mon, 29 Jun 15 22:46:13 +0000 - Webhook subscription.succeeded (Resource-ID: sub_33cd3b85bebda68ace57) triggered - start processing

SELECT * FROM pp_paymill_subscriptions WHERE paymill_sub_id='sub_33cd3b85bebda68ace57'

array (
  'order_id' => '2872',
  'product_id' => '967',
  'variation_id' => '0',
  'status' => 'active',
  'period' => 'day',
  'interval' => '1',
  'length' => '0',
  'start_date' => '2015-06-28 22:43:12',
  'expiry_date' => '0',
  'end_date' => '0',
  'trial_expiry_date' => '0',
  'failed_payments' => '0',
  'completed_payments' =>
  array (
    0 => '2015-06-28 22:43:12',
  ),
  'suspension_count' => '0',
  'last_payment_date' => '2015-06-28 22:43:12',
)

Mon, 29 Jun 15 22:46:29 +0000 - Webhook subscription.succeeded finished - end processing

########################################################################################################################

Mon, 29 Jun 15 23:47:11 +0000 - Webhook subscription.succeeded (Resource-ID: sub_33cd3b85bebda68ace57) triggered - start processing

SELECT * FROM pp_paymill_subscriptions WHERE paymill_sub_id='sub_33cd3b85bebda68ace57'

array (
  'order_id' => '2872',
  'product_id' => '967',
  'variation_id' => '0',
  'status' => 'active',
  'period' => 'day',
  'interval' => '1',
  'length' => '0',
  'start_date' => '2015-06-28 22:43:12',
  'expiry_date' => '0',
  'end_date' => '0',
  'trial_expiry_date' => '0',
  'failed_payments' => '0',
  'completed_payments' =>
  array (
    0 => '2015-06-28 22:43:12',
    1 => '2015-06-29 22:46:14',
  ),
  'suspension_count' => '0',
  'last_payment_date' => '2015-06-29 22:46:14',
)

Mon, 29 Jun 15 23:47:23 +0000 - Webhook subscription.succeeded finished - end processing

########################################################################################################################

Well, this might be a Paymill issue. But maybe it’s not even a bug, but a feature to make sure the webhook gets through. Or this happens due to some strange mix of old data, caching, … (who knows).

Finally, I compared your code to the PayPal-Code, since PayPal works as expected.
So far, I can only tell that the basic handling is the same, but PayPal executes way more security/failure checks.
That’s why I think that the only proper fix would be to keep track of the different payments and reject a payment if it comes in the second time.
There are different ways to do that and I think you have a better idea of how to track.
For now, I implemented a little workaround on my side that keeps it going (however, this only handles standard subscriptions – any special setting might break it).

Change in woocommerce.inc.php at line 248 ff:

`
$whole_period = 0;
switch ($subscription[‘period’]) {
case ‘day’:
default:
$whole_period = intval($subscription[‘interval’]) * 86400;
break;
case ‘week’:
$whole_period = intval($subscription[‘interval’]) * 604800;
break;
case ‘month’:
$whole_period = intval($subscription[‘interval’]) * 2160000; // using 25 days to prevent problems with shorter months
break;
case ‘year’:
$whole_period = intval($subscription[‘interval’]) * 30240000; // using 350 days to prevent any timezone problems whatsoever
break;
}
if (strtotime(date(DATE_RFC822)) > strtotime($subscription[‘last_payment_date’]) + $whole_period – 18000) { // minus 5 hours to prevent any problems with pending triggers

$order = new WC_Order($subscription[‘order_id’]);
//WC_Subscriptions_Manager::process_subscription_payments_on_order($order, $subscription[‘product_id’]);
WC_Subscriptions_Manager::process_subscription_payments_on_order($order);

}
`

Hope this helps to fix this bug! Maybe you can at least include some check (like my workaround) that can be enabled by option.

Best,
Jens

Hi Jens,

big thanks, wow, that saves a lot of work on my side. I’ll review and implement your fix asap.

Kind regards,

Matthias