whatspauldoing

Thanks for your reply. I’m actually just pointing out a problem with the code. And I’m not sure how to get it to a developer over at woo.

Is this something you could flag with a developer?

Cheers,

Paul

Thank you very much! That’s brilliant.

Also, it looks like the cron functions are involved. I’m getting the erroneous failed payment email at the same time every day.

I think I’ve found the bit of code that adds the failed rows to the payment_log table in class.armember.php in the function “arm_perform_update_function” lines 4292 – 4394

I’m not sure why this is being triggered though?

It is certainly then causing the code in the stripe listener function in the invoice.payment_succeeded clause to fail as the select statement:

$getData = $wpdb->get_row( "SELECT arm_token,arm_log_id,arm_user_id,arm_extra_vars FROM" . $ARMember->tbl_arm_payment_log. "WHERE (arm_token LIKE '%".$customer_id."%' OR arm_token = '".$invoice->subscription."') AND arm_display_log = 0 AND arm_payment_gateway = 'stripe'" );

will fail on the arm_token clause.

Hope that helps.

Cheers,

Paul

• This reply was modified 2 years, 10 months ago by whatspauldoing.

Thanks for getting back to me, we are listening for that even from stripe, but I’m not sure it’s working correctly.

In the payment log table for every subsequent payment for each subscriber the row shows these fields as such:
arm_token: –
arm_transaction_id :
arm_transaction_status: failed
arm_extra_vars: a:1:{s:9:”manual_by”;s:14:”Paid By system”;}

This appears to be the only correlation between all the payments marked as failed by Armember, and the successful transactions at stripe.

The stripe webhook events logged with Armember that correlate to the payment events “customer.subscription.created” all contain the correct data.

This is now happening for every recurring payment.

I hope there are some clues up there.

Cheers,

Paul

Hello there, thank you for getting back to me.

I’ve got the logs running, but I’ve also got some more info. It looks like this is only happening for the first recurring payment of any given subscription, those on their second/third etc payments are working fine.

The payment description for transactions marked as failed in Armember show in stripe as “subscription creation”. On further inspection of the payment, stripe shows the payment_succeeded event but it looks as if that’s not being captured by Armember.

I’m seeing a couple of possibly relevant empty Armember log entries which correlate to the timestamps on stripe these are: “modify webhook payment log details” and “webhook existing subscription data”.

I can send a download of the Armember log if you think that would help?

Thanks again,

Paul

Had 2 more of these failures today. Another interesting point is that they all seem to be the first recurring payment on the subscription, which is marked in stripe as “Subscription Creation”.

We can manage our members by updating the failed row in the payment logs with the charge details and changing the status of the payment from “failed” to “success”, and then re-activating the users plan through the UI, but its a bit of a headache to have to do every time.

Is it possible stripe have updated the way their webhooks work?

Hello there,

I’m getting there I think, and I can only speak for stripe, but it looks like the listener function is checking for a very limited number of events, none of which are sent when, at least with this particular customer I’m looking into, the recurring payment is successful.

The code checks against; customer.subscription.updated, customer.subscription.deleted and order.payment_failed, however in the list of events sent by stripe during a successful recurring payment the following pertinent events are sent:
invoice.payment_succeeded
subscription_schedule.updated
invoice.paid
payment_intent.succeeded

All of which would tell Armember that the subscription should remain active, but don’t seem to have cases attached to them.

I’m still looking into why that then marks the subscription inactive, rather than just throw the generic error, but I think that’s enough for today.

More tomorrow.

Cheers,

Paul

That’s not going to work, my first year of premium support has run out and I don’t intend to pay more money to have to report a bug.

I’ll fix it myself and let you know.

The webhook that’s being sent is “invoice.payment_succeeded” however there’s no code in the switch/case statement for that event.

class.arm_gateways_stripe.php – Line 1791

I wonder if that’s the problem? maybe the event is being caught by the default and is storing the wrong data?

ok, I’m seeing a few row in wp_postmeta with post_ids of ‘0’.

Should I delete those?

Paul

Yes, exactly.

Thanks again,

Paul

No, I’m afraid there’s nothing there with those as IDs.

But what I’m seeing if I add console.log(idx); to the above javascript function is a list of post ID’s followed by the 2 extra entries: crc32 and adler32.

Cheers,

Paul

It looks like crc32 and adler32 are something to do with checksum, although I’ll need to look up what that is.

Could it be to do with my hosts doing some security bits?

Cheers,

Paul

Nope, no woo.

I’ll have a check for posts with those names.

Thanks again.