Different payment options based on user type

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.

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.

@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.

@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.

@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!