Workarounds for 2Checkout Subscription Purchase Issues

If you are using vB 3.6.0 or vB 3.6.1 and have not applied this fix, then when someone makes a vB subscription purchase, the sale does not get recorded in vB, even if you allow customer passback, and the customer can get stuck on a blank page.

If you are using vB 3.6.2 through vB 3.6.4, the sale will get recorded in vB when you allow customer passback, but the customer can still get stuck on a blank page.

Regardless of whether you are using vB 3.6.0 to vB 3.6.4, when users go to make a 2Checkout purchase, they see a hash string, but no product details like the name of the item they want to purchase.

2Checkout now requires the use of 'id_type' and 'c_prod' to be passed to identify the product being purchased, but vB 3.6.0 to vB 3.6.4 currently has nothing in place to account for this input.

These instructions provide workarounds for the aforementioned issues.

[projectpilot]

I have tried this. Some part of works like the payment page at 2checkout.com shows the product information. But when someone pays, it takes them to sometimes a blank page or sometimes to an error page.

IS there anything I need to look at in particular?

[calorie]

There is one more line at the bottom of the payment_gateway.php file:

if ($apiobj->display_feedback AND !empty($apiobj->error))

Where you could change it to the following if you want:

if (($apiobj->display_feedback OR $apiobj_display_feedback) AND !empty($apiobj->error))

But a user only winds up there if the payment doesn't verify.

If you are testing in demo mode, set up a 0.01 subscription and try it live. Also, double check that all the file edits are in the correct locations. After a verified payment, you should wind up back on the payments.php page or the login thereto.

[projectpilot]

Originally Posted by calorie

There is one more line at the bottom of the payment_gateway.php file:

if ($apiobj->display_feedback AND !empty($apiobj->error))

Where you could change it to the following if you want:

if (($apiobj->display_feedback OR $apiobj_display_feedback) AND !empty($apiobj->error))

But a user only winds up there if the payment doesn't verify.

If you are testing in demo mode, set up a 0.01 subscription and try it live. Also, double check that all the file edits are in the correct locations. After a verified payment, you should wind up back on the payments.php page or the login thereto.

Yes it worked. Thanks a lot. I haven't tested but does it work for recurring payments? In 2 checkout there is a recurring product setup option. Is it compatible with the vBulletin 3.6.4?

[hydn]

Does this work or can be adapted for 3.5.7?

thanks

[pmkb]

Originally Posted by projectpilot

... does it work for recurring payments? In 2 checkout there is a recurring product setup option. Is it compatible with the vBulletin 3.6.4?

Same question, but for 3.7.2 PL 1...

[addamroy]

I'd like to see some kind of fix for 4.xx versions of vbulletin ... PLEASE PLEASE PLEASE fix the 2checkout issues. I'd greatly appreciate it and so would many other vbulletin users.