The Foxy forums are on the move!

We're in the process of moving our forums over to a new system, and so these forums are now read-only.
If you have a question about your store in the meantime, please don't hesitate to reach out to us via email.

Different payment options based on user type

sccr410sccr410 Member
in Help edited October 2012
A client of ours wants to allow the PO option, but only for specific types of users. We are using FoxyShop with WordPress at www.mytee.com

Users who are logged into the WordPress site are one type of user (distributors with special accounts on the site to give them access to extra info) and then standard users who do not login to anything on the WordPress site. Standard users can only order parts on the site and assume they are the end users of the products.

My initial idea was to setup two FoxyCart accounts for the two user types and based on that, we would use the appropriate FoxyCart URLs based on logged in/out when adding to cart. Then I realized the order data would be in two separate stores and FoxyShop cannot bring data from two stores into the WP admin.

So my next idea is if there is a way to tell FoxyCart, when going to the Checkout page, what type of user the person is via a URL variable and then be able to hide a PO option for non-Distributor accounts.
Comments
  • fc_adamfc_adam FoxyCart Team
    @sccr410,

    You could do this a number of ways. A simple way would be to set a hidden session variable on every page load specifying whether the customer is logged in or not. Then on your checkout, check that variable in the fc_json object and display the appropriate payment methods as required.
  • sparkwebsparkweb Member, Integration Developer, FoxyShop, Order Desk
    Yup... I'd recommend setting this on your single product template - just another hidden input inside the form as something like:
    <input type="hidden" name="h:user_type" value="SOME CODE TO PULL THE CURRENT USER ROLE">
    

    Note that you should not add verification hashes to session variables.

    @fc_adam - I noticed recently that it seems like once set, a session variable doesn't get reset when you pass something else in. Is that correct?

    Then in the checkout you'd just check the fc_json object and if the session variable for user_type == "something" you'd hide the PO option.
  • fc_adamfc_adam FoxyCart Team
    @sparkweb, are you seeing that in just a specific version of FoxyCart, or any version?
  • Worked like a charm, thank you guys
  • sparkwebsparkweb Member, Integration Developer, FoxyShop, Order Desk
    @fc_adam, I just tried it again on a traditional product and I didn't have a problem this time. I did have trouble resetting it last week, though, in this scenario:

    Before checkout, redirect to my SSO intermediate page.
    On this page, after submit, add a product to the cart via cURL and include the h:my_shipping info.
    This works fine, but if I go back and go through the process again (remove the added product from the cart and then adds a new one with a new h:my_shipping value, the old h:my_shipping value is still there in the checkout.

    Now I found a workaround by just posting the info to the querystring which isn't quite as secure. I didn't really extensively test this so it isn't a very thorough bug report, but this was the experience I ran into.
  • fc_adamfc_adam FoxyCart Team
    @sparkweb,

    Interesting. There shouldn't be any difference between submitting it to the cart via cURL or doing it via a normal add to cart. Thanks for the details though!
  • lukeluke FoxyCart Team
    @sparkweb: I've been looking through the code and I haven't been able to pin down anything that would explain this. Do you have a test page up to reproduce this? Seems very odd. The hidden (h:) values are stored in the session. As long as the session is working, it should work correctly, I think.
  • sparkwebsparkweb Member, Integration Developer, FoxyShop, Order Desk
    @luke, so this prompted me to go back and try this again and I found that I hadn't been properly urlencoding so they were silently failing when I thought it just wasn't updating. All is well. Crisis averted. False alarm. Thanks!
  • fc_adamfc_adam FoxyCart Team
    @sparkweb,

    Thanks for the update!
Sign In or Register to comment.