Simulate Update and Cancel links as on Emailed Receipt

dfosterhdfosterh Member
in Help edited January 2012
I'm creating a general account management landing page for our customers. I'd thought it would be trivial to simulate the 3 links included on standard emailed receipts, but have discovered the URLs to be a cryptic mash of salty hash (or something).

I don't see an obvious (or clever) way of putting the checkout page into the states I need. I'm about to go on a major kludgathon to screen-scrape the urls, but figured I'd ask/propose a better solution.

Also [BUG], on 7.2, I've noticed that once the Cancel url has been visited (but not submitted/finalized) the other urls enter cancel state as well. There appears to be a sticky cookie in the mix (IE 9, if it matters).
Comments
  • fc_adamfc_adam FoxyCart Team
    @dfosterh,

    Are you referring to the three URL's included in a subscription receipt? You'll need to have the sub_token parameter for the customers subscription for that, which you can get through the API and is also included with the initial transactions XML datafeed.

    Thanks for the bug report as well, we'll look into that and post back anything we find.
  • I am, but the very long hash on the URLs does not contain the related sub_token. It also seems to contain the state to put the checkout in (Update, Transfer, or Cancel).

    I would like to be able to do something like call the checkout page with the sub_toke and a param such as &action=cancel. Is it possible, and how do I construct the url/post?
  • sparkwebsparkweb Member, Integration Developer, FoxyShop, Order Desk
    The URL just looks like this:

    https://yourdomain.foxycart.com/cart?sub_token=SUB_TOKEN_HERE&cart=checkout&sub_cancel=true

    The update url is the same, except the sub_cancel param is not included.
  • And Transfer is the same as Update, right? Fantastic.

    Is this in the 7.2 documentation?
  • sparkwebsparkweb Member, Integration Developer, FoxyShop, Order Desk
    It's all here in the sub_token section: http://wiki.foxycart.com/v/0.7.2/products/subscriptions. I'm not sure about Transfer.
  • And so it is. OK, thanks.

    From what I can tell, following the email links to Transfer does result in the same behavior as from Update.
  • lukeluke FoxyCart Team
    Yeah, that's actually a bit confusing. There is an "updateinfo" action which can be used by any customer (not just a subscription customer). If you go to yourdomain.com/cart?cart=updateinfo it will bring up a checkout screen which will prompt the user to enter updated payment information. We use that link when we know a customer's card is about to expire.

    The sub_token "update" link is more about updating the subscription. You could, as an example, use that link along with our "redirect" parameter to send the customer back to your site to add something new (or remove something) from their subscription and then checkout which would "update" their subscription to include new products. During that process, they can also update their billing info if they want to, but it does not prompt them to do so.

    As for the "transfer" we added that (along with some notes on the checkout page) to make it clear that subscriptions can be transferred from one email address to another using the sub_token link.

    I hope that helps.
  • lukeluke FoxyCart Team
    As for the cancel link, that's part of how the system works. As soon as you load up that subscription in your cart and you tell the system you want to cancel it, it will remain there until you remove that product from the cart. I'm not sure there's another way around this. Do you have any suggestions?
  • I'm not sure we're talking about the same thing regarding the cancel behavior. Here's a use case:

    Customer...
    1. Clicks Cancel on their emailed receipt
    2. Reads the page and realizes that's not at all what they wanted to do
    3. Closes the browser
    4. Clicks Update on their emailed receipt
    5. Sorry buddy, you asked to cancel the last time, so cancel is the only option now?

    Clever Customer...
    1. Goes to another computer
    2. Clicks Update
    3. Can now update

    A. Customer should be able to change their mind and start over
    B. If not, state should be maintained somewhere other than the client to stop the clever customer
  • BTW, I got 1 email notification out of the last 3 replies to my posts. I just checked my settings, and it appears the default is for me to receive notifications. I've checked my junk mail. Am I the only one not being notified in this new forum system, or is there an issue?
  • lukeluke FoxyCart Team
    Thanks for clarifying, @dfosterh. I see what you mean if the link goes directly to the checkout (which the email receipt links do), there's no "remove from cart" option there. The simple answer is to add &empty=true to all those links. We'll update that on our side as well, but in the meantime, just modify that value in the language strings in the admin and you should be good to go. That will ensure the cart is emptied before the next action takes place.

    As for not being notified, this is a new forum install for us and we're still working through some kinks. Either yesterday or the day before we fixed the default notification settings to ensure people that start threads are notified on them. Notifications _should_ be working correctly now. Please let us know if they aren't.
  • I now seem to be getting notified. Sounds like the default was fixed in between the 3 posts I mentioned. I only checked the settings today, so they probably were defaulted differently before, as you indicate.

    I'm still not sure we're talking about the same thing regarding the cancel issue. You mention removing things from the cart/subscription, I'm talking, I think, about an entire subscription request state. Maybe the implementation of the request state is through cart items? Parlance; tomato tomato?

    In case it's not a matter of different ways of explaining the same thing, have you tried the customer steps I outlined? Do you see how the cart maintains a cancel-request state even after the request has changed to update?

    In any case, I'm off to test the cart-empty option. That may also be a work-around for my other question regarding password reset.
  • lukeluke FoxyCart Team
    Ah, shoot. I should have tested that out before recommending it. It appears the empty=true isn't taking place before the sub_token evaluation to get the right subscription. That's really surprising to me as it should empty the cart first before doing anything else. I'll look into this some more and get back to you.
  • lukeluke FoxyCart Team
    Ok, @dfosterh, try it now. We just pushed out a change to 072 that evaluates the empty=true first before evaluating the sub_token. We also updated the default language strings so the links in the email should just work correctly now.
  • All good. I can now alternate between both states using the links in the emailed receipt.
  • sparkwebsparkweb Member, Integration Developer, FoxyShop, Order Desk
    That's a great point. I'm going to make sure that empty=true is in all links that are being generated from my system as well. Thanks for bringing this up.
Sign In or Register to comment.