Jason (Lead Developer)

Thanks for reporting this important issue.

We fixed a bug related to this in s2Member v120309, where a problem would sometimes occur under installations of PHP that were running in SAFE mode (due to cURL limitations with respect to redirections).

However, it sounds like you’re still reporting problems in the latest release even. I’m not aware of this being a widespread issue, so I have to assume (at least at this point), that it’s a server-dependent issue.

If your PHP installation supports allow_url_fopen (see this article), I would suggest the following hack to see if it helps any. Please report back with your findings. If I find a way to avoid this compatibility issue all together, I’ll be happy to update s2Member in a more official capacity going forward.

Create this directory and file please:
/wp-content/mu-plugins/s2-hacks.php
( these are MUST USE plugins, see: http://codex.wordpress.org/Must_Use_Plugins )

<?php
add_filter ("use_curl_transport", "__return_false");
// This way WordPress will use FOPEN, which might work better in some environments.
?>

In short, disabling the cURL transport method in your WordPress installation, will force WordPress to fall back on another available transport supported by your server. Thereby (hopefully) allowing the communication between WordPress and Amazon to succeed, where it may have been failing under the cURL transport for a reason that is yet to be determined at this point.

Hi there. Thanks for the heads up on this thread.

@mark lion
Are you creating the User’s account in WordPress BEFORE posting this data to the IPN processor?
In this case, that would be the ideal approach (please do that).

Posting your IPN data to s2Member AFTER the account is created should resolve the issue you’re having here. The log entry you posted, indicates that you are calling the IPN handler before the User’s account is created within WordPress, so it’s queuing things up in anticipation of on-site registration.

If the account already exists, you’ll get the results you desire.

Also, regarding the Proxy return URL. s2Member’s IPN handler exits script execution and returns the full URL in the output. So it’s not going to show up in the log file entries, but your script can collect this value the same way s2Member itself does. That is, you might do something like this…

$url_with_replacement_codes_filled_in = file_get_contents('123.456.789.001/...s2member_paypal_proxy=nmi&...&s2member_paypal_proxy_return_url=%2Fthank-you%2F');

Thanks for the heads up on this request for support.

@Nigel

Feeds within WordPress (i.e. those which are NOT inside the secure /s2member-files/ directory), are treated like any other feed. That is, the feed itself will always remain available to the public.

If your feed contains links to Posts/Pages, which you may have protected with s2Member; then upon clicking the links that lead to these protected areas of your site, non-Members will be asked to log into your web site with a Username/Password. Nothing special here, that’s how one would expect this to function.

Alternative View Restrictions

s2Member can also be configured to use Alternative View Restrictions, so that links in your feed are filtered down, to only those which are available to a particular User/Member, based on the current Member’s status on your site. For example, if your feed contains a link to a Page protected at Level #1, and the current Member is logged into their account with Level #1 access, the link would be visible. However, if they are NOT logged in, or they’re logged in as a Free Subscriber at Level #0, the link would not be visible to them.

See: Dashboard -› s2Member® -› Restriction Options -› Alternative View Protection

Protecting The Feed Itself (Integrating Remote Authorization)

This is an entirely different approach, and it requires that you make your own custom feed, placing the feed itself into the secure /s2member-files/ directory. Remote Authorization is NOT something that’s built into WordPress by default, it’s something that s2Member makes possible, and it’s only integrated with s2Member’s File Download functionality. Thus, in order to use Remote Authorization, you will need to make your feed a File Download, by placing it into your /s2member-files/ directory.

I understand from your previous post, that you’re attempting to integrate with Kindle. I think you’ll find that an integration with Kindle, is very similar to that of iTunes. However, I’ve not done an integration between s2Member and Kindle myself, so I can’t say with absolute certainty. I would start this project by first watching the video tutorial that we’ve made available for iTunes. Attached to this post for your reference.

Video » s2Member® File Downloads (Remote Auth/Podcasting)

See also: Dashboard -› s2Member® -› Download Options -› Remote Auth/Podcasting

Thanks for the follow-up.

@Lee Keels

I believe this issue was addressed in a subsequent patch file which
corrected references to $a, converting them into $attr references.

Please unzip and upload the attached patch file, allowing it to override your existing copy of:
/s2member-pro/includes/classes/gateways/ccbill/ccbill-button-in.inc.php

Patch (2nd attempt) / download link:
http://d1v41qemfjie0l.cloudfront.net/s2member/uploads/ccbill-button-in.inc_.php_1.zip

NOTE: Cristian’s response that both purchase attempts were for page access isn’t correct unless something is wrong. One was for a specific page/post (successful), the other was for a site membership/subscription (not successful).

Gotchya. Thanks.
The first one was for Specific Post/Page Access,
then a recurring Subscription failed after that, due to an error produced by ccBill, regarding an existing customer.

Absolutely confirmed. We do not use ANY CCBill member services. Everything is handled by WordPress/s2Member.
I am unable to find a setting for “do not collect usernames/passwords”…user management does show OFF.
UPDATE: Found the setting and it is turned off as well.

OK. Great. Thank you. May I assume that you’ve run your tests again after making these changes?
Problem still exists after those changes were made?

I think you’re right. I think this is a limitation is way ccBill looks at transactions. It sees everything as a Subscription, regardless of what is actually being purchased, and/or how it’s being billed. If you setup a second sub-account, you can probably work around this. However, the current release of s2Member Pro is not compatible with multiple sub-accounts. I’ve just added support for this into the Shortcode processor for s2Member, and I’m attaching that to this email for you. Hopefully this will help you out.

Please unzip and upload the attached patch file, allowing it to override your existing copy of:
/s2member-pro/includes/classes/gateways/ccbill/ccbill/ccbill-button-in.inc.php

Download patch file: http://d1v41qemfjie0l.cloudfront.net/s2member/uploads/ccbill-button-in.inc_.php_.zip

Once this patch file is in place, you’ll have the ability to add these new Shortcode attributes to your ccBill Payment Buttons generated by s2Member. Two new Shortcode attributes become possible. These include: sub_account="" and form="" (both optional).

So for instance, if you have an additional sub-account that you’d like to integrate with s2Member, you can modify your ccBill Button Shortcodes, and force s2Member to use a particular sub-account and a particular Dynamic Pricing Form associated specifically with that sub-account. Example below.

[s2Member-Pro-ccBill-Button level="1" .... sub_account="0001" form="3445cc" /]

This Shortcode is abbreviated for clarity in this regard.
Only to show these two new attributes that become possible.

Taking another look at this right now.
~ One moment please.

Thanks for the heads up on this thread…

‘s2member_log’ =>
array (
0 => ‘Storing last DataLink time: Thu Apr 5, 2012 5:00:06 pm UTC’,
1 => ‘No new Datalink IPNs at this time: Thu Apr 5, 2012 5:00:11 pm UTC’,
2 => ‘https://datalink.ccbill.com/data/main.cgi?startTime=20120404170006&endTime=20120405170006&transactionTypes=REBILL%2CEXPIRE%2CREFUND%2CCHARGEBACK&clientAccnum=xxxxxxxxx&clientSubacc=0004&username=s2member&password=xxxxxxxxxx’,
3 => ”,
),
)

