I have a Paypal business account, I use the host evohosting.co.uk
A user signs up, creates the recurring payment and the payment is instantly completed. However the user never gets an active subscription.
Here are some screenshots.
I remember seeing someone mentioned in a thread possibly on this forum that delivery options might cause this? Just a shot in the dark.
It is really important for my forum that I get this fixed so I would greatly appreciate someone with the right knowledge such as thew SMF devs to take a look. My forum can't function as a proper subscription forum until I find a solution to this. It is holding everything back.
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F6T6y7TR.png&hash=afe322ec1e227017d561d8cd9e8bde3e60d20689)
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FFddIejQ.png&hash=53114260cfbf7fbcc2399ad3031955ec8f57d341)
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FDVODTBb.png&hash=02f7c81ae204ccdbfa04050e067236fe5195469c)
Recurring payments do not work on some hosts. Are you getting Paid Subs errors in your error log? If not, usually means PayPal IPN is not reaching your forum. A few mods and some hosts block IPNs. PayPal support can confirm IPN is sent, and determine if it's being blocked.
If Paid Subs is logging errors, would need a look at your forum to see what's happening. If you can pm forum link and temporary admin access, should have time tonight to poke around.
For security reasons I don't want to give access to anyone. The industry im in means it is very difficult to trust anyone and I promised my members that security is a top priority.
I can't see any errors in the log for paid subscriptions.
That's an issue with your host blocking Paypal's IPN from reaching your site (or so it was always interpreted as such)
https://github.com/SimpleMachines/SMF2.1/issues/1167
If you search this forum for "subscriptions 2005" you will find a bunch of topics about this, always with the same conclusion (or none at all :P )
i'll contact my host now then thanks :)
I've checked my logs and saw no errors referring to the subscriptions URL. I turned IPN OFF some time ago in october. My host hasn't seen any paypal activity since then, however paypal doesnt seem to be blocked. Two users subbed this morning, the end date again is 2005.
Does anyone have any ideas?
It should also be noted, some members ahve come to me and asked why they got an email from paypal saying their subscription was cancelled, I also got an email with it being cancelled.
I've had some success....
I turned on IPN again and checked the IPN history after a fresh transaction.
It sent TWO messages with a status code of 200 which means they were received.
HOWEVER, there are two errors in my forum error log. I'll post as much detail as I can....
I think I asm closer to solving this now, I would REALLY appreciate it if someone could comment on this and save me anymore headaches.
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FGOlq9PH.png&hash=119d62b95ecfce13c2e9783859f5fd427cace0a4)
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FrLDDW2N.png&hash=c22a26f5f01524263fdafeaa81d7ad0014e9a8ec)
/me never even used subscriptions, sorry :(
The 2005 end date just means the subscription has not been activated, it should be listed as pending payment. subscriptions.php is receiving the IPN, but activation fails. The first error has a valid txn_type, second one doesn't - Subscriptions-Paypal.php does not recognize subscr_signup.
What is the subscr_id in the first error?
Have you tried disabling recurring payments?
It makes life easier if you set up a test subscription for $0.10 / 1 day.
Quote from: Krash on November 05, 2014, 12:09:22 PM
The 2005 end date just means the subscription has not been activated, it should be listed as pending payment. subscriptions.php is receiving the IPN, but activation fails. The first error has a valid txn_type, second one doesn't - Subscriptions-Paypal.php does not recognize subscr_signup.
What is the subscr_id in the first error?
Have you tried disabling recurring payments?
It makes life easier if you set up a test subscription for $0.10 / 1 day.
I-NABHVTLFELSM in both.
I need the subscription to reoccur every month. I can try testing without it but its useless to me without recurring payments every month until cancellation.
I'll setup a test subscription once i get my gf setup in paypal.
Quote from: Krash on November 05, 2014, 12:09:22 PM
Have you tried disabling recurring payments?
Like most SMF users, to get this to work im going to have to give in and try to find a workaround without recurring payments sine I hear this is supposed to work.
Do I simply create a new subscription and leave the "Allow user to auto-renew this subscription:" unticked?
What about "A subscription must be active for new members to join."?
What exactly does this "Active" option do? The wording makes it ambiguous.
Please stop with the hyperbole.
This situation is ***NOT*** "like most smf users"
Your situation is an exception that seems to happen for a very few folks and can not seem to be replicated by anyone who has coding and debugging skills. While we acknowledge that there seems to be an issue, we can not replicate the issue on any of our systems and therefore can not debug the issue and therefor can not "fix" it.
And, for the last time... "most smf users" do not seem to have any trouble with the subscriptions.
Quote from: Kindred on November 30, 2014, 08:57:40 AM
Please stop with the hyperbole.
This situation is ***NOT*** "like most smf users"
Your situation is an exception that seems to happen for a very few folks and can not seem to be replicated by anyone who has coding and debugging skills. While we acknowledge that there seems to be an issue, we can not replicate the issue on any of our systems and therefore can not debug the issue and therefor can not "fix" it.
And, for the last time... "most smf users" do not seem to have any trouble with the subscriptions.
The hyperbole is the idea that "everything is fine for most SMF users". Please stop being so dismissive of what is a buggy core feature.
I've spent months searching for the solution to this bug SMF has in the paid subscriptions and I've seen A LOT of threads across the net about it. I've seen countless people beg and plead for help and in just about every case their only solution was to mod the forum or not use the paid subscriptions system. And presuming that MOST SMF users don't need the paid subscriptions feature I would say that this bug presumably affects a high percentage of people who wanted to use this feature.
Either way, I've posted several threads and read so so many other threads and pages about this bug. I'm still here and just like the others, there is attempt at a proper solution.
If I had a choice i'd ditch this software and go elsewhere but I've already invested my time, my business and the security of my family in this buggy software so I can't leave it without some major work. I'm sorry if reading my threads has inconvenienced you though.
How can I fix it if I cannot ever reproduce it? It has worked perfectly for me for years :-/
Quote from: Arantor on November 30, 2014, 09:50:24 AM
How can I fix it if I cannot ever reproduce it? It has worked perfectly for me for years :-/
I'm sorry for the nasty thread. It seems to simply be that paypal is sending the subscriber type etc that the forum does not recognize. Its in the screenshot. Paypal has likely changed the way it works in that respect and i'm presuming(based on whats in front of me) that SMF isnt compatible with it anymore.
Your installation might work because your paypal account might not have been recently upgraded or may be in a state that still works with the old way. My paypal was cleanly upgraded to business account, I set it up in the way described in the SMF documentation. However paypal is sending callbacks(i think thats what it is) that SMF doesn't recognize.
Thats my best guess. I've called my hosting several times, I've called paypal several times, everything is getting through to the software.
Can anyone help me understand what this tickbox does?
"Active: A subscription must be active for new members to join. "
See, there is more to this story than you know. The single fiercest critic of this "broken" system is in fact a team member here, one of the few people who does have this problem, and despite the fact that I fixed some of the issues in 2.1 most of a year ago, and repeatedly asked him to test it... Never did. Because if it fixed it for him, I would have pushed changes into the 2.0 branch.
There are three cases I know of: invalid txn-types (fixed in 2.1, never known to cause end-2005 error), invalid currencies like AUD and CAD (fixed in 2.1, never known to cause end 2005 error) and people activating them manually and not setting the start date correctly... When the form ends in 2005. That, in fact, is the only place in SMF where 2005 is even used.
As for active, that means it is active and selectable for people buying new subscriptions. I think, but haven't checked, that this is so you can retire a subscription without kicking people out of what they have paid for.
Also, please note that we (simplemachines.org) have a premiere business account on PayPal and do not encounter this error.
As Arantor has said.. If we could ever reproduce the issue and have someone who knows smf coding investigate, we would probably be able to address it.
I am not being dismissive, I am trying to tell you that, while your issue may be real and I am sure it is important to you, MOST smf users do not encounter the issue, and that actually means most users who do use subscriptions. It works for them. Yes, there is a small subset of subscription folks who encounter this error, and because it involves money, they are very vocal about it... And the ones who have it work are not vocal, because they have nothing to complain about.
So, if you would be willing to share full access to your site with one of our developers, I can see if one of them would be willing to work with you... But without full access to a site one which this is occurring, we really can't do too much.
For me, this problem doesn't need fixing anymore as I won't need recurring subscriptions(so long as the tests without recurring work like most say they do). But I do want to help you fix this problem so others are not in the same position. I'm currently reforming my forum and i'm very very busy but i'll try and get time for you guys in the next few days if you want to try and discover what the problem is, even if it turns out to be my fault, at least it may help others.
When you get back to this, I would like to have a look if you can give me temporary admin access. The recurring payments problem seems to be host related, and may involve conflict between host and/or PayPal security protocols, which is something they won't readily discuss. I've never been able to reproduce the problem, and several forums I've looked at have not followed through with attempts to nail down the cause. We can't fix it unless we have sufficient access to an affected forum.
When is a good time for you guys?
Will be on for another hour or so today. Would like to set up a test member, test group, and test sub to work with, so it won't interfere with your existing subs.
Just looking over the two errors posted above, which are for the same subscription. They occur 1 second apart, both have the same ipn_track_id. IIRC, PayPal executes two transactions for a recurring subscription. The first sets up the recurring sub (at 06.32.11), the second processes the initial payment (at 06.32.12). It appears that two IPNs are sent, generating two errors. The first transaction has an invalid txn_type: subscr_signup, which is not recognized by Subscriptions-PayPal.php. The second has a valid txn_type: subscr_payment, which is recognized by Subscriptions-PayPal.php. Guessing that the first IPN borks the sub, preventing the second IPN from activating it.
Which is why I tried to fix this in 2.1 a year ago and asked for testing on it specifically in the hopes that if it did fix things, it would be backported to 2.0.
But why does it work on some forums and not others? If PayPal returns the same info to all forums, and txn_type: subscr_signup is invalid, it shouldn't work on any forum.
I don't know. But I tried to fix this a year ago and asked for people to test it and no-one was bothered.
Would have to be tested on a host account that's experiencing the problem. It's always worked fine for me. I've asked OP if he can copy his forum to a different directory with a scratch database, so I can work on it without disrupting his live forum.
Was it naive of me to assume you actually had the problem since you seem to know all about it?
I'll create a copy of my forum for you guys to poke around in tomorrow(its 9pm UK here. I can be...your guinea pig. (https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi.imgur.com%2Flysu2CG.jpg&hash=433cc288d42cc30f34e4760d24e56ab5fcf5c169)
Quote from: Arantor on November 30, 2014, 03:56:56 PM
Was it naive of me to assume you actually had the problem since you seem to know all about it?
I worked on several forums that had the problem, but they all bailed out before I could determine the cause. SMF has always worked fine on my host. If OP stays with us, we should have a test install to tinker with.
Ok, agentblackhat has set up a clone of his forum. Have asked for FTP access to the install. Arantor, if you want access, unblock my pm and I'll give you the info. Going offline now, but will work on it tonight (NY time).
Having a problem with PayPal, so while I wait on OP, been poking around in the code, and have a couple of vague ideas would like to toss out for comment.
- It appears that subscribing with recurring payment checked generates two separate transactions on PayPal, one to set up the subscription, the second to process the initial payment.
- Two IPNs are posted to subscriptions.php, one right after the other. The first IPN is for the subscription (txn_type: subscr_signup), which is not recognized by Paid Subs, the second IPN is for the payment (txn_type: subscr_payment), which is recognized by Paid Subs, but both generate errors, as posted above.
- The error handler that logs these errors is in subscriptions.php (function generateSubscriptionError($text)).
Here comes the vague part ...........
Paid Subs does not need the first IPN, there is no field in _log_subscribed for recurring payment. It doesn't know or care that the subscriber selected recurring payment, that's handled entirely by PayPal. If the first IPN is causing the subscription to fail, can it be ignored by subscriptions.php? Something like this -
if ($_POST['txn_type'] == 'subscr_signup')
exit();
As to why it works on some hosts and not others, could it be a timing thing? Possibly a php setting that delays execution, and causes the second IPN to conflict with the first one, because it's still being processed?
Unchecking the recurring option is working 100% on the live forum too.
Let me know if you need anything else.
Also I remember from other threads that sometimes not allowing guests can bork things( i do allow guests but i also have private section at the bottom which blocks them).
Apparently the paypal shipping options can cause a problem too as reported by others.
The subscription works if recurring payment is enabled in ACP, but unchecked by subscriber. It doesn't work if checked by subscriber (default, which should be changed). Can't get any further because your PayPal account is not giving me option to pay with PP, and would rather not use a credit card for test purposes. Can you fix that in your account settings?
Quote from: Krash on December 02, 2014, 01:08:35 PM
The subscription works if recurring payment is enabled in ACP, but unchecked by subscriber. It doesn't work if checked by subscriber (default, which should be changed). Can't get any further because your PayPal account is not giving me option to pay with PP, and would rather not use a credit card for test purposes. Can you fix that in your account settings?
I don't know how to fix it, most people are able to pay with their paypal balance i think. I'll refund any money you send me. Is there a specific option you want me to change in paypal?
I don't have a business account, so don't know what the options are. If you subscribe with recurring unchecked, it takes you to the usual PayPal payment page, which allows you to pay with PP. If you check recurring, you go to a completely different payment page, that wants to pay by echeck with option for debit/credit card, but no option to pay with PP. You'd have to look through your account settings.
Ok, I have recurring subscription failing on my 2.0.7 test install using your PayPal address. The basic problem seems to be the post data is different for recurring and non-recurring subs, and SMF is not handling it correctly. Will work on it tomorrow, it's late, I've exhausted my beer ration for the day, and still have crap to do.
If any of the coders are interested, here's the post data. I forced subscriptions.php to log the data for the successful sub, the two errors for recurring sub were logged normally.
Post data for successful subscription (not recurring) -
Unknown Paid Subscriptions transaction type.
transaction_subject:
payment_date: 20:36:58 Dec 03, 2014 PST
txn_type: web_accept
last_name: xxxxxxxxxxx
residence_country: US
item_name: Test Sub 1 Subscription
payment_gross: 0.10
mc_currency: USD
business: xxxxxxxxxxxxxxxxxxxxxxx
payment_type: instant
protection_eligibility: Ineligible
verify_sign: ALPIMq5nXjWxGhv0zNXuZTYtjFsBAgaMT5p6V7B5f3qVyGpBDv5bY0ZQ
payer_status: verified
tax: 0.00
payer_email: xxxxxxxxxxxxxxxxxxxxx
txn_id: 6KT695681M0135058
quantity: 1
receiver_email: xxxxxxxxxxxxxxxxxxxxx
first_name: xxxxxx
payer_id: VVVWDQLHWSRV8
receiver_id: NLVM6ERYVVBZQ
item_number: 6+69
handling_amount: 0.00
payment_status: Completed
payment_fee: 0.10
mc_fee: 0.10
shipping: 0.00
mc_gross: 0.10
custom:
charset: windows-1252
notify_version: 3.8
ipn_track_id: ccfcf38ec641a
-----------------------------------------------------------------------------------------------------------
Post data for failed subscription (recurring) -
Unknown Paid Subscriptions transaction type.
transaction_subject: Test Sub 1 Subscription
payment_date: 20:42:33 Dec 03, 2014 PST
txn_type: subscr_payment
subscr_id: I-TWCMNK9W8KSF
last_name: xxxxxxxxxx
residence_country: US
item_name: Test Sub 1 Subscription
payment_gross: 0.10
mc_currency: USD
business: xxxxxxxxxxxxxxxxxxxxxxxx
payment_type: instant
protection_eligibility: Ineligible
verify_sign: AWWNiATrbHYbRqBRArhpT1rFQ.z6ACbE5U31LWniPKWEj8JdJ9ivT5ld
payer_status: verified
payer_email: xxxxxxxxxxxxxxxxxx
txn_id: 9CW78077KJ6428818
receiver_email: xxxxxxxxxxxxxxxxxxx
first_name: xxxxxxxxxxx
payer_id: VVVWDQLHWSRV8
receiver_id: NLVM6ERYVVBZQ
item_number: 6+69
payment_status: Completed
payment_fee: 0.10
mc_fee: 0.10
mc_gross: 0.10
charset: windows-1252
notify_version: 3.8
ipn_track_id: e0da1f353f4ae
Unknown Paid Subscriptions transaction type.
txn_type: subscr_signup
subscr_id: I-TWCMNK9W8KSF
last_name: xxxxxxxxxx
residence_country: US
mc_currency: USD
item_name: Test Sub 1 Subscription
business: xxxxxxxxxxxxxxxxxxxxxxx
amount3: 0.10
recurring: 1
verify_sign: AXRnPJXrmeH15JsE0YpIKFD1E4cvACIXS5ARiEmK2g602fSyh3gifPfF
payer_status: verified
payer_email: xxxxxxxxxxxxxxxxxxxx
first_name: xxxxxxxxxx
receiver_email: xxxxxxxxxxxxxxxxxxxx
payer_id: VVVWDQLHWSRV8
reattempt: 1
item_number: 6+69
subscr_date: 20:42:31 Dec 03, 2014 PST
charset: windows-1252
notify_version: 3.8
period3: 1 Y
mc_amount3: 0.10
ipn_track_id: e0da1f353f4ae
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fwww.thekrashsite.com%2Fpics%2Fbor.gif&hash=cba0817857a10dc1cd975d2b49a33ba2fc822800)
As I've been saying for months, I added subscr_payment to 2.1's handler. I didn't add subscr_signup since the API wasn't clear about when it should be sent.
I did even add subscr_eot and subscr_cancel in 2.1... meaning that the only one left is subscr_signup and there's nothing that actually needs doing with it anyway except not throwing an error if received.
Don't know why subscr_signup breaks the sub. It hits subscriptions.php first, followed by subscr_payment 1-2 seconds later. Looks like the code should dump the first and process the second, but both fail. Will kick it around tomorrow.
Part of the problem seems to be here -
ManagePaid.php
// Check this is definitely a valid gateway!
$fp = fopen($sourcedir . '/' . $file, 'rb');
$header = fread($fp, 4096);
fclose($fp);
if (strpos($header, '// SMF Payment Gateway: ' . strtolower($matches[1])) !== false)
{
loadClassFile($file);
$gateways[] = array(
'filename' => $file,
'code' => strtolower($matches[1]),
// Don't need anything snazier than this yet.
'valid_version' => class_exists(strtolower($matches[1]) . '_payment') && class_exists(strtolower($matches[1]) . '_display'),
'payment_class' => strtolower($matches[1]) . '_payment',
'display_class' => strtolower($matches[1]) . '_display',
);
}
$gateway['code'] comes up empty, which causes the process to error out when it gets here -
subscriptions.php
// We need to see whether we can find the correct payment gateway,
// we'll going to go through all our gateway scripts and find out
// if they are happy with what we have.
$txnType = '';
$gatewayHandles = loadPaymentGateways();
foreach ($gatewayHandles as $gateway)
{
$gatewayClass = new $gateway['payment_class']();
if ($gatewayClass->isValid())
{
$txnType = $gateway['code'];
break;
}
}
if (empty($txnType))
generateSubscriptionError($txt['paid_unknown_transaction_type']);
Also looks like you have to add this here -
Subscriptions-PayPal.php
/// Is this a normal payment?
public function isPayment()
{
if ($_POST['payment_status'] == 'Completed' && $_POST['txn_type'] == 'web_accept')
return true;
else if ($_POST['payment_status'] == 'Completed' && $_POST['txn_type'] == 'subscr_payment')
return true;
else
return false;
}
Tried a few things, but can't get it to go. No activation, no pending payment, just the two errors. (https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fwww.thekrashsite.com%2Fpics%2Fhairpull1.gif&hash=d1684c7b73ef4c7cc773994cfce0795f18f1c1d9)
If $gateway['code'] is coming up empty, I'd have to ask if there is an extra file in the folder that shouldn't be there for some reason.
There is more code in 2.1 than just those changes, though in terms of processing subscr_payment... you realise I keep bringing this up for a reason, right?
Quote from: Arantor on December 04, 2014, 03:32:33 PM
If $gateway['code'] is coming up empty, I'd have to ask if there is an extra file in the folder that shouldn't be there for some reason.
Are you referring to
/Sources? My test forum is pretty much a scratch install. OP's forum has around 20 mods installed, so there are additional source files. He also has an
.htaccess in forum root containing pretty urls mod. The two installs are quite different, problem is exactly the same.
Quote
in terms of processing subscr_payment... you realise I keep bringing this up for a reason, right?
Can't figure why subscr_payment is not working, with the change to
Subscriptions-PayPal.php, but as far as I can see, the 'Unknown Paid Subscriptions transaction type' error only occurs if
$txnType is empty, and that comes from
loadPaymentGateways() in
ManagePaid.php. If the entire process were in one file, might be able to grasp it, but as it is, makes my old brain feel like a pingpong ball.
The entire reason I keep bringing this stuff up is that I made more changes to the entire workflow in 2.1 than simply the bit you seem to think I might have done. There's entire branches of process flow added for conditional testing that have been missed out here.
Do a comparison of both subscriptions.php and the PayPal handler against 2.0's files and see how different they are.
For support purposes I need a fix for 2.0, those are the forums I'm trying to help. Now that I've duplicated the problem on a test install, I have the opportunity to work on it without limitations. If recurring payments ever worked on any 2.0 forum (I'm fairly certain it did), it doesn't work now, possibly due to changes in 2.0 updates or in PayPal API. The basic problem doesn't seem that difficult, but the payment verification and subscription activation process is spread out over at least three files, and I'm not understanding it well enough to fix it.
And again, I will reiterate that if people tested all the changes in 2.1 as a group, the relevant changes could be isolated and backported. Doing so just in the *hopes* of a fix is a scary amount of work.
and I will note, Krash... recurring payments *DO* work on many system - including this site.
What I'd suggest now --- is install 2.1 on the system and see if it processes differently
Does recurring payments work here?
Quote from: Kindred on December 05, 2014, 02:02:08 PM
and I will note, Krash... recurring payments *DO* work on many system - including this site.
Um, yes?
Ooops, not seeing well tonight. Just d/led 2.1 beta, will replace alpha and give it a try.
Can't set up a $0.10 test sub, only allows integers for cost. Too rich for my budget. Theme's a bit hard to look at, very cluttered.
Back to 2.0.
And you couldn't have looked at this any time in the preceding... 6 months? As in before this got to public beta?
Don't have a PP business account, so can only test recurring payments when I have access to someone else's business account, which is rarely.
Just for the halibut, uploaded subscriptions.php, ManagePaid.php, and Subscriptions-PayPal.php from 2.1 to my 2.0.9 test install, and I get the same two errors. Non-recurring doesn't work either, get one error.
Ok, here's a puzzle.
subscriptions.php does this -
// We need to see whether we can find the correct payment gateway,
// we'll going to go through all our gateway scripts and find out
// if they are happy with what we have.
$txnType = '';
$gatewayHandles = loadPaymentGateways();
foreach ($gatewayHandles as $gateway)
{
$gatewayClass = new $gateway['payment_class']();
if ($gatewayClass->isValid())
{
$txnType = $gateway['code'];
break;
}
}
if (empty($txnType))
generateSubscriptionError($txt['paid_unknown_transaction_type']);
loadPaymentGateways() is in ManagePaid.php -
// Load all the payment gateways.
function loadPaymentGateways()
{
global $sourcedir;
$gateways = array();
if ($dh = opendir($sourcedir))
{
while (($file = readdir($dh)) !== false)
{
if (is_file($sourcedir .'/'. $file) &&
preg_match('~^Subscriptions-([A-Za-z\d]+)\.php$~', $file, $matches))
{
// Check this is definitely a valid gateway!
$fp = fopen($sourcedir . '/' . $file, 'rb');
$header = fread($fp, 4096);
fclose($fp);
if (strpos($header, '// SMF Payment Gateway: ' .
strtolower($matches[1])) !== false)
{
loadClassFile($file);
$gateways[] = array(
'filename' => $file,
'code' => strtolower($matches[1]),
// Don't need anything snazier than this yet.
'valid_version' =>
class_exists(strtolower($matches[1]) . '_payment') && class_exists(strtolower($matches[1]) . '_display'),
'payment_class' => strtolower($matches[1])
. '_payment',
'display_class' => strtolower($matches[1]) .
'_display',
);
}
}
}
}
closedir($dh);
return $gateways;
}
When I dump the $gateways[] array I get this -
array(1) { [0]=> array(5) { ["filename"]=> string(24) "Subscriptions-PayPal.php" ["code"]=> string(6) "paypal"
["valid_version"]=> bool(true) ["payment_class"]=> string(14) "paypal_payment" ["display_class"]=>
string(14) "paypal_display" } }
$txnType = $gateway['code']; should make $txnType = 'paypal', but instead it's empty and subscriptions.php errors out.
If I assign values from the array to $txnType and $gatewayClass -
$txnType = '';
$gatewayHandles = loadPaymentGateways();
foreach ($gatewayHandles as $gateway)
{
// $gatewayClass = new $gateway['payment_class']();
$gatewayClass = 'paypal_payment';
if ($gatewayClass->isValid())
{
$txnType = $gateway['code'];
break;
}
}
$txnType = 'paypal';
if (empty($txnType))
generateSubscriptionError($txt['paid_unknown_transaction_type']);
.... subscription is unsuccessful but there are no errors. It appears that $gatewayHandles is empty, so the loadPaymentGateways() function does not work in subscriptions.php, but does work in ManagePaid.php.
Have no idea what this means. (https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fwww.thekrashsite.com%2Fpics%2Fidk.gif&hash=9ac7acf13f4cfaa1b58390444a38dea11e5473d2)
Is it possible to use a local <form> to post IPN data to subscriptions.php for test purposes?
Krash, keep a running total of all the money you're sending me, I don't want to have to refund each one of those payments, there are loads! I can refund in one payment then.
The thought occurred, late last night, that perhaps Old Krash has been flogging the wrong end of the horse.
Mr. Obvious asks: When recurring payment fails, where's the pending subscription?
Hint: If
subscriptions.php receives an IPN and there is no pending subscription, it will error out exactly as it's doing here.
Quote from: agentblackhat on December 08, 2014, 05:45:27 AM
Krash, keep a running total of all the money you're sending me, I don't want to have to refund each one of those payments, there are loads! I can refund in one payment then.
Don't worry about that for now, it'll take me a couple of hours to straighten out my PapPal account if I'm ever done with this.
Ok, mopes, Old Krash may be old and slow, but sometimes gets there in the end. Here's the problem -
The PayPal email address in Paid Subscriptions is set for
[email protected]. When you subscribe and
uncheck recurring payments, the post data returns
business: [email protected].
Subscriptions-PayPal.php compares
$_POST['business'] to the email address setting, here -
// This function returns true/false for whether this gateway thinks the data is intended for it.
public function isValid()
{
global $modSettings;
// Has the user set up an email address?
if (empty($modSettings['paypal_email']))
return false;
// Check the correct transaction types are even here.
if ((!isset($_POST['txn_type']) && !isset($_POST['payment_status'])) || (!isset($_POST['business']) && !isset($_POST['receiver_email'])))
return false;
/// Correct email address?
if (!isset($_POST['business']))
$_POST['business'] = $_POST['receiver_email'];
if ($modSettings['paypal_email'] != $_POST['business'] && (empty($modSettings['paypal_additional_emails']) || !in_array($_POST['business'], explode(',', $modSettings['paypal_additional_emails']))))
return false;
return true;
}
If they match,
function isValid() returns 'true' to
subscriptions.php, here -
$txnType = '';
$gatewayHandles = loadPaymentGateways();
foreach ($gatewayHandles as $gateway)
{
$gatewayClass = new $gateway['payment_class']();
if ($gatewayClass->isValid())
{
$txnType = $gateway['code'];
break;
}
}
if (empty($txnType))
generateSubscriptionError($txt['paid_unknown_transaction_type']);
... and the subscription is processed correctly.
When you subscribe and
check recurring payments (it's checked by default), the post data returns
business: [email protected]. For reasons unknown, PayPal forwards
[email protected] to a second account,
[email protected]. The payment interface is completely different, so I'm guessing that
[email protected] is a personal account, and
[email protected] is the business account required for recurring payments. Apparently PayPal uses the personal account for nonrecurring subscriptions, but forwards to the business account for recurring. When this occurs,
$_POST['business'] does not match the PayPal email setting,
isValid() returns 'false', and
$txnType is empty, causing
subscriptions.php to error out, and subscription fails.
The solution is to use the business account as the PayPal email address in Paid Subscription settings. Tried it, and it works for both recurring and non-recurring subs.
This would explain why it works perfectly for most sites - the ones that actually have a business acount and use it correctly.
Don't believe the site owners are aware this is happening, probably to do with the way PayPal sets up the business accounts, or does upgrades from personal to business. Their website is just awful, and the business payment interface is much more confusing than the personal ui. This is not an isolated case, it's affected a number of forums.
Thanks to agentblackhat for your patience, and use of your PP account.
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fwww.thekrashsite.com%2Fpics%2Fbor.gif&hash=cba0817857a10dc1cd975d2b49a33ba2fc822800)
Great! Nice investigation, Krash.
Although it's not SMF's fault, it's great that we know why it happens.
The
[email protected] email account is my main email account.
As far as I know, you can only own one paypal account, so when a business is setup, people often add another email address for each business. So that it appears as a business name rather than ones own email account.
All my forum/marketing business side of things run through
[email protected], other sites I have use their own unique paypal email too.
Paypal allows you to easily add new email addresses to do business with. This is very normal.
So what does this all mean now? What do I need to do to get this working?
Quote from: margarett on December 09, 2014, 09:07:37 AM
Great! Nice investigation, Krash.
Although it's not SMF's fault, it's great that we know why it happens.
Quote from: Arantor on December 08, 2014, 11:58:50 PM
This would explain why it works perfectly for most sites - the ones that actually have a business acount and use it correctly.
I have a business account, I use it correctly.
This has been an incompatibility of SMF with a very normal use of a business paypal account. If you log into paypal and view your account you'll see the ability to add several new paypal addresses with which you can send or receive money from. This functionality has been available and widely used for many many years, possibly over a decade.
I have been sending and receiving money for many years now using these email addresses on many systems. Only SMF has caused me these problems. Please do not try pointing the blame away from something which was a very clear incompatibility of SMF with the full features of paypal. Having worked in Web development agencies for 9 years I have never had such problems even when working with our developers on our own cart and payment systems. Sorry if i'm being a bit of a dick here but I really don't want this brushed off as "not our fault". I appreciate the work done here by Krash to help you with your software, Krash has been great. But please don't spin this in such a manner as to patronize and brush it off as my fault. Your system was incompatible with a very old and commonly used feature of Paypal.
Ok so back onto the problem at hand.
To help you understand the situation better.
These are not separate accounts. In Paypal you can setup a ton of email addresses in order to send and receive payments, all connected to the same account. One of these addresses has to be a primary which can be selected.
My primary is my personal,
[email protected], directly beneath it are several others email addresses for business use which are ALL part of the same account. These addresses are all a part of the same paypal business account.
There can only be one primary account. I've now changed it to
[email protected]If krash can try to setup a subscription again we may see it working successfully.
However, even if this does work, the problem is not fixed. If in the future I setup more forum for various businesses, I can't have them all using one paypal email address. This is just a workaround of the flaw in SMF.
If you want your software to work as a business tool, you need to try and find a way to make it compatible with business owners/users. I should be able to use my paypal account correctly and it work with SMF. So far, only trying to work around and use my business paypal account incorrectly will result in fixing the problem.
The PayPal IPN returns three email addresses, payer_email:, which belongs to the subscribing member, receiver_email:, which is your primary address for the business account, and business:, which is your PP address for forum transactions, and is the Paid Subs PP email setting.
When a member selects nonrecurring subscription, the email setting links to the PP personal payment interface, and the IPN returns the email setting as business:, and your primary address as receiver_email. For validation/security purposes, SMF compares business: with the email setting, they must match for the transaction to be processed.
When a member selects recurring subscription, the email setting is redirected to the PP business payment interface, and IPN returns your primary address for both business: and receiver_email. SMF does not have this address, so the validation fails.
Offhand, I can think of two ways to fix it. A simple edit to isValid() function can remove the validation, but this may create a security vulnerability. Or, an additional field can be added to allow two email addresses in Paid Subs settings. I seem to recall seeing a $mod_settings variable in the code that appeared to be for multiple email addresses, but there is no such feature. Would have to pick through the code to find it again. In any event, would require some coding, but it's doable, and would make Paid Subs more consistent with PayPal's account setup.
As it is, you must use your primary PP email address in Paid Subs settings for recurring payments to work.
Quote from: Krash on December 12, 2014, 01:29:11 PM
The PayPal IPN returns three email addresses, payer_email:, which belongs to the subscribing member, receiver_email:, which is your primary address for the business account, and business:, which is your PP address for forum transactions, and is the Paid Subs PP email setting.
When a member selects nonrecurring subscription, the email setting links to the PP personal payment interface, and the IPN returns the email setting as business:, and your primary address as receiver_email. For validation/security purposes, SMF compares business: with the email setting, they must match for the transaction to be processed.
When a member selects recurring subscription, the email setting is redirected to the PP business payment interface, and IPN returns your primary address for both business: and receiver_email. SMF does not have this address, so the validation fails.
Offhand, I can think of two ways to fix it. A simple edit to isValid() function can remove the validation, but this may create a security vulnerability. Or, an additional field can be added to allow two email addresses in Paid Subs settings. I seem to recall seeing a $mod_settings variable in the code that appeared to be for multiple email addresses, but there is no such feature. Would have to pick through the code to find it again. In any event, would require some coding, but it's doable, and would make Paid Subs more consistent with PayPal's account setup.
As it is, you must use your primary PP email address in Paid Subs settings for recurring payments to work.
Krash did you try doing another sub? i changed the primary to
[email protected], i am wondering if it currently is working now.
Yes, it works now. As long as the primary email address is same as email setting in Paid Subs, SMF will validate the IPN. Try it in your clone install.
I'm inclined to agree with Bruno, this is really a PayPal problem. Can't see any reason why they should return the primary address twice. Would make more sense if business: is the originating address (as set in the business site), and receiver_email: is the primary. But no one here is going to convince PayPal to change the way they do things, and fixing it in SMF doesn't look like a big deal.
Hopefully this gets some attention in the end, if I want to keep using SMF for future projects then the only viable option is to pay for some of the modded payments systems out there who seem to already have all this fixed and working.
It actually is working, SMF is doing what it's supposed to do to validate IPN, it's just that it's not entirely on the same page as PayPal API. Will take a look at the coding when I have some time. May not be too difficult to make it do what you want.
Why is it a problem to use your primary email address in Paid Subs?
Quote from: Krash on December 13, 2014, 11:42:46 PM
It actually is working, SMF is doing what it's supposed to do to validate IPN, it's just that it's not entirely on the same page as PayPal API. Will take a look at the coding when I have some time. May not be too difficult to make it do what you want.
Why is it a problem to use your primary email address in Paid Subs?
It is not consistent with the brand to use my name and birth year @hotmail.com for taking payments. It should be something like
[email protected]. Also I want to keep my personal email and the company separate.
It appears that at some point in the development process this problem was anticipated. If you look at the isValid() function, there's a $modSettings['paypal_additional_emails'] variable that's checked in the validation process -
// Correct email address?
if (!isset($_POST['business']))
$_POST['business'] = $_POST['receiver_email'];
if ($modSettings['paypal_email'] != $_POST['business'] && (empty($modSettings['paypal_additional_emails']) || !in_array($_POST['business'], explode(',', $modSettings['paypal_additional_emails']))))
return false;
return true;
But the setting doesn't exist. Someone apparently knew about this early on, but it was lost along the way and never made it to 2.0. The forum sends the correct info to PayPal here -
$return_data['hidden']['business'] = $modSettings['paypal_email'];
PayPal takes you to the personal account payment interface and posts it back correctly when payment is nonrecurring. But when recurring payment is checked, it redirects to the business payment interface, and the post data is changed to a different address (primary) that the forum doesn't have, and validation fails. In effect, your PayPal account acts like two separate accounts, business and personal, that are linked. This may be because it was originally a personal account that was upgraded to business, but really don't know.
May be able to come up with a workaround, but to fix it properly is fairly involved. Paid Subs code is broken up into lots of little bits spread over different files, and there are parts of it I haven't yet found.
QuoteBut the setting doesn't exist. Someone apparently knew about this early on, but it was lost along the way and never made it to 2.0.
Just because there isn't a UI item for it does not mean it doesn't exist. There are plenty of such settings where UI items don't exist but the code supports them - such as integration hooks for example.
If the correct info is sent to PayPal, and it's failing on return back because of a mismatch, put the relevant value into the smf_settings table, because if the only problem is a missing UI item, that's easy to fix. But I want to be clear that that is the problem - and I suspect it isn't being exposed as a UI item to limit the amount of confusion people will have with it.
If there's no way to add the additional email address in ACP, then it's basically not useable. This is not an uncommon problem, and there should be a better way to fix it then having admins edit the database, for obvious reasons. Was going to try to add the input field to Paid Subs settings,. but that's one of the bits I haven't found.
Will try editing the settings table on my test install when I get a chance.
You make it sound *so* dramatic.
Subscriptions-PayPal.php
$setting_data = array(
array('text', 'paypal_email', 'subtext' => $txt['paypal_email_desc']),
); $setting_data = array(
array('text', 'paypal_email', 'subtext' => $txt['paypal_email_desc']),
array('text', 'paypal_additional_emails', 'subtext' => $txt['paypal_additional_emails_desc']),
);Add this to ManagePaid.language.php
$txt['paypal_additional_emails'] = 'Additional emails to recognise from PayPal';
$txt['paypal_additional_emails_desc'] = 'They should be separated by commas, e.g. [email protected],[email protected]';
Thanks, will tinker with it tonight.
Ok, Matt, Arantor's solution solves the problem. You can input the email addresses either way and subscriptions will work, so you can reset your primary the way it was. If you don't want to edit the code yourself, I've attached the modded files -
/Sources/Subscriptions-PayPal.php
/Themes/default/languages/ManagePaid.english.php
The edits are at triple slash ///. Backup the originals (just in case).
I have not tested yet but thankyou very very much for the recent support with this problem.
I hope this thread will be great for other users with the same problem in the future should they use the search function.
I'll continue to stick with SMF and help out where I can if I find other issues with the forum. Well done :)
Let us know how the fix works for you.
I have used 3 different hosts and its always been the same - failed subscription finished 2005. I have only ever used single (none recurring) payments.
Last I heard it was accepted as a bug and Arantor was working on it. I would just like to say thanks fro that and the work put in.
What I wanted to know was if I could use the 2.1 subscriptions files on SMF 2.0.9. Would that work?
Andy
I just saw the edits above - I will try those.
No. It most definitely will not work.
Also... i am not aware of sny currently open issues with subscriptions... so, either your issue was patched and fixed or it was never actually accepted.
In order to know if Krash's fix will work for you, do you use a business account at PayPal?
As far as I know it is just an ordinary account. There was a name change/upgrade for it a couple of years ago.
Account Type: Premier ; Verified
Merchant account ID....
Whether merchant account is the same as business account I do not know?
Me neither :P
Yes, I believe that it is the same
Seem to recall we tried to fix this for you quite a while ago. Two things to know about PayPal email address in Paid Subs settings. It is case sensitive, and must be exactly the same as in your PP account. And, as per this thread, If you're using a secondary email address in a business account, it won't work without the posted fix.
If you can pm your url and give me admin access, will have a look tonight.
Yes Krash you did have a look a couple of years ago. You thought it was ok then.
Ok, the paypal email address set in SMF subscriptions is the same as the primary email address on the paypal website in email settings - exactly. It is an email address from the domain used for SMF.
PaypaI sends payment notifications back to this and it is forwarded to my gmail account. I get these ok.
In paypal settings there are also 2 other personal email addresses.
'Email for Correspondence' in SMF subscriptions is different (gmail one).
My personal email in profile (admin) is the gmail one - different.
SMF Webmaster email is different in the AC panel.
QuoteAlso... i am not aware of sny currently open issues with subscriptions... so, either your issue was patched and fixed or it was never actually accepted.
Kindred, you will find the subscriptions 2005 bug on SMF github. Its been there quite a while.
https://github.com/SimpleMachines/SMF2.1/issues/1167
Ok, it's working now. Currency code in Settings must be lower case, jpy not JPY, because of this -
// Verify the currency!
if (strtolower($_POST['mc_currency']) != $modSettings['paid_currency_code'])
exit;
The 2005 end date is not a bug, it's the default end date for an unactivated subscription.
Which suggests that the error was userside, not code side and thatbthe github issue can be closed with documentation that the currency code should be lower case (or possibly, forced to lower case in our code)
That's only one case. We were seeing other instances of this error without that being a case.
It's all so nebulus and hard to track down. And has been an issue for longer than that GH issue.
Any error that causes subscription to fail leaves the 2005 end date. The error handling in Paid Subs needs work, don't know if it's improved in 2.1. Posted a couple of suggestions on Dev board.
I didn't do anything to the reporting, I fixed up some of the cases that would cause it to fail. But without anyone testing to see if it helped, I gave up caring about it.
Krash,
Thanks for taking a look and spending so much time.
I think when I checked the currency code on the web it was capitalised. Not sure if that was at paypal or other site (PHP), maybe both.
Looking up now, Wikipedia shows it capitalised for ISO 4217. Also PHP websites.
Even the drop down box for currency shows them capitalized in SMF subscriptions. Its worth putting a line of documentation/help topic there to remind people to put it in lower case.
Is there no way of checking these codes using PHP on saving the subscription?
Yes, this, and a similar problem involving email addresses, are easily fixed, just a question of the devs getting around to it. I've brought it to their attention, so hopefully it'll be taken care of.
Let us know if you have any further problems.
I can confirm it is working :) (JPY > jpy)
Must be 3 years of manually setting dates and emailing notifications 600 times.
Don't think that was your original problem, but don't really remember. Will try to get this fixed in 2.1.
Edit: Just checked the code, that's been fixed in 2.1 -
// Verify the currency!
if (strtolower($_POST['mc_currency']) !== strtolower($modSettings['paid_currency_code']))
exit;
The IPN post data and Paid Subs setting are both converted to lowercase for comparison.
QuoteDon't think that was your original problem, but don't really remember.
I think it was the same. Nothing changed since I started using SMF except moving hosting companies but that didnt help. The only thing changed is the currency code problem.