Subscription Price Verification

[kbadr]

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

[Rich_Z]

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?

[Andreas]

From paypal.php

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

[Marco van Herwaarden]

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.

[mfarmerhi]

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?

[Rich_Z]

Originally Posted by mfarmerhi

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

Are you serious? :down:

[mfarmerhi]

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

		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:

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