Page 1 of 2
Users Are Not Degraded
Posted:
September 27th, 2010, 11:50 pm
by erichamby
After a user subbscriptions runs out thier account is not degrading back to a normal user. Is thier a normal cause for this?
Re: Users Are Not Degraded
Posted:
September 28th, 2010, 5:10 pm
by erichamby
Any ideas guys?
Re: Users Are Not Degraded
Posted:
September 30th, 2010, 3:45 pm
by erichamby
Im getting this email from paypal.
automatic payments from XXX have failed 1 times. As a result, we will not try to process these payments again. Please contact your customer to collect the outstanding balance.
Customer name: XXX
Customer email: XXX
Automatic payment ID: XXX
Profile status: Suspended
For: Daily
Payment due: Sep 30, 2010
Outstanding balance: $2.00 USD
But when i look at my admin side this user is still a VIP member and was not downgraded to subscriber.
Re: Users Are Not Degraded
Posted:
October 2nd, 2010, 10:58 am
by Elizabeth
Hi,
Do you have the Logging Routines Enabled?
If you do, what is being reported by PayPal to s2member?
If you do not.
Please Enable them and see what is being passed:
Dashboard -> s2Member -> PayPal Options -> Enable Logging Routines? -> Yes.
Re: Users Are Not Degraded
Posted:
October 2nd, 2010, 2:41 pm
by erichamby
What exacly am i looking for in the logs?
Re: Users Are Not Degraded
Posted:
October 22nd, 2010, 4:53 am
by Jason Caldwell
Hi Eric. Thank you for your patience.
Apologies for the delayed response.
It sounds to me like this Member has been failing payments. By default, PayPal will retry the failed payment 2 more times after the initial failure. After the 3rd consecutive failed payment, PayPal will terminate the Recurring Profile and s2Member will be notified via IPN. The Member will be demoted/deleted at that time, based on your configuration of s2Member.
See: s2Member -> PayPal Options -> EOT Behavior
If this information does not help, please feel free to post or email your s2Member log file for review. In order to enable logging, you must log into your Dashboard, and go to: s2Member -> PayPal Options -> Account Details -> Debugging/Logging.
Once enabled, your logs will be stored here:
/wp-content/plugins/s2member-logs/paypal-ipn.log
Hopefully you've had logging enabled so we can see exactly what has happened. Whenever you post your log file, please be sure to include details for us, so we know what Member to look for in the logs.
Re: Users Are Not Degraded
Posted:
October 22nd, 2010, 3:18 pm
by erichamby
Im only getting 1 email about a failed payment attempt and it says it wont try anymore.
Paypal ipn logs:
http://hotfile.com/dl/77689174/9da6165/ ... n.zip.html
Re: Users Are Not Degraded
Posted:
October 22nd, 2010, 3:38 pm
by Jason Caldwell
Hi Eric. Thank you.
Which Member are we analyzing in this file? An email address or Recurring Payment ID will be fine. Anything we can use to reference the Member in question.
Re: Users Are Not Degraded
Posted:
October 22nd, 2010, 4:38 pm
by erichamby
All of them, i have not had any member degrade. I been having to look up the profile IDs in paypal and see when they paid to degrade them myself.
Re: Users Are Not Degraded
Posted:
October 22nd, 2010, 9:23 pm
by Jason Caldwell
I've taken a good look at your log file Eric. It appears that your installation of s2Member HAS been receiving failed payment notifications from PayPal's IPN system. However, these IPNs have failed twice thus far. Once for two different Members; according to the log file you sent over.
Here is what's happened in both instances:- Code: Select all
'recurring_payment_id' => 'I-X36W14YARBWU',
'product_name' => 'Daily',
's2member_log' =>
array (
0 => 's2Member POST vars verified through a POST back to PayPal®.',
1 => 'Unable to verify _SERVER[HTTP_HOST]. Possibly caused by a fraudulent request. If this error continues, please check the `custom` value in your Button Code. It MUST start with your domain name.',
),
So the custom="" attribute in your original Shortcode was not properly configured. According to your log files, the domain you're running s2Member on is:
www.XXX.com. I suspect that is NOT correct? What you should have in your Shortcode, is a custom value matching the installation domain that s2Member is being hosted on. So something like this should appear in your PayPal Button Shortcode.
- Code: Select all
[s2Member-PayPal-Button ... custom="www.YourDomain.com" /]
I hope this offers you some insight. Please let me know if you continue to have trouble.
Re: Users Are Not Degraded
Posted:
October 22nd, 2010, 11:10 pm
by erichamby
yea ... my domain does appear there, i placed the XXX there myself after downloading the log from ftp since my site is private. So the XXX does not have anything to do with it.
Re: Users Are Not Degraded
Posted:
October 22nd, 2010, 11:28 pm
by Jason Caldwell
Gotchya. Thanks for the clarification.OK. So another possibility here is that s2Member was unable to perform a lookup on the Custom value associated with recurring_payment_id
I-X36W14YARBWU. Please have a look at your list of Users in WordPress®, and see if you can find a User with this Paid Subscr. ID "
I-X36W14YARBWU". That Member should be associated with a Custom value, which you can view in your Dashboard by clicking "Edit" next to their name in the list.
In other words, this error:Unable to verify _SERVER[HTTP_HOST]. Possibly caused by a fraudulent request. If this error continues, please check the `custom` value in your Button Code. It MUST start with your domain name.could also be the result of a missing Custom value in your database. s2Member will try to perform a database lookup using the recurring_payment_id "
I-X36W14YARBWU". If that fails, s2Member has no reference to the Member's account.
So the next steps in debugging the issue, are to verify the Custom value associated with each of your Members that failed in the log file. These Members have the following Paid Subscr. IDs:
I-X36W14YARBWU
I-2FB4LD3SFMBBIf you'd like to provide me with a Dashboard login, I'll be happy to investigate further and run debugging routines on your installation to diagnose the issue. Otherwise, please report back with the s2Member "Custom" values listed in your Dashboard for these two Members.
If you plan to provide me with Dashboard access, please use this private contact form.
Re: Users Are Not Degraded
Posted:
October 22nd, 2010, 11:33 pm
by erichamby
chances are i cause this also. when i degrade a user by hand i also delete there profile id number. which would cause this error but still dont explain why i would have to degrade the account myself days after failed payments.
Re: Users Are Not Degraded
Posted:
October 22nd, 2010, 11:45 pm
by Jason Caldwell
Thanks for reporting back Eric.
~ Much appreciated.
OK. So it sounds like the problem may have been caused by some doubt about whether s2Member would deal with the failed payments as it should. Please keep in mind that s2Member is dependent upon PayPal. After payments have failed multiple times in a row, s2Member will be notified by PayPal ( as indicated by your log file ). If you jump the gun a bit, and demote/delete the Member manually before that IPN notification is received by s2Member, just be sure to leave the original Paid Subscr. ID and Custom values in the database. This will allow you to build confidence in s2Member over time.
I also recommend monitoring your log file for these IPN messages:
txn_type=recurring_payment_suspended_due_to_max_failed_payment
( please compare dates in your existing log file as well for some clarity )
This is the IPN event ( recurring_payment_suspended_due_to_max_failed_payment ) sent by PayPal automatically when a Member's payments have consistently failed. PayPal may not always send this notification to s2Member spot on. I've seen them get backed up and it sometimes takes an extra day or two, even after the account has been suspended. In other words, the email that you receive as the merchant, may not always be synchronized with the IPN communication behind-the-scene.
If I've missed something here, or misunderstood you in some way, please let me know. I'm always interested in hearing reports like this. It's people like you ( paying close attention ) that have made s2Member what it is today. ~ Thanks!
Re: Users Are Not Degraded
Posted:
October 23rd, 2010, 12:26 am
by erichamby
i got 2 users thats accounts will run out sunday so ill wait to see what happens once more. i have waited about 2 weeks however and still they users account has not been degraded. The email i get from paypal says they there has been a failed payment attempted and there will be no more attempts. so i guess it only tries once. Where do i see this setting in paypal?
Re: Users Are Not Degraded
Posted:
October 23rd, 2010, 1:01 am
by Jason Caldwell
Sounds good Eric. Please keep us updated.erichamby wrote:so i guess it only tries once. Where do i see this setting in paypal?
Documented here: https://cms.paypal.com/us/cgi-bin/?&cmd ... 9A7G0502UIThe default is 2.
- Code: Select all
Reattempt on failure. If a recurring payment fails, PayPal attempts to collect the payment two more times before canceling the subscription.
Taken from this documentation: https://cms.paypal.com/us/cgi-bin/?cmd= ... 8A7C30G05ZBoth s2Member, and s2Member Pro use the default setting of 2 failed payments maximum. In the case of s2Member Pro, there is a hard-coded reference to this in all PayPal API communication.
- Code: Select all
$paypal["MAXFAILEDPAYMENTS"] = "2";
/s2member-pro/includes/functions/paypal-checkout.inc.php
Re: Users Are Not Degraded
Posted:
October 23rd, 2010, 1:45 am
by erichamby
Could this be whats caused my issues? it is set to suspend the account after 1 failed attempt, does the plugin need more than 1?
Re: Users Are Not Degraded
Posted:
October 23rd, 2010, 1:55 am
by Jason Caldwell
I would watch the dates closely. It sounds like your PayPal account is sending you email notifications that reference a single failed payment ( and refer to it as the "last" one ); when in reality, your Customers are allowed up to 2 failed payments in a row. I suspect this is what's creating what appears to be a huge delay on the part of s2Member and the IPN system. I've seen this happen in Sandbox test mode, but never on a live account. It's hard to know for sure though. Please monitor your dates and keep us posted. You may also want to contact PayPal and report this discrepancy.
Re: Users Are Not Degraded
Posted:
October 23rd, 2010, 2:00 am
by erichamby
I also still dont see where to change the setting in paypal for this. i would set it for 2 times but cant. i followed the instructions in your last post but wont let me edit it. ill keep looking into it and let ya know.
Re: Users Are Not Degraded
Posted:
October 23rd, 2010, 4:19 am
by Jason Caldwell
In our observation, PayPal Pro account holders can also edit Recurring Profiles ( if they originally went in as a Recurring Profile ) using a PayPal Pro integration, which is the case with s2Member Pro Forms. With PayPal Pro integration, s2Member is responsible for configuring "MAXFAILEDPAYMENTS" through its API integration with PayPal. s2Member Pro uses the default configuration of 2.
-----------------------------------
Otherwise, if you are using PayPal Standard Integration with the free version of s2Member, there is no way to adjust this setting. PayPal uses a default value of "2" with all standard "Subscriptions", according to the documentation here:
https://cms.paypal.com/us/cgi-bin/?cmd= ... 8A7C30G05ZPayPal wrote:Reattempt on failure. If a recurring payment fails, PayPal attempts to collect the payment two more times before canceling the subscription.
Actually, there is one way to adjust it. You can modify the full version of your PayPal Button Code, by adding an "sra" input variable and setting it to "0". This just disables failed payment retries all together ( on a per-Subscription basis, as it's created ). So it's an on/off switch essentially. See:
https://cms.paypal.com/us/cgi-bin/?cmd= ... 8A7C30G05ZPayPal wrote:sra ( Optional ) Reattempt on failure. If a recurring payment fails, PayPal attempts to collect the payment two more times before canceling the subscription.
Allowable values:
0 – do not reattempt failed recurring payments
1 – reattempt failed recurring payments before canceling
The default is 1.
Re: Users Are Not Degraded
Posted:
October 23rd, 2010, 2:39 pm
by erichamby
Shouldnt i be able to not use reacurring payments and that would work? if this is the issue anyways.
Re: Users Are Not Degraded
Posted:
October 23rd, 2010, 7:23 pm
by Jason Caldwell
erichamby wrote:Shouldnt i be able to not use reacurring payments and that would work? if this is the issue anyways.
Certainly. If you generate a "Buy Now" button with s2Member's Button Generator, these are one-off transactions that are not tied to Recurring Profiles or Subscriptions. You will lose the ability to charge your Customer's on a recurring basis though.
Re: Users Are Not Degraded
Posted:
October 27th, 2010, 10:15 pm
by erichamby
Its strange that even when a user cancels thier membership the system never tries to charge them but also doesnt degrade the account.
Re: Users Are Not Degraded
Posted:
October 30th, 2010, 3:28 am
by erichamby
Any more info you can give?
Re: Users Are Not Degraded
Posted:
October 30th, 2010, 4:16 am
by Jason Caldwell
Hi Eric. Thanks for the follow-up.Based on my previous examination of your log files,
it appears to me that PayPal is communicating properly with PayPal.
In other words, PayPal IS sending s2Member an IPN once payment fails enough times.
Jason Caldwell wrote:I've taken a good look at your log file Eric. It appears that your installation of s2Member HAS been receiving failed payment notifications from PayPal's IPN system. However, these IPNs have failed twice thus far. Once for two different Members; according to the log file you sent over.
Here is what's happened in both instances:- Code: Select all
'recurring_payment_id' => 'I-X36W14YARBWU',
'product_name' => 'Daily',
's2member_log' =>
array (
0 => 's2Member POST vars verified through a POST back to PayPal®.',
1 => 'Unable to verify _SERVER[HTTP_HOST]. Possibly caused by a fraudulent request. If this error continues, please check the `custom` value in your Button Code. It MUST start with your domain name.',
),
And as we discussed later, these errors were most likely a result of you deleting the Member before s2Member received the IPN response from PayPal. So these IPN failures WOULD have been processed successfully, but because you had already removed the Member manually, they failed.
Is that not correct?
If you have another log file you can send over with additional concerns you'd like us to address, please feel free to do so. If there is something I'm missing here, I'll be happy to have another look for you.