Bugs & Feature Requests
Gateways, Merchant Accounts, Bank Accounts, Oh My!
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
Putting checkout form on my site
edited December 2009
If put the HTML for the checkout form on my SSL secured site, or just "submitted" the form via cURL from my SSL secured site, would that be a violation of the ToS, and/or represent a security risk?
Blocka, though it's possible you might get that to work, it's definitely not recommended. It might propose a security risk, depending on how you're manging the data and what you're doing with failed transaction attempts. There is a lot of behind the scenes stuff going on between the cart and checkout pages in order for all of the FoxyCart functionality to work correctly and some of that functionality changes from version to version. One of the main selling points of FoxyCart is that our caching system makes it very easy to keep your checkout page looking exactly as you want it, even though we're a hosted solution.
What limitations are you running into that would lead you in this direction?
The caching system is actually the
problem...I can't have dynamic content anymore, because its all been cached.
Aside from that, what I'm trying to do is a whitelabel solution for what we offer. In essence, we are selling a solution for hosting live interactive events. Some events will require payment to view, this is where foxycart comes into question.
We want to expose this all through an API. The consumer would request a live event via the API, and if the current user has permissions to see it, they will get back a link to a SWF file for that event, which can be embedded on a third party site.
Now if we wanted a consumer to charge for these events as well, the situation becomes sticky. We store all the information about who has access to which events on our side, and the only way to gain access is to go through the foxycart checkout form, which will in turn update our database via the XML Feed.
The problem is these third party sites want to customize the way the checkout looks. I don't think it makes sense to create a store for everybody. Plus they shouldn't need to mess around with foxycart at all...all they would want is to display a checkout form.
I thought the best way would be where I could extract the checkout form HTML, and say "use this code on your site" or something like that. Or event better, have them submit the request to a script on our server which would reroute the request via cURL to foxycart, thus providing a makeshift "API" for them to use.
I'm not sure what you mean stuff going on behind the scenes of the cart and the checkout...this is from checkout and onward, it doesn't involve the cart. The idea would be a server side script which would scrape the form off of a url like this:
, effectively "filling the cart".
Maybe if we had an API to do checkouts, that would be a much more straightforward approach.
It sounds like you need multiple template sets (which is on our request list). Other than that, what dynamic data would you need on the checkout page?
Based on what you're describing, FoxyCart may not be the right solution for you. You may want to look into just integrating with a payment gateway yourself directly and not use FoxyCart since it sounds like you're going to have your own system already for managing the different live event systems, the different checkout pages and the management for the different event details.
I think what I need foxycart for is for PCI compliance really. As you guys know, it is way too expensive to become PCI compliant for a small company, and we would like to store CC information for return customers or for subscriptions. Integrating with a gateway means that we have to be PCI compliant. The other choice that I know of is a service called braintree which stores CC information in their db, and gives you a token which you can reference, but its also a very expensive service. Foxycart was the cheapest way that I have found to handle this kind of stuff for us.
We're not really using it for the cart, only to abstract away the gory details of payment, and to store CC numbers.
The dynamic stuff we would want to display would be the usual dynamic stuff on our site (welcome so and so!, dynamic sidebars, etc.), which we could of course ditch for the checkout page.
As for our whitelabel requirements, I think the best way for us to handle it is to just give them an API call to assign an event as being payed for by a user, and to have them work out the details of how they want to accept payment (I can of course refer them to foxycart).
: Luke and I have gone back and forth on this, but I (personally; Luke's coming around
am _very_ keen on adding the functionality you're describing (checkout as an API type of system).
More details coming privately.