We’re writing an article on how to switch payment gateways for Paid Memberships Pro. In the article, we want to help site owners with the best practice way to get old members moved to the new gateway. One option is to cancel everyone and ask that they buy again through the new portal. Some sites, though, want to slowly migrate people to the new gateway only when their payment method fails on the old one.
In this video, Jason and Kim chat through a feature request for the Paid Memberships Pro plugin to better handle billing method and subscription updates when a membership site has switched payment gateways.
[00:00:00] Kim Coleman: We are writing an article about switching payment gateways, and a part of this article talks about the membership billing page, which is the page in our plugin where a member would get an email saying ” your payment method on file is expiring” or “your payment method failed.” Update your billing information.
So when those two events happen, an email is sent. A link is included to the membership billing page. But there is a edge case where the payment gateway for the live site may be different then the payment gateway that was used when the subscription was originally created. Right.
The article outline I wrote says that you should put a note on this page to say that “We are using a different payment gateway. If you see a notice that your billing information cannot be updated, you should complete a new checkout. And Patrick and Mandy have asked whether this could be something automatically handled in the plugin.
So I am interviewing Jason. Yeah, slash in public talking through how we as founders would think about this as a feature and the implications.
[00:01:10] Jason Coleman: It might help to think about what’s ideal. Pretend we could snap our fingers and make it work, in an ideal world.
That message we show this feels like a catch all. Oh, I’m confused. Just show them the message that it can’t be updated. Right, right.
[00:01:24] Kim Coleman: We’re looking at here.
[00:01:25] Jason Coleman: Your billing information cannot be updated at that time. So we, we’re not making a judgment when we do that. But what would you want it to do? You would want it to just work and you can keep your payment settings in the background for Authorize.net while you have Stripe settings. And so when you’re on this page, we theoretically should be able to tell the subscription associated with this user is linked to another gateway. Update them through the other gateway. As long as we have API information, credentials and things.
I think an ideal world. Completely ideal world. Is that. It would come to this page, allow you to update billing information. And automatically create a new subscription at the preferred default site gateway.
You don’t want people on Authorize.net anymore. What might come up in that post, what I recommend a lot of times is: cancel everyone’s subscription, send them an email, tell them that you have a new payment gateway, give them a month free and have them switch over.
Everyone says, oh, we can’t do that. Not, everyone’s going to sign back up, which is totally true.
[00:02:24] Kim Coleman: There’s a lot of fear there. For people who’ve built up a longstanding number of people they’re making the switch for the new payment gateway for who knows what reason?
[00:02:34] Jason Coleman: Saying, Hey, just cancel all the subscriptions, force them to switch over now. We know they’re going to lose some subscribers. So what you want to do is if someone’s dangling onto the old’s subscription, let it go. But when they check out again, give them a new subscription. If their billing fails and we’re asking them in the update, ideally don’t have them update the old subscription, have them check out again for the new one.
[00:02:54] Kim Coleman: So intercept the “your payment couldn’t be processed” email, and instead of sending that send a new type of message. Or send a link to the new checkout page. Filter the contents of the “payment method failed, click here to update your billing information”, to actually be like a checkout.
At that point they’re already in this dunning stage, they’re already expired. So them completing a new checkout at that point with the new gateway, isn’t bad. It’s a good thing.
[00:03:21] Jason Coleman: We could redirect them. In some cases, when you say “update billing” and we can’t, let’s redirect them to the checkout page.
[00:03:29] Kim Coleman: For the same level.
[00:03:31] Jason Coleman: The problem is that update billing. It says Hey, just update the credit card and leave the subscription alone. Checkout has all this stuff: is it the old price then if you check out again and it’s going to by default be the new price, correct. And maybe they’re supposed to be locked into their old pricing, or when you check out again, proration is going to come into account, it’s going to try so hard to know what people intend.
When they’re checking out. Oftentimes you could get five smart humans and three out of five of them would agree on what’s supposed to happen to this user when they check out.
[00:04:01] Kim Coleman: So Jason has established that this is not a problem that five smart humans will have consensus about. Oh, yeah.
We could disable the payment method. Expiring soon email, we could disable the payment method failed.
What helps is what you said, if we just let them, the payment failed, let their subscription cancel. And then they get the Hey, your subscription cancelled. Tabula rasa.
Because at that point, a new checkout isn’t a loss so don’t send the payment information expiring soon message when you will be taking them to a page that looks like this. Yeah, that looks like, okay, well, you can’t actually do anything about this.
[00:04:41] Jason Coleman: The thing is we don’t the software doesn’t know what’s an old gateway. It just knows it’s not the main one. Sometimes you have multiple gateway options. There’s onsite and offsite. You usually only want one on-site.
[00:04:52] Kim Coleman: If you checked out for an onsite type payment method, that was credit card based, and the current gateway…
[00:04:59] Jason Coleman: If it was a credit card and it’s not the main gateway, you should not send the update billing.
[00:05:06] Kim Coleman: And not only not send the update billing information email, but also don’t show the link to the update billing page from the membership account page people and perhaps improve the message here.
[00:05:18] Jason Coleman: Sometimes we get clever and we hide this because we know it’s not supposed to be there and then people are like, wait, I know there was an update billing there before, and now it’s not there. Where did it go? Yeah. And then that’s why it’s good to have it, even though it’s not functional and then show a message saying: this isn’t functional for this reason.
There’s a really weird edge case too with Stripe this a thing where in the API you say the app that is making this subscription is Paid Memberships Pro. That’s a new feature. I don’t know exactly when they added it. We started using it in December. One of our customers had an issue where now Stripe, when they’re trying to update billing, we say, Hey Paid Memberships Pro is updating the subscription and they say, oh, no, no, no. Some third party user management system created the subscription to start with. We help them import their subscriptions into PMPro. But now you try to update the billing and Stripe says, I’m not going to let you update that because that’s not the same application.
Why did it start happening now when we start passing up ID, but also it may be, it’s just Stripe decided to implement that implement as a feature. Yeah, of course, why let different apps edit the subscription, but the app. Is, this is like a tangent, but it’s related that there’s other reasons that the update billing page fails. This is what we’re trying to, cause this is a similar thing we’re saying like, Hey, you know, which customer signed up on the old platform because it was before a certain date. Show those customers a message. Hey, if you were imported over from the old system, you need to checkout instead of update billing.
Some way to detect and filter or let site owners in a setting or code say this is an old gateway.
And if it’s an old gateway and it used a credit card. An onsite versus offsite is just a soft designation on the gateway. There’s not a piece of code saying this is onsite. No. But we can kind of assume. Hey, if you’re switching from Braintree to Stripe, you don’t want to have those as two options at the same time.
Maybe different countries have. Sometimes different country, like Stripe doesn’t support this so I use onsite.
[00:07:08] Kim Coleman: The longest road to resolving this, which is a medium level of goodness is like you said, if we still know that the gateway credentials are present in the database. Try it right. Yeah, I think this is Authorize.net. We’re currently on Stripe as our active gateway, why not try it.
[00:07:28] Jason Coleman: We want people to probably check out again instead though so they get on the new system. The site owners should make that decision. So then in our article about switching gateways like, here’s a bit of custom code or here’s the hidden setting you gotta go click. I don’t want people using this gateway anymore. Yeah.
[00:07:44] Kim Coleman: That could be as simple as erase the gateway credentials.
[00:07:48] Jason Coleman: It is though. For recurring orders. It depends on the gateway. As soon as we get a message saying this is PayPal and a thousand dollars was charged, the first thing the gateway IPN and webhook handlers does is: is this real? And it sends a message back to Stripe. It says: this is real. You have to have the APIs to do that. So you can’t get rid of the API credentials. You want to have it, but. But we do want to detect that situation.
Hey, don’t let them check out again or don’t let them update, but instead of update billing, switch to checkout. So I think that’s it. This is probably why we didn’t code it. It’s not even worth programming, find the old gateway API and update the billing because people probably don’t want to do that anyway.
So instead we should detect that situation and get them to check out again after their membership expired.
[00:08:28] Kim Coleman: I also think, because we don’t already support that, by adding that back in, it would cause more confusion. This code has been live for a long time. So anyone who has done a gateway switch doesn’t expect that billing information can be updated. So if we add that now that’s going back on what decision we already made. People expect that it doesn’t work or they’ve experienced that it doesn’t work and our goal is to improve the user experience. And build upon a decision we already made.
[00:08:56] Jason Coleman: When people try to update billing the redirect to checkout and have them checkout, we should list all the problems with that potential problems and then try to make a list of solve those cause those are things that we kind of want to solve anyway. It’s hard. Some of that needs like more direction from the site. What do you intend in this situation? Like the ‘legacy’ are people locked in or not could be somehow. There’s a lot of these cases where like importing from another site. Changing your gateway. Doing some other kind of system change. Changing from Mailchimp to ConvertKit. It doesn’t just work anymore. You know, like the system is confused and it’s handling two different sets of users. The default decision isn’t always clear.
But the big one would be if you have a recurring level and you check out early for a recurring people kind of intend figure out when the next payment date was and then extend their membership from that date. And keep it going. And I feel like we have code that does that, or in certain situations we get it right. And some other situations, we get it wrong.
[00:09:49] Kim Coleman: Set up their subscription, charge them $0 today and set the delay for the sub to start on the next payment date.
[00:09:58] Jason Coleman: We could at least probably build a gist that says, if we do a redirect to checkout, redirect to checkout, and it’s going to kind of break, it’s not going to work how people really want it. And they’ll be like, Hey, it doesn’t really work. We could maybe that redirect to checkout could set a parameter or a flag saying this is a special old user checking out, from an old gateway to a new gateway and this custom code could check for that flag and in this situation what I want to do is find out what they paid. Update the pricing. Yeah. And make sure that we start on their old payment date.
Subs table fixes this.
[00:10:29] Kim Coleman: It makes it easier, but it doesn’t fix it.
[00:10:30] Jason Coleman: We don’t keep track of the next payment date. We either ask the gateway: what was the next payment date? Or we guess. Well, you checked out on the fifth, there’s an order and you said it was monthly, so I’m assuming the next one’s coming on the fifth of next month. But it’s not always the case. Maybe you tweak the subscription at the gateway, or maybe there’s some kind of custom trial built in, or maybe your IPN handler wasn’t really working so we haven’t been getting your orders, but then you fixed it and now we’re getting orders and some of them were backlogged, so there’s gaps.
We can’t guess it correctly. The subs table says we’re going to actually ask the gateway and keep it in sync. And we’ll always have a better guest basically. I mean, there’s still will be. You know, ways to fool it. But if we know what their next payment date is, then you can reliably say, oh, give them a trial until the next payment date. It’s a thing that you can write in code and know with 99% certainty, not 80% certainty, that it’s actually going to work how you want it to.
That’s why we don’t do this.
[00:11:27] Kim Coleman: There’s no straightforward answer. I like the idea of not sending the “update your payment method” email. We could also, if that flag was set, ignore old gateways, we could also cancel immediately.
[00:11:42] Jason Coleman: If a payment fails, cancel and have them check out again as a decent option for a lot of sites. Sometimes it’s a little aggressive. There’s a reason we have uptake billing code, but, it kind of simplifies. They fail the payment, I’m gonna assume they’re not in. But if you do that only for certain gateways, you’re kind of minimizing the downside of being that aggressive with your canceling.
[00:11:59] Kim Coleman: But isn’t that the same as just setting everyone’s accounts to cancel on the day, they would have re-processed.
[00:12:06] Jason Coleman: But some some people will pay for eight months and then get cancelled. It won’t just get canceled at once.
[00:12:12] Kim Coleman: We’re just gonna keep taking your money until your credit card is about to expire. We can’t take anymore. And then we can’t take your money anymore so we’ll stop.
[00:12:18] Jason Coleman: We need permission again to check out.
[00:12:20] Kim Coleman: That’s not bad.
[00:12:21] Jason Coleman: I think we could write some things down to get done and… we probably can detect that situation, disable the billing failed email. Then their subscription will be canceled and then will get caught by the “Hey, your subscription cancelled. You want to sign back up?
[00:12:35] Kim Coleman: So the code in core would say: This is an old gateway. The payment failed once. Expire and cancel immediately.
[00:12:44] Jason Coleman: Probably make it cancel too. And then they’ll get to cancellled the email.
So the only case actually is the payment failed. So it usually is on the date their subscriptions should be over if the payment failed. We don’t send them the update billing. We cancel them immediately. They get a ” your membership was canceled.” They’re going to be redirected to check out again. And then maybe they want to get the old pricing. Here’s a list of articles about how to program that. We have code like this. There’s a grace period. Let them have the old price. But the thing is that has to be custom code because it has no idea how your website set up. It doesn’t know how many membership levels you have or what the pricing was or.
[00:13:17] Kim Coleman: Thanks for talking this through with me. I hope it illustrates to people who listen that product decisions are complicated when you have no control over how people are using your system and how long they’ve been using it. And that you need to account for obvious use cases, but also edge cases. Great. Thanks.