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