This article may help in trouble shooting the PaymentsPlus - PayPal IPN system and further assist with Sandbox testing.

Recuring Subscriptions Verses Buy Now
I've found that since introducing One Off Payments for PayPal (web_accept), most admins are not using recurring subscriptions because their users forget they sign up for a recurring subscription and then scream blue murder when their PayPal account is automatically debited. (This is also the reason I stopped recurring support subscriptions on PaymentsPlus site, because people simply forget what they commit to. I'm saying this so you'll be aware of what future problems that you can have with recurring subscriptions on your site, my personal experience shows that a one off purchase using Buy Now option whilst can be a bit more work in marketing to get users to renew, works best and aviods the "Oh I wasn't aware it was a recurring subscription" senario that you will encounter.

Firstly, here a bit of background how the system works from when the payment button is selected.

All the Values sent with the Payment Button are sent to PayPal, on successful payment PayPal sends all the values back to your IPN script for verification. The first script ipn.php then sends all the values back to Paypal for them to verify that the transaction is valid, and if it is PayPal responds with one word VERIFIED.

There can be several IPN responses sent by PayPal, each time a response is sent by PayPal it is must go through the Verification process. The responses currently used by PaymentsPlus are as follows:
web_accept
subscr_signup
subscr_cancel
subscr_payment

The responses type received are returned in the variable 'txn_type' so an example for web_accept would be 'txn_type' => 'web_accept'. From the report that you receive you can quickly identity the response type by looking at the response 'txn_type' variable.

web_accept - web_accept is only used for the Buy Now process and has its own sign up script built in

Recurring Subsctiotions Use the following responses:
subscr_signup - subscr_signup creates an initial record for a recurring subscription. 

subscr_cancel - If the user Cancels their Subscription at PayPal, then subscr_cancel will set the publish dawn dates accordingly taking into account any remaining time left on the subscription that's already been paid for.

subscr_payment - subscr_payment records the initial payment to start the subscription and sets the subscription to remain published until the script recieves a cancel response. Currently renewal subscription payments are not recorded in PaymentsPlus for PayPal subscriptions, however Admin recieves notification direct from PayPal when a subscription renews. In furture versions PaymentsPlus may be changed to record all recieved subscription payments.

Once PayPal passed the word VERIFIED, PayPal will update their own records and does not give a Rats what your IPN script will or won't do, so it's not PayPal that updates your database, its the IPN scripts that do all the work.

After PayPal sends the word VERIFIED it collects the money, updates its own records and then notifies you and the buyer of the transaction of successful payment, cancelation, refund or what ever... then that's it, PayPals work is done!.  It's then up to the IPN scripts ipn.php and or ipn_web-accept.php to run and update the database in any case ipn.php will always run and then trigger ipn_web-accept.php if 'txn_type' => 'web_accept'

The PaymentsPlus ipn.php will not start processing till it receives VERIFIED and then ipn.php or ipn_web-accept.php will do their own series of checks to to check that the values returned by PayPal are valid. This is done by checking up to 5 values returned by PayPal to ensure it matches with records in the database and it's not some script kiddie trying to bypass your IPN script to get something for free.

In most cases where the IPN Scripts fail either in testing or live transactions is because either settings are not correct in configuration or you are using the same Listing to test with without adjusting the database record and then fails because the database already has a transaction ID recorded for that listing.

Lets look at web_accept it's the most common used and easiest to work with...
web_accept performs 5 data checks before it processes anything.  These checks are the minimum recommended by PayPal that should be performed in your as follows:
1. Is status = Completed
If its a new transaction then the status should not be Complete, if 'payment_status' => 'Completed', then its not new and we've already processed this, so the script will return false, trigger a fail message and NOT process.

2. We have not already processed the subcribe or unsubscribe for this subscr_id
When 'payment_status' => '', then we'll do another check to really make sure we haven't processed this transaction before. If we have then the value returned by 'txn_id' will be found in the database table #_ajp_orders_subscription_payments and the script will return false, trigger a fail message and NOT process.

