Forum Replies Created
March 25, 2019 at 11:20 am in reply to: Let all traffic from a given IP address through paywall #79374
Yes, we used an internal plugin, but the performance hit is nasty and the plugin is not being maintained now.
So probably need the custom coding. I will revert on that.
JohnMarch 23, 2019 at 12:09 pm in reply to: Let all traffic from a given IP address through paywall #79372
That’s exactly it, and much better explained that I did!March 22, 2019 at 12:27 pm in reply to: WP eMember – Password Reset Email Does not Include the Password #72502
Just wondering if it is possible to use the wordpress password reset logic instead of WP emember?
I tried this, but discovered that when a user changes their WP password, it does not change the password in the WPemember member table.
Just wondered if there might be a function that could be hooked onto the wordpress password update code to fix that?
Thanks very much, that’s what I will do. Great support as always.
I note that Tips and Tricks has the new Stripe Plugin up and running with Apple Pay even for subscriptions: way cool!
So I was wondering what you plans, if any, are to port that capability to the Payment Gateway Bundle Plugin add on for WP eStore were?
And I also note that WP Emember has been upgraded to work with the Stripe Plugin.
So the other option I’m considering is to go with the Stripe Plugin (and the add on bundle) as a replacement for WP estore. (We only sell memberships so a lot of estore’s functionality is wasted for us.)
That leaves the question about what to do about our members, both existing and future, who still want to use PayPal, but we could revert to PayPal buttons for paypal subscriptions only (no credit cards) for that, particularly since we are depreciating PayPal as much as our users will let us. (Stripe is way easier to work with).
Are there any pitfalls in that last idea that I have not thought of?
Yup, that will definitely fix it. The key point being that we have manually verified that every time PayPal has sent both numbers the “S” number has been the one that corresponds with the number in WP eMember.
And by the way, I went back and checked in a Google spreadsheet we update with every IPN, using Zapier and WPES’s excellent IPN passthrough feature, and there was no hint of “I” numbers in any of our IPNs prior to June 11th 2018. I think what was happening was that they were using I numbers for what they then called “advanced subscriptions” (credit card with no paypal account required), which we did not use (prefer Stripe). (That’s why you are seeing I numbers prior to June on your clients that used Advanced Subscriptions.
Then from June 11th they changed to giving all new Subscriptions (advanced or standard, an I number) but still sent S numbers for IPNs that related to subscriptions set up prior to June and I numbers for those set up afterward.
The trouble started on October 25 when they started sending all IPNs with I numbers and added the old_subscr_id variable. Would have been fine if they told us, but I have checked their IPN docs and there is, as yet, no mention of the old_subscr_id. I reported this to them yesterday.
One other issue to be aware of. These IPN changes seemed to have partially broken the IPN passthrough feature on eStore too, since some notifications that I have verified were sent from PayPal are not coming through out of eStore. I need to do more work to accurately define which passthrough and which don’t.
Let’s fix the first issue of recognizing the old_subscr_id variable and then I will work more on defining the pass through issue.
Thanks for the help, as always.
The examples I’m showing above are only a year or so old.
I think you are checking you numbers on PayPal? If so, you are being misled because all paypal screens have suddenly been changed to only show the “I” number even if the subscription was originally set up with an S number. That said, they are keeping the S number on their database and not displaying it.
I know this for two reasons:
1 Paypal only started using I numbers at all in early 2018. See this quote from the original PayPal email:
Beginning February 22, 2018, all new subscriptions will be created with a subscription ID beginning with the characters I- (e.g. I-5APLHGTHC2N4). Prior to this change, subscriptions were created with IDs beginning with the characters S- (e.g. S-5APLHGTHC2N4).
What they didn’t tell us is that they were going to give all old subscriptions an I number too, and they did that some time in the last couple of months.
2. If we look at the example notifications I copied in my comment above we see that now there are two variables:
So the problem is that the WPEM and WPES IPN handlers are not recognizing the old_subscr_id=S-84U22277TD2214514 variable.
We can see this from the log:
FAILURE :No member found for the given subscriber ID:I-3FDD900PEUHY
Bottom line, this is a general problem, but hard to catch since it will only affect member cancelations in cases where we or the member cancel at PayPal.
We only found it by chance.
The bad thing is that many WPEM customers will be giving free memberships to those who have canceled and never know.
Just realized that in my configuration it’s WP estore that handles Paypal cancels. Here’s the relavant log entries showing the fail:
As you can see eStore is not picking up the old_subscr_id=S-84U22277TD2214514 (why would it) that paypal is now sending.
Hope that helps.
[10/28/2018 1:20 PM] – SUCCESS :Subscription cancellation notification check for eMember – check if a member account needs to be deactivated… subscr ID: I-3FDD900PEUHY
[10/28/2018 1:20 PM] – SUCCESS :Retrieving member account from the database…
[10/28/2018 1:20 PM] – FAILURE :No member found for the given subscriber ID:I-3FDD900PEUHY
[10/28/2018 1:57 PM] – SUCCESS :Subscription cancellation notification check for eMember – check if a member account needs to be deactivated… subscr ID: I-SBAMVHR3BW0X
[10/28/2018 1:57 PM] – SUCCESS :Retrieving member account from the database…
[10/28/2018 1:57 PM] – FAILURE :No member found for the given subscriber ID:I-SBAMVHR3BW0X
OK, I have got to the bottom of this. What they have done is they are now sending both the old and new profile numbers in the IPN. Below is an IPN for a subscription profile I just canceled myself at paypal. (I have xxxxx out user-sensitive information.)
So I guess there’s nothing for it but to update the IPN/API handling in WP eMember to handle this new behaviour.
Bummer! The joys of doing business with PayPal.
amount3=19.99&address_status=confirmed&subscr_date=06:20:52 Oct 28, 2018 PDT&payer_id=SSADFCZCLBACQXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXsubscr_id=I-3FDD900PEUHYemail@example.com&address_country=United States&old_subscr_id=S-84U22277TD2214514&address_city=xxxx&verify_sign=Aicup8xSELK2A7DEGC9CICwUe3RQAFLGrYE0HU77EPTw1yLwjOWD9Axs&payer_email=xxxxxxxxxxxx&payer_business_name=xxxxxLLCfirstname.lastname@example.org&recurring=1&txn_type=subscr_cancel&item_name=Member One Year, Auto Renewal&mc_currency=USD&item_number=1&residence_country=US&period3=1 Y&ipn_track_id=f40b67bc69317
I agree, a bug at PayPal. I have also reported it to Merchant Support and will revert here when I get an answer.
The nasty thing about this is that many WPEM users will be inadvertently giving their canceled members free access and probably won’t notice. We only came across the problem by chance.
Thanks for following up too.
It seems like we are now seeing a a problem with this.
Recently, Paypal have started sending IPN messages such as those for some cancelations, with the new numbers starting with “I”, even though the subscription was set up with the old number starting with “S”. The result is that WP eMember does not update the member’s status to expired or inactive.
Of course this is not T&T’s fault or responsibility. In fact I’m not sure how you would even fix it since how could you be sure a cancelation is for a given subscription without matching the Subscriber ID.
I’m beating on Paypal about this, but we all know what a futile business that is.
Anyway, I thought you would like to know.
As far as I can see, this problem is limited to memberships that we cancel by the member themselves in their PayPal account. Cancelations due to credit card fails are still working.
The work around is to keep an eye out for the cancelation notice email from PayPal which ironically contains both the old “S” number and the new “I”number and manual cancel the member.
The only other thought I had, is that I have been traveling all summer and so am still at WPEM 10.0.7, so maybe Paypal are sending both numbers and T&T has updated to reflect that. Anyway, as soon as I clear my desk, I will update to the latest version of WPEM.
Great support! thanks. Got it and will test.
Thanks for quick reply. One more question that will affect how I ask for the change:
Can I use The Basic Stripe gateway option for subscriptions?
I tried the same short code as for the normal stripe subscriptions, but it did not work (not surprising).
Since I sell a lot of subscriptions, I would need a user to be able to use the Basic Stripe Pop Up window for a subscription. So if that needs a change, I want to make sure I ask for that at he same time I’m asking for Apple Pay.
(Much to my surprise, Stripe indicate that they have subscriptions working with Apple and Google Pay.)
Is there a code to make Strip Basic the default payment method instead of Paypal? I tried “stripe” but that seems to only work with normal stripe.
I also looked in the code, but was not smart enough to find it.
I can sure see why T&T does not want to do a full Apple Pay gateway! But I think I have a simpler answer.
I have just been experimenting with Apple Pay through Woo Commerce. They are basically just using Stripe’s implementation of Apple Pay, which seems to work well, even with subscriptions.
(I love WP eStore and don’t want to change to Woo)
So how about just adding the Apple Pay and Google Pay option to the Payment Gateway bundle Simple Stripe Popup window implementation.
On Woo this is just an option called Apple Pay Request Buttons (Applepay and Google)
I think that this is simply a matter of passing the enable flag (like with Bitcoin) to Stripe and they take care of all the Apple/Google BS from there.
As always, I would be happy to pay for this change.