Hi @keniry
I appreciate the time you took to type out this review. I’ll respond with equal attention to detail!
Since you state that the root issue you have with GiveWP is our support team (and I’m the Head of Support) I’ll start with that, and return to your more specific concerns at the end.
I’ve taken a detailed look at all of our interactions with you in priority support, and have made the following observations:
1. We definitely could have done better on some of our replies, in terms of educating you on how the product works, and in terms of moving every conversation toward resolution more quickly.
2. There was a lot of miscommunication in terms of our team not fully understanding what your problem was, and we could have done better at internally discussing them to get a more comprehensive reply back to you instead of spending time with back-and-forth that wasn’t moving things toward resolution.
We take support very seriously, and I hate that you had that experience with our team. I firmly believe in growing and learning, and all of us are looking into how we can learn from this situation. Your success with online donations is our number one priority.
Now, back to your specific issues, which I’ll reply to in order:
1. PageSpeed insights: you’re right that GiveWP is fairly heavy in terms of scripts and styles loading on pages where they are not needed, and that’s something that Google increasingly frowns on. One of the near-term goals on the product roadmap is to optimize and only call those scripts when needed. We have some custom code snippets for only calling those scripts on certain pages that some developers have had success with. Additionally, there is known feedback on our feedback site that address performance. I’ve looped in our Lead developer to weigh in on a public reply there: https://feedback.givewp.com/feature-requests/p/givewp-should-enqueue-scripts-only-on-needed-pages-instead-of-adding-it-to-the-e
The only defense I have of that is that some very large and very successful sites have atrocious pagespeed scores, so while it’s important, it’s not everything.
2. We’re happy to look into the PHP errors in the logs, but this is not the best forum for that.
3. Donation spam: absolutely every ecommerce platform (especially the open source ones that run on WordPress) deals with purchase spam. Donations are particularly ripe for that because there’s no cart: so a bot can load in 100s or 1000s of card numbers into the form and just slam it over and over. It’s something that we have taken great pains to address in the past, and will continue to. Your particular issue is that some of the fraudulent transactions were going through on Stripe, and some were not.
The good news is that, in addition to all of the steps we provided you (though I’m not sure if you tried any of them, and eager to help if you’re still having problems) we are also working to add in more protections for site owners to combat spam. Here’s the feedback post for that: https://feedback.givewp.com/bug-reports/p/additional-spam-donation-protection
As a side note, the webhook would have nothing to do with donor spam. It’s just the one-way communication from Stripe back to your site to alert your site of something that happened there. So if the spam is getting all the way through to Stripe and triggering an event that is sent over the webhook, then the fix is to stop it before a webhook is involved.
4. That brings us to pending donations: It’s a great idea to make the webhook and the steps to correctly configure it more prominent, but there’s no way for the GiveWP side to “detect” if it’s set up, because Stripe doesn’t allow access over the API to see the configured webhooks. Presumably, that’s a bit too much of a security risk. So we only know that the site is connected to a webhook when we start getting transactions and events sent over the webhook. We made a special popup immediately after connecting to Stripe, and reference it multiple places in our docs, with the hopes that folks will get connected. If they don’t, we’re more than happy to help the get things set up in priority support or here on the forums.
5. Email access: the reference in the docs to limiting the number of donations is related to how many donations display if you HAVEN’T been authenticated. If I try to donate with an email address that I know is already a donor, I shouldn’t be able to see the previous donations made by that donor until I am authenticated. Just the one that I just made.
If you are seeing donations being displayed to the wrong person, that’s a telltale sign that caching is causing issues, and delivering a cached page to subsequent users. You should exclude any page on your site that displays donor information from the cache. That’s a thing that your caching provider can help with.
Finally, very glad that donations are actually working for you. I’m happy to continue the discussion over in priority support, where you still have an account!
