Paid Subscriptions - Always enddate 2005 and Status is Finished

[Sir Osis of Liver]

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.

[agentblackhat]

When is a good time for you guys?

[Sir Osis of Liver]

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.

[Sir Osis of Liver]

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.

[Arantor]

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.

[Sir Osis of Liver]

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.

[Arantor]

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.

[Sir Osis of Liver]

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.

[Arantor]

Was it naive of me to assume you actually had the problem since you seem to know all about it?

[agentblackhat]

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.

[Sir Osis of Liver]

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.

[Sir Osis of Liver]

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).

[Sir Osis of Liver]

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 -

Code Select Expand



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?

[agentblackhat]

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.

[Sir Osis of Liver]

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?

[agentblackhat]

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?

[Sir Osis of Liver]

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.

[Sir Osis of Liver]

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

 

[Arantor]

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.

[Sir Osis of Liver]

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.