Unexpected txn_type error?

[Tsquared]

I tried using the buy now/one-time/non-recurring/no trial option instead of subscriptions since a) we're not doing auto-renewal so we don't need them, and b) PayPal subscription management is so completely hosed right now that I don't even know where to start. I used the button generator in the s2Member plugin to create the pay button.

However, the Buy Now option fails right after you submit the payment in PayPal but before you get to the registration page on our member site. You get the error in a dialog box: "Unexpected txn_type. The PayPal® txn_type did not match a required action." Looking at the logs, PayPal is sending back as the txn_type = 'web_accept'.

For subscriptions it returns 'subscr_payment', and subscriptions do work here in that I can pay for it and go through the s2Member registration steps and get an account on our site. They don't work in the sense that PayPal sends the IPN stuff back in the dumbest way imaginable (the cancel arrives before the member can even create an account -> error; and don't get me started on it sending a cancel in the first place 1 second after you pay for a one-year membership). Plus the member gets an e-mail from PayPal saying their profile has successfully been cancelled, which I'm sure will freak everyone out the minute we go live, even though their membership really is active and will be for a year. I know the background of PayPal's IPN nonsense, but this is even a bigger fail than I thought.

Anyway, I'd rather use the Buy Now option because members will have to manually renew anyway and so there's no need to use the subscription option in PayPal. But something isn't agreeing with s2Member here. Does s2Member not accept 'web_accept'? Any ideas?

Thanks
T2

Log entry included below (private info redacted)

array (
'transaction_subject' => 'www.mysite.com',
'payment_date' => '08:01:47 May 21, 2010 PDT',
'txn_type' => 'web_accept',
'last_name' => 'Smith',
'residence_country' => 'US',
'item_name' => 'One-Year Membership',
'payment_gross' => '0.01',
'mc_currency' => 'USD',
'business' => 'ouremailaddress@gmail.com',
'payment_type' => 'instant',
'protection_eligibility' => 'Ineligible',
'payer_status' => 'verified',
'tax' => '0.00',
'payer_email' => 'payeremail@earthlink.net',
'txn_id' => '1US92867U0707124F',
'quantity' => '1',
'receiver_email' => ''ouremailaddress@gmail.com',
'first_name' => 'John',
'payer_id' => 'VACSJZ2PTGX6U',
'receiver_id' => '7KVD93H94V6GJ',
'handling_amount' => '0.00',
'payment_status' => 'Completed',
'payment_fee' => '0.01',
'mc_fee' => '0.01',
'shipping' => '0.00',
'mc_gross' => '0.01',
'custom' => 'www.mysite.com',
'charset' => 'windows-1252',
's2member_log' =>
array (
0 => 'Return-Data received on: Fri May 21, 2010 3:01:58 pm UTC',
1 => 's2Member POST vars verified through a POST back to PayPal®.',
2 => 's2Member originating domain ( _SERVER[HTTP_HOST] ) validated.',
3 => 'Unexpected txn_type. The PayPal® txn_type did not match a required action.',
4 => 'Redirecting Customer to the Login Page, due to an error that occurred.',
),
'subscr_id' => '1US92867U0707124F',
)

[Tsquared]

I think I solved my own problem. Don't know whether this is a bug, feature, or my stupid programmer skills.

I had what I thought was a decent enough idea in that I took out the item number in the PayPal button code because my client only has one item (a one-year membership) and has no real need to track anything by product ID. I didn't want to confuse them with more data. This was apparently a bad idea.

I was rooting around the paypal-return.inc.php code in the s2Member plugin, and it looks like omitting the item number breaks all the parsing you're doing of the stuff PayPal sends back to the site. Somewhere around line 92 of the code (at least in my editor) it looks for $paypal["item_number"], which like I said I didn't use in my button code. I guess instead of failing gracefully and ignoring the fact that it's missing, it just fails on down to the else statement that writes the error I got in the logs.

I didn't realize until just now that this had nothing to do with subscriptions vs. buy now. It's just that the subscription test I did used the item number and the buy now I ran did not. D'oh!

It might be worth setting this up to where it can live with what I did and still allow the process to not fail and the member to register. I think what I did wasn't unreasonable though I should have thought more about the implications of it before I did it.

And knowing's half the battle!

Thanks.
T2