News:

SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

2.0.2 Subscription Erroring - Giving Wrong End Time

Started by TitanTlaloc, August 23, 2012, 10:56:08 PM

Previous topic - Next topic

TitanTlaloc

Hi all,

My subscriptions all go through paypal correctly, but then there are error's immediately afterwards.

I tracked down the problem to the fact that the end time of the subscription is incorrect. It always sets the year to 2005, which causes an error.
The start date is always correct.

Any suggestions?

TitanTlaloc

Just to clarify,

The errors are not page errors, just coding errors.
The visual error is that I get an e-mail stating there is a subscription error.
(In addition to noticing the end_time subscription date is set to year 2005)

Sir Osis of Liver

Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

TitanTlaloc

Hi again!

Been a while.

I searched through the forum to see if this has been solved but I'm not the only one running into this issue still.
I looked through the error_log file and I don't see anything involving this.

I can tell you that when someone subscribes, it puts them into the group I pre-selected in the settings,
However if you go to the subscription, it will say that the subscription is "finished" and not "active"
If I pull up their subscription history, it says that their start date / time is correct, but the end date / time are set to 2005 for the year, which I believe is what is causing the problem.

I checked my IPN settings for paypal and they check out ok, and I am recieving the payment every time, in addition to the user getting the proper usergroup -- so the communication seems fine to paypal.

Furthermore, I will get an immediate email stating "
Subject: Paid Subscription Error Occured
Body
"The following error occurred when processing a paid subscription
------------------------------
Unkown Paid Subsciptions ttransation type.
"
"

As I said for a while back, the error seems to revolve around the fact that the "end_date" is set to the year 2005, so the subscription gets confused.

Any ideas?
Thanks!

TitanTlaloc

As an update, I just had 4 subscriptions go through and the usergroup does not update.

madfiddler

Hi, same issue year. I've posted a number of times about this in various threads, but never got to the bottom of it.

I wonder if it is something server side rather than an issue with the forum code?

Sir Osis of Liver


The end date is always 2005 when subscription fails.  Post the complete error from your error log.

Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

MrPhil

By any chance does this subscription thing make use of the Calendar start and end year limit? If your SMF has been around for a while (and you haven't been using the Calendar), you might want to check if the max year is still 2005, and change it to 2015.

Sir Osis of Liver


Don't think so, Phil.  IIRC, 2005 is the default end date if a subscription is not successfully activated.  An unknown trsansaction type fails basically because subscriptions.php doesn't recognize the transaction type posted by the IPN, so it takes no action.

Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

TitanTlaloc

#9
Here is one from today.


Unknown Paid Subscriptions transaction type.
transaction_subject: <Removed>
payment_date: 16:38:00 Nov 02, 2012 PDT
txn_type: web_accept
last_name: <Removed>
residence_country: US
item_name: <Removed>
payment_gross: 15.00
mc_currency: USD
business: <Removed>
payment_type: instant
protection_eligibility: Ineligible
verify_sign: A8IL3LvQi-Y9xapU7iFvNmIS.HuqArlmtfLOsv.GnouWN8-p28znLEtB
payer_status: unverified
tax: 0.00
payer_email: <Removed>
txn_id: 5V061186BY7209639
quantity: 1
receiver_email: <Removed>
first_name: <Removed>
payer_id: <Removed>
receiver_id: P2FKYV4RY9JRJ
item_number: 5+504
handling_amount: 0.00
payment_status: Completed
payment_fee: 0.74
mc_fee: 0.74
shipping: 0.00
mc_gross: 15.00
custom:
charset: windows-1252
notify_version: 3.7
ipn_track_id: 9e32c2d1cc416

Sir Osis of Liver


Subscriptions-PayPal.php recognizes web_accept as a legitimate transaction type, so I suspect something else is wrong, and it's throwing that error for lack of having a more accurate one.  You can try setting up 1 day/$.10 test subscription and a test member, and see if the error occurs when you subscribe from the member account.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

TitanTlaloc

Still having the same issue. I did one with a recurring and this is the beginning of the error notice:

Unknown Paid Subscriptions transaction type.
txn_type: subscr_signup

When I get one with a non-recurring I'll post it. All of my previous posts/examples involve non-recurring transactions.




TitanTlaloc

#12
I just this error for refunding the order:

Unknown Paid Subscriptions transaction type.
transaction_subject: Test_normal Subscription
payment_date: 21:02:52 Nov 02, 2012 PDT
subscr_id: I-R5H230C9P6EN
last_name: <Removed>
residence_country: US
item_name: Test_normal Subscription
payment_gross: -0.10
mc_currency: USD
business: <Removed>
payment_type: instant
protection_eligibility: Ineligible
verify_sign: AqBqA1nSf.CEBj1d5rbDP.LO-woKAUjO9FXpmmPPdLFWy-tqlq44OKZA
payer_email: <Removed>
txn_id: 7VL736483H205524T
receiver_email: <Removed>
first_name: <Removed>
parent_txn_id: 5CX94182340833546
payer_id: <Removed>
receiver_id: P2FKYV4RY9JRJ
reason_code: refund
item_number: 8+7
payer_business_name: <Removed>
payment_status: Refunded
payment_fee: 0.00
mc_fee: 0.00
mc_gross: -0.10
charset: windows-1252
notify_version: 3.7
ipn_track_id: f04756348dc56

Sir Osis of Liver

As far as I can see, subscr_signup is not recognized by Subscriptions-PayPal.php as a valid transaction type.  The error logged for the refund does not contain a txn_type.  Can't tell if this is a problem with the IPN or just the error logging.  Subscriptions-PayPal.php recognizes Refunded as a valid transaction type , but if it's not there, the transaction fails.

If you go here, there's whatever info I was able to come up with for a previous goround with this feature.  It was never resolved, but non-recurring subscriptions should work properly.

Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Advertisement: