New to the community? Welcome! Please read our Community Rules and Guidelines
Join the live Q&A with our Community moderator team Wednesdays, 1-2pm PT (4-5pm ET) and Fridays, 4-5pm GMT. Learn more in Community Events
@swinny Perhaps you can actually set up the max payment failures when creating new subscriptions, but I only asked tech support about the existing subscriptions because we have thousands of those that we are having this issue with.
(We switched to creating new PayPal subs through Braintree because those can still be upgraded, the I-type subscriptions can only be upgraded 20% which doesn't work for us, and Braintree automatically does the 2 failures thing)
So we now have a load of subscriptions that our system shows as still active when they've actually been cancelled because the payPal notifications are sending us i-xxxxxxxxx references for subscriptions that were notified as s-xxxxxxxx when they were set up.
There is no mention of the s-xxxxxxxx reference in the suspension notifications so how are we supposed to tally up which subscriptions are cancelled?
@swinny On the Recurring Payments screen (https://www.paypal.com/cgi-bin/webscr?cmd=_merchant-hub) you can set the filter to "Suspended" to find those subscriptions.
Thanks for that but I know that list, hence being aware of suspended subs that our site doesn't know are suspended.
The problem is, these suspensions are still only referenced by the i-xxxxxxxxx identifier. All these subs were given an s-xxxxxxxxxx when they were set up. What genius thought it was a good idea to just randomly change a unique identifier and replace it with another, different unique identifier without any notification or transition procedure.
...or maybe there is a procedure that I just haven't heard about?
Yes, I can trace these users individually and manually edit the database to replace the s-xxxxxxxx refs with i-xxxxxxxxx refs but, these are about to start coming thick and fast and I just don't have the time to deal with them all manually. The whole point of putting up with payPal's high charges and lame customer service is that the api makes things work without loads of manual input. Right now, payments via my old school bank account are lower maintenance than the payPal ones.
I apologize for the frustration that this is causing to your daily processes. The way that I understand is that you should have received a mapping in the following manners:
If you did not receive this, I'd suggest you submit a ticket with our Technical Support team requesting a mapping of your subscriptions.
That sounds great and if that's what was happening, I'd have figured it out without moaning about it on here>
We've been logging all inbound traffic from payPal and here are all the fields submitted with this transaction:
product_name=Gxxx Cxxxxn\'s very own annual subscription
time_created=10:54:11 Nov 12, 2016 PST
payer_email=userEmail @ xxxxxx.com
receiver_email=xxxxx @ mydomain.com
residence_country=GBThe txn_type is recurring_payment_suspended_due_to_max_failed_payment
So.... how are we to ascertain from this, the subscription that has been suspended when it was created by payPal with a s-xxxxxxxxxx reference?
I agree that with the information you receive below, it would be difficult to sort out that information. My suggestion would be to submit a ticket to Technical Support who can help you with your specific account.
I completely agree that this change has negatively impacted day-to-day business processes and it's my goal to help bridge the customers and teams involved to improve this process going forward. I sincerely apologize for the inconvenience this has caused.
OK, as we've established above: the txn_type=recurring_payment_suspended_due_to_max_failed_payment does not include the old subscription ID although weirdly, the email notification does include it (in brackets) so the omission means there's no way to deal with this programatically although using the emails we are, in effect, invited to deal with it be updating the database manually -- frankly, it's all a bit naff and unprofessional.
Thanks for your invitation to submit a ticket: the page you linked to was one of those ones designed to avoid customer contact: it just sent me round in circles and eventually told me to ask the community so here I am, no further forward other than deepening my resolve to implement an alternative payment solution as soon as time and resources permit.
If it's not impolite to ask: since you're an employee of PayPal and you know that this fault exists, why don't YOU submit a ticket? I'm damned if I can get through the obfuscation process to figure out how to.
I apologize for the negative impact that this caused. For the first issue, I've passed this feedback onto the team to find a solution.
With regards to submitting a ticket, if you go to https://www.paypal-support.com you'll find at the bottom a button that says "Contact Us". If you submit a ticket there, an MTS Engineer will be able to help you. Unfortunately, I'm unable to submit a ticket on an account that isn't mine.
Again, I can only apologize for the inconvenience this has created and I understand the situation you are in if you have to switch solutions. Hopefully we can solve your problem before you are forced to do this.
I wrote a small script that changes the "max failed payments" for each active subscription from 1 to 2, it works but please be aware that it sends an email to each customer telling them their subscription has been updated. Of course, tech support had assured me no messages would be sent if you changed the 'max failed payments' through the API. Sigh.