isaac2017

Hi Clayton.

You can count me in. ??

Hi Clayton,

Good to hear that.
How do you want me to pass the doc to you?

Isaac

Hi Clayton,

I also have a version of their documentation which is only available to developers participating in their beta program. If you are interested, I can email it to you as its a private document linked to stripe users with SG accounts.

Isaac

Hi Clayton,

So this happens for both redirect and webhooks.

I have made some progress in the debugging of the isses.
The normal scenario based on the log is as such.

1. Customer clicks on checkout in the checkout page.
2. Gets redirected to bank for further processing.
4. After customer has filled in required security info, bank start processing.
5. webhook.charge_succeeded is received.
6. webhook.paymentintent_succeeded is received.
7. redirect to order received page.
8. payment_method->process_payment is executed.
9. Order is now completed.

Now the problem arises here. The webhooks did not manage to get back to the server and during the payment_method->process_payment execution, stripe returns the with the error message that the payment intent is no longer valid because the order has already been charged and paid for in stripe.

I am thinking is there a way to use the payment_intent payload which is returned with the result to process the payment information properly.
eg. $result[‘error_data’][‘payment_intent_error’][‘payment_intent’]

What do you think?

Hi Clayton,

I have not added any new filters for the based plugin functionality, so the payment intent methods is currently in its default state.

Thanks for the process_payment pointer. I added an action at “wc_stripe_before_process_payment” to check if the order status is completed and added wc_add_notice so that the payment process would he halted.

Am not sure if this hack would work, will be monitoring the outcome through the day.

Thanks for your help.

Hi Clayton,

Thanks a million.
Will wait for your update and make the appropriate changes from my side.

Will leave a review soon.
Thank you for getting back to me on this so promptly.

Hi Clayton,

Yeah, we did but the title of the payment is easier to read when its with the formatted id. Another reason is that we did not want to expose the internal ID’s to our third party vendors (which included stripe) so that all communications between customer, vendor and us are based on a common “friendly” information.

Do you think you could add this filter or something similar so that ID’s like we use be compatible? Or if you have other ideas that can help me address this concern, I would appreciate it.

Thank you.

Hi Malachite,

1. Can I refer to them plugin issues or do they just handle the MailChimp side of the equation?

2. I actually had resync it once and am weary of trying again, it takes a long time to resync the past purchases. It seems that it is timing out, if I look at the code that generates that particular error code.

I am currently in a time sensitive project and appreciate your assist on this.

Thanks.

Hi Malachite,

I just noticed that there are a lot of logs indicating that the sync has stop for orders.

2017-11-28T21:06:38+08:00 NOTICE sync.stop :: halting the sync for :: orders

Does this give you a clue on what i should look at?

Hi Malachite,

thanks for the reply.

1. Can I send this over to you on a private channel? I am not comfortable posting it over a public forum.

2. The members e-comm tab that I am referring to is the tab within mailchimp site (https://usx.admin.mailchimp.com/lists/members/) in which I use to monitor what is being posted to mailchimp from woocommerce.

3. Yes I have created a test purchase and it does not sync over at all when I check at mailchimp.com