We’ve recently come across what seems to be a bit of a glitch with our web source codes when we offer presales or special web discounts and I’m curious if anyone has experienced something similar.
The majority of orders are recording the proper source code based on the promotion code that is entered on the site, but a small handful are tracing back with the generic web source. Obviously the patron has been able to log in and has used the proper promotion code, as they’ve bought tickets during the presale or at the discounted price. We’ve tried logging in and entering the promotion codes in every way that we can think possible, and can not seem to replicate the issue. It isn’t a huge issue, as it is usually only a small number with each promotion, but it’s quite baffling at the same time.
So if anyone can offer any insight it would be very much appreciated.
Thanks,
Karyn
On our site, it appears you can enter a promotion code when reserving tickets (before logging in). If the customer does not log in prior to reserving tickets but enters a promo code to trigger discount pricing, your web code is still logging them (behind the scenes) but as an anonymous shopper by calling LoginWithPromoCode and passing through the anonymous user login information + the promo code. In order to retain this source number when the real customer logs in later, your web code needs to call LoginWithPromoCode a second time and should ALSO pass in the promo code here as well. If the promo code is not entered with the real customer login, it will revert to the default source_no.
The following method sequence should be used by your web application:
GetNewSessionKey
LoginWithPromoCode (anonymous user is logged in + promo code)
ReserveTickets
LoginWithPromoCode (real customer is logged in + promo code)
TransferCart
Sabina... you've definitely pointed us in the right direction!
Thank you both for the quick responses.
Bumping this post up...SOLUTION!!!! This may not work for everyone who is experiencing this problem, but I hope it helps.
We have been plagued with orders via the web that have the general web source code instead of the source code ties to the offer. It had been impossible to replicate online and had been a high priority research project for about a year now.
Here is the lovely solution from Lynch2:
We looked into Sabina’s suggestion that we might have been losing the source number on the transition from the anonymous login to the real-user login. However, we already had existing code that, when a source code (promo code) isn’t specified by the user, fetches the source code from the GetCart API call and passes the source code to LoginWithPromoCode.
After testing and ruling out that issue, we wondered if there would be a reason that getting the current source code would be impossible. When we deliberately entered an incorrect password, we found that the two ways to get to the source code—the LoginInfo and GetCart API calls—only work with a validated session. A validated session appears to be one that is validated through the anonymous user credentials, or through a real user’s credentials.
When a user enters an incorrect password, the session becomes invalidated. GetCart returns an exception, while LoginInfo returns only the business unit associated with the session key passed into the API call. (The session doesn’t actually expire; if you successfully log in after this point, you’ll be able to fetch results from GetCart with the same session key you used at the beginning of the process.)
If the user remembers the correct password and utilizes it to log in at this point, our web code doesn’t know to log them in with the promotional source code, since we can’t look at a GetCart response to determine what that source code is.
With TPAC, we ended up storing the promo code’s numeric source code in a session variable on the web code side. This only happens when the user enters a promo code. For their site, promo codes are entered by the patron only on the performance detail pages, not as a separate field during login. So whenever we display a login page, we can also include a hidden field that passes along this saved source code into the LoginWithPromoCode API call.
Further testing on TPAC’s end revealed one more case – what happens if a patron uses a “Forgot Password” token? Tokens don’t have source code information automatically attached to them, so we wouldn’t have a source code to pass in with the login information. Fortunately, we still have the source code in a session variable on the web code side, so we can include the source code in the LoginEx2 call.
As long as the patron doesn’t start a new session, we’ll have the source code on hand for every relevant login screen. And if they do, they lose the contents in their cart and have to start over from the beginning anyway.