3. The reciever e-mail account is ours.
This checks that the Admin Email address recorded in PaymentsPlus > General Settings > Mosets Tree > PayPal Admin Email matches the email returned by 'receiver_email'  if it doesn't then the script will return a fail message for this item but still process.

4. That payment amount is correct
A clever script kiddie can manipulate the values in a payment button and try to get the item for less that its real value, so this will check the value being returned by 'mc_gross' and compare it with the value stored in the database, if it doesn't match then the script will return a fail message for this item showing both the stored and returned value but still process. If there's a discrepancy here then you need to discuss it with your user and take appropriate action, one of which could be reporting the violation to PayPal and suspending the listing.

5. That the payment currency is correct
Currency, is a bit fickle to get right, PayPal returns the currency from its own records in 'mc_currency', so this means that you must have this configured in your PayPal account at PayPal and then ensure that the currency matches your PayPal Account setting to that found in PaymentsPlus > Payment Gateway Settings > Currency code (under the PayPal Settings Configuration heading) if it dosen't match then the script will return a fail message for this item but still process.

The above reports/messages will be sent to the Notify Email address recorded in PaymentsPlus > General Settings > Mosets Tree > PayPal Sales Email

The Notify Email is returned in the variable 'business'
A common error when testing with PayPal Sandbox is to use the Sandbox Testing Admin Email and when you do this you WILL NOT get the emails. This is because the Sandbox Testing Admin Email is for PayPal's internal use only within the Sandbox environment and can't send emails from the IPN scripts to SANDBOX Email accounts.

So, you need to ensure that PaymentsPlus > General Settings > Mosets Tree > PayPal Sales Email is a valid and working email account in order to receive all the reports that the IPN scripts generate.

Any attempts after the first will fail because the transaction already exists (see above data checks 1 AND 2). To re-test the listing you would need to use something like PhpMyAdmin and return all the values for that listing back to "Thank you for submitting your new listing" state assuming that the listing was New and not a renewal.

The different status triggers can be seen by reading the PaymentsPlus 2.20 manual pages 43 to 47 and alter the values accordingly.

The IPN scripts update the database automatically in a forward fashion only, so if you get an error during testing or then you need to manually revert or modify the database entries. Some fields (not all) can be re-set from PaymentsPlus Manage Subscriptions if the subscription exists, but its best to use something like PhpMyAdmin.

In the web_accept process the Tables that may need modification are as follows:

1. Table #_ajp_orders_subscription_payments delete the record for txn_id  For example lets say the Listing ID is 880 and your database prefix is jos you could find the transaction using the returned variable for 'txn_id' lets say its 29736661SS978515M by running this SQL in PhpMyAdmin:
SELECT * FROM `jos_ajp_orders_subscription_payments` WHERE `txn_id` ='29736661SS978515M'
On the returned result just place a check in the check box and click the Delete Icon.

2. Table #_ajp_orders_subscription_details
Delete the record for the Mtree Listing ID.  For example lets say the Listing ID is 880 and your again the database prefix is jos you could find the transaction by running this SQL in PhpMyAdmin:
SELECT * FROM `jos_ajp_orders_subscription_details` WHERE `link_id` = '880'
On the returned result just place a check in the check box and click the Delete Icon.

3. Update Mtree Links Table #_mt_links
Assuming the listing transaction was New Edit the listing lets say the Listing ID is 880 and your again the database prefix is jos you could find the transaction by running this SQL in PhpMyAdmin:
SELECT * FROM `jos_mt_links` WHERE `link_id` = '880'
With the result found click the Edit Icon (Pencil) and edit the following fields. Rember though that this is assuming the Transaction was NEW if it was a Renewal or something else  see the PaymentsPlus 2.20 manual pages 43 to 47 and alter the values accordingly to that particular status.
set link_published = 0
set link_approved = 0
set publish_up to the same date as link_created  (not really required but just to be complete)
set publish_down = 0000-00-00 00:00:00
set set_ipn_action = NULL
set ipn_action_notes = NULL
set ipn_status = NULL

Please Note: This article may be moved to a future update of the PaymentsPlus User Manual at a later stage.