Forum Replies Created
-
Posts
-
Some additional info: I checked on the events log for payments from that other non-Wordpress application, and the log tells me that it was initially received with the correct description (coming from their app), and this was followed by an additional request, updating it to the wrong description (coming from WordPress):
Source Stripe/v1 PhpBindings/7.28.1 Stripe Payments/2.0.43 (https://wordpress.org/plugins/stripe-payments/)
POST /v1/payment_intents/pi_xxx
200 OK
View log detail
Request parameters
{
“description”: “Summit – Payment Plan 2 (3x USD 370.-) (2 of 3)”
}So it seems that the plugin on WP is doing “rogue updates”? Btw. is there a link to the previous version of the plugin?
Hi, I used the test version and made a few test requests, trying both with and without a short description for the product (which is a normal separate, single product yes): Still incorrect, and at the same time I also realized that it affects (single) payments coming to the API from another application (ie. not from WordPress). That seems more than surprising, so now I am thinking of invoking Stripe support.
Subscription update payments (also from the other app) are coming through correctly btw. And interestingly, those don’t update that “wrong” description (see below) that is being used, this one is just stuck.
In the object you see a mix of the correct description (Summit – Hawaii In-Person Option) and the incorrect description (Summit – Payment Plan 3 (4x USD 277.50) (2 of 0))
{ "id": "", "object": "payment_intent", "last_payment_error": null, "livemode": false, "next_action": null, "status": "succeeded", "amount": 33300, "amount_capturable": 0, "amount_received": 33300, "application": null, "application_fee_amount": null, "canceled_at": null, "cancellation_reason": null, "capture_method": "automatic", "charges": { "object": "list", "data": [ { "id": "", "object": "charge", "amount": 33300, "amount_captured": 33300, "amount_refunded": 0, "application": null, "application_fee": null, "application_fee_amount": null, "balance_transaction": "", "billing_details": { "address": { "city": "", "country": "AT", "line1": "", "line2": null, "postal_code": "1234", "state": "" }, "email": null, "name": "", "phone": null }, "calculated_statement_descriptor": "ASCENSION ONE", "captured": true, "created": 1612861937, "currency": "usd", "customer": "", "description": "Summit – Payment Plan 3 (4x USD 277.50) (2 of 0)", "destination": null, "dispute": null, "disputed": false, "failure_code": null, "failure_message": null, "fraud_details": { }, "invoice": null, "livemode": false, "metadata": { "Product Name": "Summit - Hawaii In-Person Option", "Product ID": "20523" }, "on_behalf_of": null, "order": null, "outcome": { "network_status": "approved_by_network", "reason": null, "risk_level": "normal", "risk_score": 25, "seller_message": "Payment complete.", "type": "authorized" }, "paid": true, "payment_intent": "", "payment_method": "", "payment_method_details": { "card": { "brand": "visa", "checks": { "address_line1_check": "pass", "address_postal_code_check": "pass", "cvc_check": "pass" }, "country": "US", "exp_month": 4, "exp_year": 2022, "fingerprint": "", "funding": "credit", "installments": null, "last4": "4242", "network": "visa", "three_d_secure": null, "wallet": null }, "type": "card" }, "receipt_email": "", "receipt_number": null, "receipt_url": "", "refunded": false, "refunds": { "object": "list", "data": [ ], "has_more": false, "total_count": 0, "url": "" }, "review": null, "shipping": null, "source": null, "source_transfer": null, "statement_descriptor": null, "statement_descriptor_suffix": null, "status": "succeeded", "transfer_data": null, "transfer_group": null } ], "has_more": false, "total_count": 1, "url": "" }, "client_secret": "", "confirmation_method": "manual", "created": 1612861934, "currency": "usd", "customer": "", "description": "Summit – Payment Plan 3 (4x USD 277.50) (2 of 0)", "invoice": null, "metadata": { "Product Name": "Summit - Hawaii In-Person Option", "Product ID": "20523" }, "on_behalf_of": null, "payment_method": "", "payment_method_options": { "card": { "installments": null, "network": null, "request_three_d_secure": "automatic" } }, "payment_method_types": [ "card" ], "receipt_email": "", "review": null, "setup_future_usage": "off_session", "shipping": null, "source": null, "statement_descriptor": null, "statement_descriptor_suffix": null, "transfer_data": null, "transfer_group": null }(Ids and personal data are removed from the object.)
Yes, but here is something that might be relevant – while it is not multisite, we do access the backend on a subdomain. Could that be an issue? Still as said above, it is able to find it eventually on the settings page itself in 99% of the cases.
As the webhook obviously is not a physical URI, so I am wondering how/where it is being created (thus how it could even be deleted by something else)?
No, no multisite. Can you tell me in what form the webhook actually exists? Or how the plugin tries to check for its existence? This could be helpful for narrowing down the issue.
So here is what happened in the meantime. Basically every day, in the backend I would get the warning that the webhook is not existent or configured properly. Simply going to the config module (edit.php?post_type=asp-products&page=stripe-payments-settings#sub), it would in fact find it right away – “Live Webhook Status – Webhook exists”, and upon another refresh the error message on top would go just away by itself.
But today, the webhook has indeed gone missing again, and I had to recreate a new one, and delete the old one in the Stripe dashboard. The test webhook however was still there and fine.
Please, how can this keep happening?
Ok thanks, I updated the plugin, removed all extraneous webhooks and created fresh ones through the settings.
So far looking good, but I do see now that I have payments in the WP subscriptions module, which were tracked multiple times by the plugin, even though only one payment was actually made, thus ending the payment plan prematurely.
October 16, 2020, 5:09 pm Subscription ended —
October 16, 2020, 5:09 pm Subscription ended —
October 16, 2020, 5:09 pm Subscription ended —
October 16, 2020, 5:09 pm Subscription ended —
October 16, 2020, 5:09 pm Subscription ended —
October 16, 2020, 5:08 pm Regular payment made $296.00
October 16, 2020, 5:08 pm Regular payment made $296.00
October 16, 2020, 5:08 pm Regular payment made $296.00
October 16, 2020, 5:08 pm Regular payment made $296.00
October 16, 2020, 5:08 pm Subscription createdI guess that is a result of those multiple webhooks? Any way to resolve/fix/reset this from the WP/plugin end, or do we have to resolve this manually?
Thanks!
Now this seems an improvement for sure, also I am now able to manually resend requests from Stripe to WP, which had previously failed.
I also notice that it looks like as if the same webhook were set up multiple times (which I did certainly not do manually) – I am having
https://(domain)/?asp_hook=live
five times in the list of webhooks in the Stripe dashboard, with four of these actually tracking activity. Does that make sense?
I did that, and it is fine for a while, before the errors start popping back up. And thus, the error log is still filling with the fatal errors. And the webhook error statistics in the Stripe dashboard is climbing, now at 43% errors.
Got error ‘PHP message: PHP Fatal error: Uncaught Stripe\\Exception\\SignatureVerificationException: No signatures found matching the expected signature for payload in /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/stripe-payments/includes/stripe/lib/Exception/SignatureVerificationException.php:28\nStack trace:\n#0 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/stripe-payments/includes/stripe/lib/WebhookSignature.php(61): Stripe\\Exception\\SignatureVerificationException::factory(‘No signatures f…’, ‘{\\n “id”: “evt_…’, ‘t=1602668831,v1…’)\n#1 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/stripe-payments/includes/stripe/lib/Webhook.php(29): Stripe\\WebhookSignature::verifyHeader(‘{\\n “id”: “evt_…’, ‘t=1602668831,v1…’, ‘whsec_…’, 300)\n#2 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/stripe-payments-subscriptions/inc/asp-sub-stripe-webhooks.php(32): Stripe\\Webhook::constructEvent(‘{\\n “id”: “evt_…’, ‘t=1602668831,v1…’, ‘whsec_…’)\n#3 /opt/bitnami/apps/wordpre…\n’
Hi Alexander,
Yes there are errors, but they are only occasional. I checked the server error log, and this is what I am getting:
—
Got error 'PHP message: PHP Fatal error: Uncaught Stripe\\Exception\\SignatureVerificationException: No signatures found matching the expected signature for payload in /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/stripe-payments/includes/stripe/lib/Exception/SignatureVerificationException.php:28\nStack trace:\n#0 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/stripe-payments/includes/stripe/lib/WebhookSignature.php(61): Stripe\\Exception\\SignatureVerificationException::factory('No signatures f...', '{\\n "id": "evt_...', 't=1602316361,v1...')\n#1 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/stripe-payments/includes/stripe/lib/Webhook.php(29): Stripe\\WebhookSignature::verifyHeader('{\\n "id": "evt_...', 't=1602316361,v1...', 'whsec_...', 300)\n#2 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/stripe-payments-subscriptions/inc/asp-sub-stripe-webhooks.php(32): Stripe\\Webhook::constructEvent('{\\n "id": "evt_...', 't=1602316361,v1...', 'whsec_...')\n#3 /opt/bitnami/apps/wordpre...\n—
Thanks