In this log entry s2Member did not receive anything from ccBill. To clarify… s2Member will request REBILL, EXPIRE, REFUND, or CHARGEBACK details for the past 24 hours. In this request, it was asking for any of these that occurred starting on 2012-04-04 at 5pm until 2012-04-05 at 5pm (i.e. in the last 24 hours). ccBill responded back, saying none of these occurred in that time frame. Does that help any?

All of the post-processing routines for AliPay are ultimately handled by s2Member’s core PayPal IPN processor, as they get piped into the core PayPal processor after some initial handling that is specific to AliPay. So while there are no Hooks/Filters specifically for AliPay, there are MANY Hooks/Filters available within the PayPal core processor that can be used to grab this information.

Here is a quick example…
/wp-content/mu-plugins/s2-hacks.php

<?php
add_action('ws_plugin__s2member_during_paypal_notify_after_subscr_signup', 'my_info_grabber');
function my_info_grabber($vars = array())
	{
		if($vars&#91;'paypal'&#93;&#91;'subscr_gateway'&#93; === 'alipay')
			{
				print_r($vars); // An array of all transaction details.
			}
	}
?>

There are many other Hooks/Filters available through these files…
/s2member/includes/classes/paypal-notify-in…php

Thanks for the heads up on this thread.

@Lee Keels
Can you please verify that your ccBill account is configured NOT to handle Usernames/Passwords and/or User Mangaement? It sounds to me like your ccBill account is attempting to handle account access, and this might be the underlying reason for this error message during a second attempt to purchase something new.

Thanks for the heads up on this thread.

I noticed those links you posted were on two different domains.
Can you please describe for me the reason for that?

I suspect that’s the underlying cause. s2Member’s tracking codes work in conjunction with browser cookies that identify a paid customer immediately after a purchase. Mixing multiple domain names into a single installation may cause unexpected conflicts. WordPress will set cookies for the domain the site is configured to run on. If the domain the customer actually ends up on after checkout is different, it may fail to display tracking codes.

If you can please explain why the two links you posted are using different domains, that will help. I’ll assume you’re running a Multisite Network, is that correct?

Thanks for the heads up on this thread.
~ Handling this via email.

Thanks for the heads up on this thread.

While we’re always open to new ideas, I’m not currently aware of any clean/standard way to prevent this. As Cristian mentioned, Flash Cookies, or other forms of extremely advanced tracking might help to thwart this behavior. However, we can’t build things like that into s2Member and offer support for them. Those are things you’d need to implement in some custom fashion.

Hi Theresa. I’m following up with you via email.
~ Thanks for working with our Support Reps.