Buy now and recurring payments

I am experiencing issues when a member who has a Level 1 subscription (paid) with specific ccaps, happens to make a separate purchase through a Buy Now process (which would make them Level 1 (paid) with an additional ccap).

Sometimes, the Buy Now purchase will cause a cancellation of their recurring payment through Paypal. That is very unsettling as the members get the impression that I cancelled it. How can this be avoided?

My current set up is this one:

  • one click button for the recurring subscription to start - Level 1 + ccap
  • Buy Now is through a pro-form (since i need the option for a coupon) - Level 1 + ccap

Why would some members have their subscription cancelled when they make a one time purchase after? Why others are not experiencing the same issue?

Specifically, which Pro form are you using for this?

I use the Level 1 form because I want everyone to become Level 1 when they purchase.
I can’t use the Capability (Buy Now) form, because it is too convoluted:

  • if someone is not logged in, they have to log in before making a purchase
  • if someone is a free member, they can’t become a level 1 as the “*” will keep them at Level 0
  • if they have not registered before, they can’t buy as the “*” requires them to be logged in before

Any other simple alternative?

Well, that explains why a member’s current status is getting cancelled. That should actually happen every time; it is the intended behavior.

As to a better alternative, I don’t know of one off the top of my head. I’ll give it some thought.

I don’t see why the intended behavior would be to cancel a recurring payment for a Buy now. I can see one recurring payment cancelling and replacing one, but a buy now should be independent. If level 0 is for Free, everything Paid should be 1 or more. The problem is that a free registered member, using a Capability (Buy Now) form would stay at level 0, which is not logical either (BUY now cannot be associated with a Level 0, which is free).

A Buy Now form isn’t designed to add anything to anything. It simply institutes a purchase, and that’s it. So if the member already has an account, it will probably get overridden.

I’ve thought about this a little more, and need to ask you a couple of questions, Carole.

As I’m sure you realize, the problem with what you want to do is that, until the user enters some details, neither WordPress nor s2Member knows who that person is. So having a current member login first overcomes that, and then you can use a modification form.

Since that approach is not to your liking, it means that you are left with WP and s2Member having to recognize the user either by their username, or by their email or IP address when they attempt to buy a new form of access. So here are my questions:

  1. Which would you prefer that WP and s2Member use here: username, email address, or IP?
  2. Are you sure that these approaches aren’t worse than the current one?

The problems, as I currently see them, are that if you choose to go by username, the user might simply mis-remember that (or just use a different name), and so you’re back at square one. So going by email address looks better. But what if the user has more than one email address and inputs a different one from before? That’s no better than before.

And there’s another problem: a quite different user may innocently try the same username, or not-so-innocently try the email address. What then?

These problems maybe make tracking by IP sound good but, if the user has a mobile device, then that won’t work either.

So, if I’m right, you’re probably going to need two-factor authentication to make this work. So I suggest that that’s what you need to look at first.

The one “solution” i know of is to have a three-way conditional for displaying 3 different pro-forms:

  • display one form if the user is not logged in (no idea if they have subscribed before, or paid or not)
  • display one form if the user is logged in with Level 0 (free subscriber)
  • display one form if the user is logged in with Level 1 or more (paid subscriber)

Yes, i can do that, but i am depending on the registered users to log in before filling the form, as the one that would be displayed when logged out, is NOT for them to be filled (exactly for the reasons you mention, of the risk of mistyping).

So yes, there IS a solution, but it is convoluted AND dependent on the visitor having to log in when they should (unfortunately, we know people don’t always read instructions, which would also lead to a risk of mistype and having the ccap not be associated with the account).

Yes, without two-factor authentication, I don’t see what else you can do apart from putting up a warning in large type urging those who already have an account to login first before buying anything new.

The only other thing I can think of would be, in cases where someone attempts to use a username or email address that’s already taken, to generate a message asking them whether they already have an account and, if so, urging that they log in.

Apart from that, I don’t see what else Jason or anyone else can do to make this any less convoluted.

This is the approach I use on client sites: modifying the error message displayed when a user enters an already existing email address or username.