Another paid subscriptions bug?

[Sir Osis of Liver]

Per this thread, looks like there's a problem involving recurring payments.  If recurring payments are enabled, and member checks the option when ordering (it's checked by default), subscription fails because SMF does not recognize the transaction code sent in the IPN.  Did some test subs on a scratch 2.0.2 forum, and non-recurring sub work fine, but recurring payment does not.  Payment is completed but errors are generated and subscription fails.

This is what I have so far - 

In /Sources/Subscriptions-PayPal.php, it appears that the following txn_types are recognized:

  Refunded
  reversal
  subscr_payment
  web_accept

The following, which appear in the error log, are not:

  subscr_cancel
  subscr_eot
  subscr_signup


When I do a test subscription with recurring payment, two 'Unknown transaction type' errors are generated. PayPal executes two transactions to set up the subscription:

1 - Recurring Payment created - txn_type = subscr_payment
   
2 - Recurring Payment completed - txn_type = subscr_signup

The second transaction debits the member's account.  Don't know why the first error is generated, as subscr_payment is a recognized txn_type, but subscr_signup is not, and subscription fails.  If the recurring sub is cancelled by the forum or the member (in their respective PayPal accounts), an IPN is posted to the forum with txn_type = subscr_cancel, which is also not recognized by SMF, and throws the same error.

Unless it's somewhere else in the code, SMF doesn't know what to do with subscr_signup, so there's no way a recurring subscription can work.

[feline]

Interesting .. on our system (2.0.2) subsription works without any problem .. also recurring payments

[Sir Osis of Liver]

Where is subscr_signup in the code?  Can't find it, and if it's not there, recurring payments shouldn't work.  Can't test it on my installs because I have a personal PayPal account, and recurring payments only works on business accounts.

[feline]

I don't known which code is received .. I see only the result.
And I have a normal account on paypal .. no business

[Wazza]

Interesting .. on our system (2.0.2) subsription works without any problem .. also recurring payments

Could this be because your forum was "updated" to 2.0.2 and not a "New" install of 2.0.2?

This bug exists in a "New" install of 2.0.2 not recognizing the return_url sent like: "subscr_eot"  As Krash says it seems it's not there? so this is why I ask is yours working in a New install? as maybe this is were the difference may be?


,,,The PayPal account needs to be upgraded to premium or business to except a request from the forum for a recurring payment. This part is not were we have concern with. It is how 2.0.2 handles the return_url sent like: "subscr_eot" as Krash states in the first post.   

[feline]

Interesting .. on our system (2.0.2) subsription works without any problem .. also recurring payments

Could this be because your forum was "updated" to 2.0.2 and not a "New" install of 2.0.2?

I make anytime updates .. 2.0 -> 2.0.1 -> 2.0.2

edit:
just compare files from my system and a fresh 2.0.2 install archive ... no difference

[Sir Osis of Liver]

subscriptions.php is the form handler - it receives and processes the IPN, and calls functions from /Sources/Subscriptions-Paypal.php, which includes the PayPal gateway code.  It looks for specific txn_type codes which are hardcoded in the script.  As far as I can tell, they aren't in the database and don't occur anywhere else.  That being the case, if txn_type is subscr_signup, recurring subscription should fail because it's not in the code, which is what's happening on Wazza's forum.  It's a clean 2.0.2 install, new database, no mods or custom edits, basically nothing on it.

[Wazza]

I did a down load of the older versions of SMF over the weekend to see if I could see the difference too, but couldn't find it? So now really unsure how recurring payments ever worked? or how anyone using notify_url via PayPal has it working?

We have set up a brand new install of 2.0.2 to test and find why it is not working?

As right now in a brand new install this bug presents a major risk to new users, being able to create and receive a recurring payment from a member as the money part works. But then your forum will not recognize the notify_url. Outcome their member will never get what they paid for. 

[Sir Osis of Liver]

Just tried a test subscription on my 2.0 forum using your PayPal address, and got the same result.  Subscription failed, two unknown transaction type errors for subscr_payment and subscr_signup.

[Wazza]

Just refunded, thank you for testing. Surprised we are the first to find this error?

[Sir Osis of Liver]

I'm surprised there's no interest in this problem.  If I'm reading the code correctly, recurring subs shouldn't work for anyone, and never could have in 2.0.x.

