Upcoming Change to PayPal Subscriptions

[MTS_Ciaran]

PayPal is making changes to the way Subscriptions are created, managed, and displayed. For additional information, see our article Why am I seeing changes to how Subscriptions are reflected?

[S_S_S]

So far PayPal tech support has been utterly unhelpful. Taking days to reply with a message like "upgrading subscriptions more than 20% was never possible" which is clearly untrue, denying it even when provided with screenshots of actual upgrades. Since our business very much depends on users being able to upgrade we've just completed the transition away from PayPal for new customers. We went with Braintree, a daughter company of PayPal, because they can actually do PayPal subscriptions with normal upgrades again (without the customer present even!), and also restores the ability to retry a failed subscription three times instead of halting the subscription on the first failed payment (seriously, who thought that was a good idea?).

The API of Braintree is very different, so you are going to need some serious programmer hours to redo the integration, especially if you (like us) don't want cancel the existing customers and thus need to support both APIs. The integration is not a smooth as a new player like Stripe but Braintree's tech support is a dream compared to PayPal's.

[swinny]

either i am simply missing the bigger picture (and someone say so, please) or the replies from support are getting sillier.  The below is the most recent reply italics with my concerns.

"Since this is a backend processing change, it was not disclosed on that FAQ page. We never disclose specific details on how the payments are processing/batching. What you are observing is correct and intended functionality.

They did not find it necessary to disclose the change to GMT subscription set ups.  even though 1) it breaks a lot of implementations already out there running, and have been for years.  2) it is also brings in the whole problem about merchants having to address those users who can get up to 4+ hours (depending on time zone from GMT) of free access.  should we have some special dynamic price that updates each evening for anyone who signs up then?  A user who signs up at 20:01 but wont be rebilled until say, 05:00 the following period essentially has 9 hours of free usage.

When the profile is created and billed, you can get the details of the subscription from us and you can confirm the renewal dates. This API is outlined here: https://developer.paypal.com/docs/classic/api/merchant/GetRecurringPaymentsProfileDetails_API_Operat...

You can look to use Reference Transactions to bill the users for the 3-4 hours of potential free access when someone subscription will roll over into the next day's batch. https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECReferenceTxns/

Doesnt this seem like a LOT of new headaches for something that has always just worked and if this is what was needed for the new subscription system, why wasnt this indeed communicated to merchants (note above, this is apparently just a "backend processing change" not worthy of us to know).

Something really does not add up.

[btibor]

hello @MTS_Ciaran, I'd like to clarify couple of points here:

- event details page seems to be not accessible anymore (https://www.paypal-status.com/history/eventdetails/8180) 

- event FAQ previously stated:

>What will happen if my old S- Subscriptions next payment cycle is after December 2018?
>
>We will be sending out an email in October with the mapping of old Subscription ID and the new Subscription ID to all the merchants who have their next payment cycle after December 2018.

Are you sending out this mapping e-mail(s) already? When are you going to stop sending "old_subscr_id" in IPNs?

Thanks & Best regards,

Tibor

[statcounter]

My first post on this forum. Can i completely skewer paypal for changing existin subscription ids. What an idiotic and stupid thing to do. Fair enough, change new subscription ids, but don't force everyone to update their old subscriptions. Absolutely ridiculous and no need for it. Completely turns me off wanting to ever use paypal for anything.

That said, we do have subscription with paypal and we need to suppor them. When are we going to get the mapping information from "S-" subscription ids to the new "I-" subscription ids?

[swinny]

statcounter,

at least for subscriptions under my account, they already did the mapping of a lot of them.  i dont understand how they are doing it.  i assume it is happening upon the next rebill.  it may have even started for you and you do not realize it.

when i look at the subscription renewal emails, the line showing "Profile ID:" will have the new "I-" prefix and directly to the right of the new ID will be the "S-"  (old) subscription ID in parentheses. 

what i would like to know is what certain emails mean.  out of the blue i will get emails with the subject "Automatic payment changed" with absolutely zero info about WHAT changed.  it obviously wasnt canceled.  it doesnt appear the changes make any difference to the merchant, so what the heck are we getting these for?

the other silly issue is, a new subscription set up generates TWO emails now.  Why?  wouldnt one email saying a new subscription profile has been created and a payment of that specific amount work?

[statcounter]

They've already started migrating our old "S-" subs to new "I-".

I was complaining as they have not even given us a text file with the mapping from the old subscription number to the new ones. It's absolutely nuts.

[Rob-sortitoutsi]

I really can't believe how badly this move has gone.

I'm getting IPN's for existing subscriptions with no old_subscr_id, that means i'm getting an IPN for a payment to "I-xxxx" but no I have no idea who it's for because in my DB it's saved as "s-xxxx" and old_subscr_id is not included. 

We're talking about subscriptions which have been active since 2011 here and now I have to manually try and figure out who each payment was for based on their name or email address.

Right now i'm only getting "old_subscr_id" in 90% of cases, 10% I have to manually do myself, which is completely unacceptable for a payment gateway like paypal.

That's not even going into how bad an idea it was to switch the ID's in the first place. 

[stoem]

May I ask PayPal the following:

What. The. Actual. **bleep**?

Our subscription logic, which has been in place for a decade (we have subscriptions that are as old as that and still active), contains a bit of code that goes something like this:

'Check the subscr_id, if it doesn't already exist then create a new subscription.'

We're now receiving I- subscription ids which we have no knowledge of for subscriptions that have been S- for a decade. We also haven't had any communications about this change. 

I mean are you serious?

Can someone explain what's going on? I read something about a mapping you'll send us - has this happened? 

Good god, this is beyond a joke.

Stefan

[statcounter]

Rob and Stefan. That's the exact same problem for me. I've gotten a response from paypal to say they didn't want this update for old subscriptions to go out. This was accidental.

[not_here]

Hi @stoem @Rob-sortitoutsi @Rob-sortitoutsi @swinny

I sincerely apologize for the lack in communication with this update. You'll find content has been created for the changes here. I'm also working with the teams to get a project status update out on PayPal Status. 

Please look over the information in our article. If you find that you still have open questions, please feel free to respond here and I will get your answers as quickly as possible.

Christina