Importing existing members w/ recurring subscriptions, but changing payment gateway

Hi!

Longtime Wordpress developer here, but my first time playing around with s2Member. I’m currently working on a migration for a client from a RainMaker site to a self-hosted WP site running s2Member. I wrote a script to translate the RainMaker subscriber export CSV into something that s2Member could understand, and my import went off without a hitch… for the most part. I can see all of my members, their subscriber levels, EOT’s, etc. on my new WP site.

Here’s my problem, though… my client was using Stripe as a payment gateway on RainMaker, and wants to transition to using Authorize.net on his new WordPress site. Apparently they have a more favorable fee structure. So… the Stripe transaction/subscription IDs that I have from the RainMaker subscriber export don’t line up with anything when importing to the WordPress/S2/Authorize.net solution. Which, as I have found out, means that when I login as an imported user, and go to modify my payment details, it tells me that I’m “not a paying subscriber”.

Any thoughts on how to fix this, without forcing everybody to re-subscribe come the end of their term? What I envisioned was something like this…

  1. EOT date is set, so the user gets an EOT e-mail a few days before the end of their subscription, and is prompted to re-enter their payment details (as we obviously don’t have them for the new site/Authorize.net)
  2. User is now auto-billed based on their current member-level (which we deduced from their group/product when importing from Rainmaker).
  3. Now that the user’s information is in the system, ARB works as it should.

Am I crazy here? It seems like there should be a way to to this, but I can’t seem to get past s2Member not recognizing that members aren’t “paid” because it’s lacking a transaction/subscriptions ID.

Any help is greatly appreciated.

Thanks in advance!

Dan

Not being able to pass members’ details from one payment processor to another is not really s2Member’s problem. It’s a security and privacy issue.

In order to change payment processor successfully, the member must reach EOT with the original payment processor. So your method seems to deal with the issue, but I can’t really see how it’s an improvement over just getting members to complete a Billing Modification form once they have reached EOT. That is the regular way of handling this.

Thanks for the reply!

And yea… that solution came to me about an hour after I posted my question to the forums (sending an EOT mail a week or two before their term is up, and linking it to a billing modification form). But that’s how these things always go, right? Explaining the problem to someone else tends to kick-start the wheels turning…

Thanks again!

Dan

2 Likes

Absolutely! That happens to me all the time!