This hack may fix it (haven't tried it) -

In /Sources/Subscriptions-Paypal.php find this:

Code Select Expand



// Is this a subscription?
public function isSubscription()
{
if (substr($_POST['txn_type'], 0, 14) == 'subscr_payment')
return true;
else
return false;
}

// Is this a normal payment?
public function isPayment()
{
if ($_POST['payment_status'] == 'Completed' && $_POST['txn_type'] == 'web_accept')
return true;
else
return false;
}

// How much was paid?
public function getCost()
{
return $_POST['tax'] + $_POST['mc_gross'];
}

// exit.
public function close()
{
global $smcFunc, $subscription_id;

// If it's a subscription record the reference.
if ($_POST['txn_type'] == 'subscr_payment' && !empty($_POST['subscr_id']))



Change to this:

Code Select Expand



// Is this a subscription?
public function isSubscription()
{
if (substr($_POST['txn_type'], 0, 14) == 'subscr_payment' || substr($_POST['txn_type'], 0, 13) == 'subscr_signup')
return true;
else
return false;
}

// Is this a normal payment?
public function isPayment()
{
if ($_POST['payment_status'] == 'Completed' && $_POST['txn_type'] == 'web_accept')
return true;
else
return false;
}

// How much was paid?
public function getCost()
{
return $_POST['tax'] + $_POST['mc_gross'];
}

// exit.
public function close()
{
global $smcFunc, $subscription_id;

// If it's a subscription record the reference.
if (($_POST['txn_type'] == 'subscr_payment' || $_POST['txn_type'] == 'subscr_signup') && !empty($_POST['subscr_id']))



There's nothing in the database that flags a recurring sub, it's treated the same as a one-time subscription, so this workaround shouldn't affect anything in the forum (if it works).

[Arantor]

Well, it definitely has worked for me in the past, so I'm intrigued as to why it hasn't for you.

[emanuele]

Looking at this:
http://www.paypalobjects.com/en_US/ebook/subscriptions/Appx-ipn_subscription_variables.html
and this:
http://stackoverflow.com/questions/1061683/subscriptions-with-paypal-ipn

If I understand well, signup shouldn't be "so" important, payment should be the answer that says if the payment is valid or not (that's just a guess BTW).

To debug paypal issues I need to be in a very good mood (it has to do with money and I don't want to do something wrong with someone else's money) so...later.

[Arantor]

Note that you can use the sandbox setting so that you don't actually use actual money.

[emanuele]

Yep, I know, the comment was intended more in the sense that if I do anything wrong here that goes into SMF it means I'm playing with someone else's money.
So (since I'm known to have...ehm...a lot of imagination in create bugs ), I prefer to take my time and play with paypal when I have plenty of time and a good mood.

[Arantor]

That's the joy of the sandbox mode, you can test it and test it and test it over and once you're satisfied it can be committed

[Wazza]

Hi Krash,

Injected the code (don't worry I have a back up  ) into the test 2.0.2 we created.

Came up with this error.

Fatal error: Cannot redeclare paypal_payment::isSubscription() in /home/wazza/public_html/ATown/Sources/Subscriptions-PayPal.php on line 233


...I should point out to the others I agree totally with the extra comments about getting this wrong when its someones money we are working with. However currently left the way it is, this gets it wrong 

"Recurring" whilst for me would be great to be working as optioned in SMF, I should say this is not imperative to me that this must work. I looked at this more as a time saver for members not needing to return and renew each month. I can live with out this, if this cannot be made functional. However for me I'm now more concerned for the future ramifications left this way in SMF if others make the same mistake?

I believe we ether need to fix this option or have this option removed   

Wazza

[Sir Osis of Liver]

Well, it definitely has worked for me in the past, so I'm intrigued as to why it hasn't for you.

Where is the code that recognizes subscr_signup?  That's what has me stumped.

To debug paypal issues I need to be in a very good mood (it has to do with money and I don't want to do something wrong with someone else's money) so...later.

Don't believe it's a PayPal problem.  They're sending the correct IPN, and it's received by subscriptions.php, but SMF doesn't recognize the txn_type and subscription fails.

[Sir Osis of Liver]

Fatal error: Cannot redeclare paypal_payment::isSubscription() in /home/wazza/public_html/ATown/Sources/Subscriptions-PayPal.php on line 233

Don't see how the hack could cause that error.  Attach your modified Subscriptions-Paypal.php.

[Wazza]

Attached 

[Sir Osis of Liver]

<sigh> Posted the original code wrong, but hack was correct.  Attached should be good.

[Wazza]

Just ran in the test site if you want to look at the error log

[Wazza]

Unknown Paid Subscriptions transaction type.
txn_type: subscr_signup
subscr_id: I-5PD4V57CDU1S
last_name: Wazza
residence_country: AU
mc_currency: AUD
item_name: Try Again Subscription
business: [email protected]
recurring: 1
verify_sign: AQPPHRijwPigCZ-gJGYn5U5MSzblANEdfdWpAQ0QS4ENDFjO3wmDO7pS
payer_status: unverified
payer_email: Wazza
first_name: Wazza
receiver_email: [email protected]
payer_id: AYZ5QYZ4P53ZY
reattempt: 1
item_number: 1+2
subscr_date: 19:50:19 May 28, 2012 PDT
charset: windows-1252
notify_version: 3.4
period3: 1 D
mc_amount3: 0.10
ipn_track_id: c8c9a5a1ce3bc

[Sir Osis of Liver]

Krap.  Either I buggered up the boolean, or txn_type is checked somewhere else.

[Wazza]

Don't bet yourself up on this one!

I think you have done real well finding and trying to fix the problem 

Appreciate the effort.  ...Maybe if we leave it for a day, someone else may add some light to this? 

[Sir Osis of Liver]

Try this.

[Wazza]

okay doing now 

[Wazza]

Parse error: syntax error, unexpected '{' in /home/wazza/public_html/ATown/Sources/Subscriptions-PayPal.php on line 260

[feline]

Replace at line 258:

Code Select Expand


if (($_POST['txn_type'] == 'subscr_payment' || $_POST['txn_type'] == 'subscr_signup') && !empty($_POST['subscr_id'])


with:

Code Select Expand


if (($_POST['txn_type'] == 'subscr_payment' || $_POST['txn_type'] == 'subscr_signup') && !empty($_POST['subscr_id']))


[Sir Osis of Liver]

That's what I had previously.   Subscription didn't work, but didn't cause a parse error.  Something must be wrong with the boolean.

[Restor]

Hi All,

I needed the paid feature as well and did have some spare time to look into the paypal code. Actualy the code is pretty good as far as i can see.

The issue on my install why payments did not work all was because in sandbox mode the curl test statement failed which resulted in a fallback to plain http (fsockopen) which is not really bad either btw. But the problem i uncoverred here is that the verify request is done with a non ssl request on port 80 to paypal which at least for me did not verify in the sandbox. After changing the curl test to fixed sandbox and SSL port 443 the verify works like a charm.

Code Select Expand

                if (function_exists('curl_init') && $curl = curl_init('https://www.sandbox.paypal.com/cgi-bin/webscr'))
                {
                        // Set the post data.
                        curl_setopt($curl, CURLOPT_POST, true);
                        curl_setopt($curl, CURLOPT_POSTFIELDSIZE, 0);
                        curl_setopt($curl, CURLOPT_POSTFIELDS, $requestString);

                        // Fetch the data returned as a string.
                        curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);

                        // Fetch the data.
                        $this->return_data = curl_exec($curl);

                        // Close the session.
                        curl_close($curl);
                }
                // Otherwise good old HTTP.


I did not feel like fixing the sandbox check for now, i am now testing signing up of subcriptions and recurring payments which both seems to work flawless now. And yes you do get some IPN's which are not used about the subcription, but that is because SMF does not actualy know about the existence of the recurring payment, it just adds the amount of payed time to you current payment which had the effect of extension like a recurring subcription. If you do not receive a payment it will automaticly stop the subscription as well.

I hope this helps a but in fixing this issue.

Regards,

[Wazza]

Hi Restor,

Welcome too! ...great first post 

I will add this to the test forum later today that Krash and I have been messing with and try.

Have you still been selecting 'Allow user to auto-renew this subscription' ? with this working?

Also have you tried a live payment, not in sandbox? we were testing live with a .10^c payment set up

Thank you 

[taysan]

FWIW I've had very little luck with auto renewing subscriptions.  Frankly even the initial subscription has been spotty in terms of confirming payment back from PayPal etc.

I'm constantly having to cross reference PayPal email addresses to my members to confirm who is subscribing but of course they aren't always the same.

At minimum having the Member Name show up in the payment transaction, as well as the bloody useless 'an error has occurred' email I get when it doesn't work (what use is getting an error message email with absolutely NO useful information in it?).

I've completely stopped promoting paid subscriptions largely because it's not worth the effort involved.

[xPureEvilx]

So is this topic dead? Iam using SMF 2.0.2 and cant seem to get Paid Subs working.

[Arantor]

I've never had a problem with paid subs to be honest... the big problem with this topic and similar ones is that too many people have never had a problem with it and can't reproduce it either in order to debug it.

[Wazza]

Problem hasn't gone away I've just stopped trying to get it fixed 

In short if you're trying to use reoccurring payments your headed for 'BIG' problems.

I'm using non-reoccurring to fix the problem until a fix becomes available.

The funny thing is now I fully understand reoccurring payments even if this now gets fixed i will just stay with non-reoccurring payments.

This creates less anger from a member if they drift off, as they dont need to stop a reoccurring payment

   

[live627]

In short if you're trying to use reoccurring payments your headed for 'BIG' problems

Oh! So that's why the recurring subscriber on my site last didn't get their group added.

[Wazza]

In short if you're trying to use reoccurring payments your headed for 'BIG' problems

Oh! So that's why the recurring subscriber on my site last didn't get their group added.

Yes this is what happend to me, plus I had error messages come via emial too 
Also this created errors in my site error log

[madfiddler]

Sorry to bump, but I've been complaining about this issue for years, and never had a resolve to it. I have the 2005 issue.

What's the latest now?

Thanks,

m

[emanuele]

When I do a test subscription with recurring payment, two 'Unknown transaction type' errors are generated. PayPal executes two transactions to set up the subscription:

When you say 'Unknown transaction type' you mean the

Code Select Expand

$txt['paid_unknown_transaction_type'] = 'Unknown Paid Subscriptions transaction type.';
asking for confirmation, because that error is triggered in case the gateway cannot handle the payment at all.

I tested the recurring subscriptions in few currencies (USD, EUR, AUD) and when properly configured the aypal account to accept payment in other currencies worked without an issue.

Now I have to wait a couple of days to see if the recurring payment is accepted and processed properly.

[Sir Osis of Liver]

Yes, that's the usual error.  It's not a gateway problem because payment is successful, and subscriptions.php receives the IPN - correct payment details are in the logged error.  It just isn't processed correctly and the subscription isn't activated.  This is a common problem, and doesn't always involve recurring payments.  I've been unable to duplicate it on my test forums, so it may be host or php config related.

[emanuele]

As far as I can tell from the code, that error is generated here:

Code Select Expand

$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 isValid simply checks if the gateway *can* handle the transaction.
The checks for paypal are rather trivial:

Code Select Expand

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;
}

so:
* is paypal enabled?
* is there:
   * a) a txn_type or a payment_status POSTed?
   or
   * b) business or receiver_email POSTed?
* is the email correct?

and that's all...
It doesn't check what tnx_type contains at all.

The only case I didn't see the subscription activated was when paypal (seller paypal) was wrongly set to "ask me" for currencies different than USD and the subscriptions were set in something different than USD. In that case paypal correctly don't accept the payment and SMF doesn't activate the subscription.

[Sir Osis of Liver]

I only encountered the currency problem once, and was able to fix it.  All the other forums with failed subscriptions were using USD.  If you look at my first post top of this thread, I found IPN transaction types that are specified in Subscriptions-PayPal.php, and others that are not.  In some cases sub will fail with unknown txn_type error even though txn_type in IPN is valid and specified in Subscriptions-PayPal.php.  IIRC, in at least one case, a sub was successful with a txn_type that is not specified in Subscriptions-PayPal.php.  Wasn't able to duplicate the problem, so didn't pursue it.  I can't do anything with recurring payments because I have a personal Paypal account, and it requires a business account, but otherwise Paid Subs has worked for me in all 2.0.x versions. 

[madfiddler]

Wonder if I should start accepting USD rather than GBP then....

[Sir Osis of Liver]

Paid Subs should accept GBP - it's one of the currency choices in Settings.

[madfiddler]

Yep, I just want to find a way to make this work, and not have the 2005 bug. Just a thought to try dollars and see if that does indeed work.

[madfiddler]

Tried $ instead of £. Get the 'pending payment' issue.

[Sir Osis of Liver]

Is your Paypal account set up for GBP?

[madfiddler]

I have a business account which is set in GPB, yes, but accepts anything it seems. I've reverted back to GBP payment now, just thought I'd try.

I wonder if this is a server issue though. The SFMHacks Shop IPN appear to work either however my server logs show that Paypal is indeed contacting the server.

[madfiddler]

Something else which is interesting, if I select currency "other" it says

currency code - GBP
symbol used - &pound;%1.2f

Shouldn't symbol used be £%1.2f ?

Perhaps the internal symbol for GBP when selecting the drop down menu is incorrect?

[Sir Osis of Liver]

&pound will give you the correct symbol in html.

Post an error from your error log for a failed subscription.

[madfiddler]

OK, thanks.

I've never been able to find an error in the log, no mention at all. Only only mention in the server log saying there was a call from notify.paypal.com

[Sir Osis of Liver]

If there's no error, that usually means the IPN never reached the forum.  It's being blocked, either by a mod or your host.  If you contact Paypal merchant support, they can confirm that the IPN was sent, and if it's getting to the forum or not.

[madfiddler]

OK Krash, thankyou - I will do.

[Arantor]

Retracked under https://github.com/SimpleMachines/SMF2.1/issues/1169 to prevent it falling through the cracks any further. (Having a central place to co-ordinate all the issues does actually help )