Temporary Logins

I'll be the contrarian here.  We used to do this, both with a nightly job and a procedure running in LP_CUSTOMER_RANK, but have stopped.  I think you really want to think through your use case.  In our case the only significant outcome of creating the logins was that we had numerous cases of customers trying to buy tickets in TNEW, going to register a new account, and then being denied with a (PCI-mandated) cryptic message because a login already existed.  Whatever we tried to do to massage the messaging, people read "You Can't Register Because Reasons" and gave up or became angry.

Gawain Lavers So, the issue we're looking to solve is that we have a LOT of people that have Guest logins and when they have tried to log back in to them (for digital content or what have you) they can't, they hit forgot password and never get anything b/c it's a Guest login. SO, my thinking is that, for anyone that only has a guest login (which we're going to do away with b/c of this exact scenario), I could tweak this to create a temporary web login that they'd be able to access. We're also going to attempt to begin training our donors and subscribers to log in to unlock their discounts rather than give them a promo code, so we need them to hit their actual record so that pricing rules and such will work for them, rather than creating new accounts that wouldn't unlock said discounts. It's definitely going to take some education, but making sure they can actually hit the right account is going to be a big step.

Yeah that makes a lot of sense: we had to turn off Guest Checkout when we ran our digital season last year.  We're hoping a way to control Guest Checkout based on products in the cart is coming soon.  Also, a tool for "converting" a Guest login to a full login, based on email address would be helpful.  One could then include a link to it as Dynamic Email Content for confirmation emails containing Digital Content (or Memberships, or whatever).

Ooh....that's a very sexy solution. Love it! But, hoping this will get us there for now. 

Gawain Lavers,

Not saying that it is the greatest solution in the history of solutions, but it works extremely well, and, since implementation, we have not had a single issue with Guest Checkout; we implemented a cookie-based solution for this.  The breakdown of how it works is this:

• Whenever the cart page is loaded, a custom procedure is called by JavaScript which returns the performance numbers of any active gated content events (that is, which would require logging in to access; we do have some free livestream events which do not require that).
  • This is done simply by checking actively on sale performances against a specific "Gated Content" keyword.
• The JavaScript then looks at all the performances in the cart to verify whether or not any of those performances are in the cart.
• If present, it applies a cookie called "IsGatedContent" with the value of "Yes", if not, the value of "No".
• Every time the cart is loaded, that runs and will update the cookie when necessary.
• When the checkout button is pressed, it then checks for the status of that cookie; when the value is "Yes", it disables that button and changes the messaging to alert the patron to the fact that Guest Checkout is unavailable due to their particular cart items.
  • If someone was already logged in, they of course skip the "login" page, so that logic is never run, but of course, they are already logged into an account anyway, rendering the logic moot.
  • The extreme example of an exception is someone who put a non-gated content item into their cart, clicked checkout, created a Guest Account, then went back and added a Gated Content item and then went back to check out is both extremely unlikely for our business case and as well, I created a checkout customization which then disables checkout in that case; so no worries there either.

Just in case that assists you at all.

John

Gawain Lavers,

Not saying that it is the greatest solution in the history of solutions, but it works extremely well, and, since implementation, we have not had a single issue with Guest Checkout; we implemented a cookie-based solution for this.  The breakdown of how it works is this:

• Whenever the cart page is loaded, a custom procedure is called by JavaScript which returns the performance numbers of any active gated content events (that is, which would require logging in to access; we do have some free livestream events which do not require that).
  • This is done simply by checking actively on sale performances against a specific "Gated Content" keyword.
• The JavaScript then looks at all the performances in the cart to verify whether or not any of those performances are in the cart.
• If present, it applies a cookie called "IsGatedContent" with the value of "Yes", if not, the value of "No".
• Every time the cart is loaded, that runs and will update the cookie when necessary.
• When the checkout button is pressed, it then checks for the status of that cookie; when the value is "Yes", it disables that button and changes the messaging to alert the patron to the fact that Guest Checkout is unavailable due to their particular cart items.
  • If someone was already logged in, they of course skip the "login" page, so that logic is never run, but of course, they are already logged into an account anyway, rendering the logic moot.
  • The extreme example of an exception is someone who put a non-gated content item into their cart, clicked checkout, created a Guest Account, then went back and added a Gated Content item and then went back to check out is both extremely unlikely for our business case and as well, I created a checkout customization which then disables checkout in that case; so no worries there either.

Just in case that assists you at all.

John