vb.org Archive - Subscription Price Verification

vb.org Archive (https://vborg.vbsupport.ru/index.php)

- Modification Requests/Questions (Unpaid) (https://vborg.vbsupport.ru/forumdisplay.php?f=112)

- - Subscription Price Verification (https://vborg.vbsupport.ru/showthread.php?t=73419)

Subscription Price Verification

(I posted this at VB.com, but I was told it was a hack request and I should post it here. All I need is a "yes" or "no", though. I don't need code)

I wasn't sure where to post this. It's a question for a VB developer, I think.

I want to hack the subscriptions.php page to conditionally change the price of a subscription (to allow upgrades for someone who purchased a different subscription plan already.) I am proficient in PHP and I know how to do this.

My question is, if a subscription is listed in the VB database as costing $X, but Paypal processes it as $Y, will VB reject the subscription? Does it do any sort of check to make sure the amount Paypal received is the amount the subscription costs, as listed in the VB database? I looked at the VB code, and it doesn't seem to do a check like this, but I just wanted to post to make sure.

If the price is verified, that's not really a problem. I just can just create an additional Upgrade Subscription that is only visible to users who should get the special upgrade price.

Thanks, ahead of time.

Actually, I would be interested in this hack myself if you go ahead and develop it. I am just starting a multi-level subscription program, and users are asking me about upgrades already....

Did you get this done yet?

From paypal.php

Code:

$sub = $DB_site->query_first("SELECT * FROM " . TABLE_PREFIX . "subscription WHERE subscriptionid = $subscriptionid"); 

$cost = unserialize($sub['cost']);

if ($_POST['tax'] > 0)

{

        $_POST['mc_gross'] += $_POST['tax'];

}



// Check if its a payment or if its a reversal

if ($_POST['txn_type'] == 'web_accept' AND $_POST['payment_status'] == 'Completed')

{

        if ($_POST['mc_gross'] == $cost[strtolower($_POST['mc_currency'])])

        {

                build_user_subscription($subscriptionid, $userid['userid']);

Take a look at the highlighted part. To me this seems like vBulletin does check the amount.

Why don't you set up 2 subscriptions. One for the first purchase, and a second for an upgrade, both with their own price. All you got to do now is (optionally) only allow an upgrade if there is already a first purchase. This would mean less fidling with the important parts of the code.

Aaargh! I can't believe vB assumed that once a subscripton was began that site owners would NEVER EVER IN ALL OF TIME want to change the subcription price, without cancelling out everyone currently subscribed.

Worse if you've installed the reoccurring subscription hack so that subscriptions are automatically renewed...

kbadr, how did you solve the problem of raisin subscription prices? Anyone else have thoughts about how to hack / handle this?

Quote:

Originally Posted by mfarmerhi

Are you serious? :down:

Quote:

Originally Posted by Rich_Z

Are you serious? :down:

Er... serious about what? My disbelief that vB wouldn't think a site owner might ever raise prices?

Yes.

That the problem is compounded if you have reoccurring subscriptions?

Yes.

So, um... yes, I'm very serious. I'm earning money witn my forum; intend for it to be a major part of my business. If vBulletin is intended to be anything more than a hobbiest's application, they'll need to think more deeply about where their product intersects with ecommerce. Er... and this is seeming like a pointless aside.

More to the point has anyone ever considered a fix for vb's shortsightedness?

Okay... technically changing prices isn't a problem only and unless you have the reoccurring hack installed (https://vborg.vbsupport.ru/showthread.php?t=64834
). Simply changing the price does not cancel existing Memberships -- they expire naturally at the end of their set dates.

Without the reoccurring hack Members would need to manually re-subscribe ANYWAYS, thus being able to choose whether they want to re-subscribe at the new, higher price.

However, IF you've already installed the Reoccurring hack AND raised the price, this all become a problem: an automatic subscription payment at the old price will NOT renew the subscription at the new price. The subscription fails and that Member would need to manually resubscribe if they choose. (And we all know, the more action you require of a customer, the lesser your chances are of making the sale -- the whole purpose OF making subscription payments automatic.)

The down and dirty solution IF you've installed the reoccurring hack AND need to raise prices is to change the the reoccurring hack's step 4 to:

Step 4:

Find

Code:

                if ($_POST['txn_type'] == 'web_accept' AND $_POST['payment_status'] == 'Completed')

                {

                        if ($_POST['mc_gross'] == $cost[strtolower($_POST['mc_currency'])])

                        {

                                build_user_subscription($subscriptionid, $userid['userid']);

                        }

                }

                else if ($_POST['payment_status'] == 'Reversed' OR $_POST['payment_status'] == 'Refunded')

                {

                        delete_user_subscription($subscriptionid, $userid['userid']);

                }

Replace that entire section with:

Code:

                if ($_POST['txn_type'] == 'web_accept' AND $_POST['payment_status'] == 'Completed')

                {

                        if ($_POST['mc_gross'] == $cost[strtolower($_POST['mc_currency'])])

                        {

                                build_user_subscription($subscriptionid, $userid['userid']);

                        }

                }

                else if ($_POST['payment_status'] == 'Reversed' OR $_POST['payment_status'] == 'Refunded')

                {

                        delete_user_subscription($subscriptionid, $userid['userid']);

                }

                          else if ($_POST['txn_type'] == 'subscr_payment' AND $_POST['payment_status'] == 'Completed')

                          {

                                build_user_subscription($subscriptionid, $userid['userid']);

                }

I say "down and dirty" because this "solution" does NOT check the amount of the reoccurring subscription payment against the cost of the subscription (the price has changed, right? We don't want it comparing the sub. payment to the new price, we already know they don't match. And, the old sub. cost isn't recorded anywhere, so we have no way of telling whether the sub. payment matched the old cost anyways... thus, the complete elimination of comparing the payment to the expected cost).

It's down and dirty because, without the price checking it's theoretically possible that someone might fool with the subscription amount in the payment (say, changing it to $1 every 10 years) and still have the system recognize it as a valid subscription. Unlikely... but possible.

So... that's my contribution.

The real solution would require maintaining a record of old subscription costs in a new variable(s) in order to compare future subscription payments against those. Still a relatively simple hack (er... kind of), but beyond what I feel like working through at 1 am in the morning...

X vBulletin 3.8.12 by vBS Debug Information
Template Usage: (1)ad_footer_end (1)ad_footer_start (1)ad_header_end (1)ad_header_logo (1)ad_navbar_below (3)bbcode_code_printable (2)bbcode_quote_printable (1)footer (1)gobutton (1)header (1)headinclude (6)option (1)post_thanks_navbar_search (1)printthread (7)printthreadbit (1)spacer_close (1)spacer_open Phrase Groups Available: global postbit showthread	Included Files: ./printthread.php ./global.php ./includes/init.php ./includes/class_core.php ./includes/config.php ./includes/functions.php ./includes/class_hook.php ./includes/modsystem_functions.php ./includes/class_bbcode_alt.php ./includes/class_bbcode.php ./includes/functions_bigthree.php Hooks Called: init_startup init_startup_session_setup_start init_startup_session_setup_complete cache_permissions fetch_threadinfo_query fetch_threadinfo fetch_foruminfo style_fetch cache_templates global_start parse_templates global_setup_complete printthread_start bbcode_fetch_tags bbcode_create bbcode_parse_start bbcode_parse_complete_precache bbcode_parse_complete printthread_post printthread_complete
Messages:

Phrase Groups Available:

X vBulletin 3.8.12 by vBS Debug Information
Page Generation 0.00973 seconds Memory Usage 1,743KB Queries Executed 10 (?)
More Information
Template Usage: (1)ad_footer_end (1)ad_footer_start (1)ad_header_end (1)ad_header_logo (1)ad_navbar_below (3)bbcode_code_printable (2)bbcode_quote_printable (1)footer (1)gobutton (1)header (1)headinclude (6)option (1)post_thanks_navbar_search (1)printthread (7)printthreadbit (1)spacer_close (1)spacer_open Phrase Groups Available: global postbit showthread	Included Files: ./printthread.php ./global.php ./includes/init.php ./includes/class_core.php ./includes/config.php ./includes/functions.php ./includes/class_hook.php ./includes/modsystem_functions.php ./includes/class_bbcode_alt.php ./includes/class_bbcode.php ./includes/functions_bigthree.php Hooks Called: init_startup init_startup_session_setup_start init_startup_session_setup_complete cache_permissions fetch_threadinfo_query fetch_threadinfo fetch_foruminfo style_fetch cache_templates global_start parse_templates global_setup_complete printthread_start bbcode_fetch_tags bbcode_create bbcode_parse_start bbcode_parse_complete_precache bbcode_parse_complete printthread_post printthread_complete
Messages: