Issues with Plan Fee Increases, Paypal 20% limits

Joomla 1.5.25
CB 1.8
CB Subs 2.0.1
PHP 5.4.2

DETAILS:

We have just recently taken over managing Joomla and CB support issues for our client
Our client unfortunately hit an issue following Multiple Subscription level Plan prices increases. As a result of the methodology employed they are now hitting regular renewal issues daily, which is causing serious problems with their membership base. The longer this persists, the longer it will take to resolve due to increasing registrations on a daily basis.

I will attempt to lay out the series of events leading to this problem, which have now been researched in more depth.

The organisation decided to increase annual fees across all membership plans. They asked via the forum what the best approach to do this would be and were advised to create new plans, prevent new members from signing up to old plans, and old members would be re-prompted to re-register with a new plan on renewal. As they had in excess of 1,100 members already registered they felt this would be an administrative nightmare, as well as causing members confusion and risking losing members who did not re-register again.

So the process they followed was to simply increase the plan values and adjust the Recurring payment record within PayPal. They then discovered that PayPal was limiting them to a max of 20% increase in rates E.g. 10 to 12; 20 to 24; 30 to 36, etc..
After changing the CB Subs Plans to the new 20% increase they proceeded to manually update past recurring payment records form existing members on PayPal to match the new values in CB Subs.

But they then encountered a PayPal error stating “ You are only allowed to increase the amount by 20%” EVEN THOUGH the percentage changes they were making were exactly 20% increases over the previous values. To get round the issue they applied a figure 1cent lower.. e.g. 11.99 instead of 12 euros, and 23.99 instead of 24, etc. This worked. They then proceeded to update the remaining records.

This appears to have made matters worse as, in my opinion, PayPal and CB Subs values will not match on a subsequent renewal, leading to further failures. Having said that however, on checking the PayPal recurring changes dashboard, they found that PayPal had indeed set the higher figures (e.g. 23.99 to 24 and 35.99 to 36) to the correct values originally intended but with ONE EXCEPTION, those at 11.99 still remained at that amount.

The treasurer received two emails for each change, one acknowledging the reduced value (e.g. 23.99) and another acknowledging a change of 24.00 (i.e. the original figure they wanted to achieve and which matches the specific plan value). So it appears that most changes were corrected by PayPal, but I am not convinced this is the case, as I would not expect PayPal to make such a rounding adjustment??.

Each renewal recurring payment is correctly administered by PayPal (i.e. correct PayPal set amount is charged). PayPal then sends a notification to CB Subs. but CB subs is rejecting it and thereby expiring the member.

What is not 100% clear to me at the moment is if this is happening just to items which are 1p out or to all payments, even those that do match (according to the PayPal adjustment emails).

So, the question I have is: Considering the current situation, what is the best, and most cost effective approach to resolving this issue, whilst absolutely minimising both disruption and confusion on the part of the members to ensure that CB subs and PayPal integrate correctly in future. E.g. Do they now re-adjust all the 11.99 etc. amounts in PayPal to reflect the correct plan values? Are the other values, which now appear to be correct in PayPal ACTUALLY CORRECT or just being rounded up visually in the PayPal dashboard, and in fact are incorrect? Is this proposed intervention enough to resolve the issues between PayPal and CB Subs? Or will there be other issues further down the line? E.g. on subsequent renewal anniversaries?

A secondary problem reported, is if a member upgrades to a higher plan, CB Subs/PayPal is still (sometimes - tba) leaving the earlier recurring entry intact, resulting in a double payment by the member, until the organisation manually delete the old recurring payment entry from PayPal.
Superuser Access to the Joomla backend is provided in the ticket

IN ERROR LOG SECTION:
This following message seems to be the one specifically related to renewal issues, I have verified that the IP address of the caller generating this message is almost always (99%) a PayPal server:

loadSomething::subid 1163 with planid 4 could not load.

This message also appears periodically:

NOTICE: Undefined variable: return in <span>/</span>home<span>/</span><path>/public_html/components/com_comprofiler/plugin/user/plug_cbpaidsubscriptions/processors/paypal/cbpaidsubscriptions.paypal.php on line 394

This message has also recently just started appearing as of 13/06/12:

WARNING: SimpleXMLElement::__construct() [<a href='simplexmlelement.--construct'>simplexmlelement.--construct</a>]: Entity: line 29: parser error : Premature end of data in tag Cube line 7 in <span>/</span>home<span>/</span><path>/public_html/components/com_comprofiler/plugin/user/plug_cbpaidsubscriptions/cbpaidsubscriptions.currency.php on line 91

To clarify: Increasing Paypal payment subscriptions is not something presently supported by CBSubs.

If you do this (provided your Paypal account allows you to do that, which is not the case of in 98% of countries), you would need to edit the database entries for all payment baskets which have running orders for that (the "mc_gross" column).

In this instance the client can modify recurring payments via the clients PayPal account. When they do this the member is then correctly notified of the change by PayPal.

To be clear are you saying that to reconcile the IPN failure problems reported above:

On the PayPal side, correct all recurring payment profiles to match the relevant plan values: e.g. modify $11.99 to $12.00.

Then edit the database entries for all payment baskets changing just the "mc_gross" column value to also match $12.00 if it does not already. Are there any other database values in this table or other tables that also need to be considered?

Q: Do CB Subs intend to provide a facility to increase subscriptions. I'd imagine the majority of recurring plan installations out there would be interested in having an option that handles this. This is also evident in the PayPal Developer Forums.

Yes, correct, payment baskets need to match, as they represent the "order" and are those that are checked.

R: it is a feature-request that is not that easy to implement cross-payment-providers, specially as the leader, Paypal, does not allow that in most countries, it is not a popular demand yet on our end. Also we have a few other features that need to be implemented on which this one depends (at least to be able to do it automatically) with PSP APIs).

As a Test for this issue I created a new Plan, charging $1 and expiring in 3 days. I then subscribed a test user to this plan. All fine.

After subscribing the user I then changed both the plan value (to $1.50) the plan duration (to 1 day) and reduced the privileges from "publisher" to "editor" . I did not touch the PayPal side of things.

Three days later PayPal automatically charged the test user $1, sent a notification to CB Subs which was successful. I expected this to fail as the Plan amount and the PayPal amount charged do not match (?)

I checked the User Profile, and the Plan appears as Expired, but the User is still 'ACTIVE' and still has privileged access (i.e. publisher). I assume it is only active as there is a grace period of 10 days (?).

Three days later Paypal charged $1 again. Once again this appears successful on CB subs side. So, contrary to the other errors reported this one seems silent.

Beat, do I need to adjust other database fields, apart from the mc_gross one? e.g. mc_fee - If so, how does one calculate the fee as it appears it may be accumulative.

I am testing some repairs today so need to know by tomorrow latest. D