[jordanlev]

2 questions: How does this compare to existing eCommerce back-ends like SnipCart, Ecwid, Foxycart?

And: I presume your service requires javascript to function (as all of the similar services do)... any chance of providing a non-javascript fallback such as a generic-looking checkout page hosted on your own servers (like when you use a paypal button to send users to their site to complete the final step of the transaction)? Please don't tell me that "everyone uses javascript yay" or that I shouldn't be concerned -- I know who my clients and their users are and I know what their accessibility requirements are :) (I always have to say this when I ask eCommerce services this question because usually they dismiss it out of hand and it's very frustrating when you have requirements that sites work even without javascript).

Thanks, and best of luck!

[AJSturrock]

Firstly we’ve looked at all of these options and as developers got pretty excited by their potential. The problem was that we found them to all be lacking in some degree, Snipcart is only for the most basic ecommerce, Ecwid is focused more on widgets, and Foxycart requires you to use their hosted checkout.

Secondly every member of our team has been in a position at some point in their working lives where we’ve had to build applications that support all manor of strange legacy requests. We completely understand.

Yes, if you use our javascript SDK with the API, you would require javascript for it to work. That said, you could take the backend approach and then there would be no issues with supporting older clients or applications as it would all be handled by the servers.

We have been thinking about adding a hosted checkout page for exactly the reason you describe. it would probably be an option so that you can either use a hosted checkout page quickly, or if you want more control you can use one of our SDKs and build your own checkout.

Thanks for wishing us luck!

[bikamonki]

Have you tried a proxy approach with node.js? I have done this twice already when using baas solutions.

[jHoldroyd]

We've had a few people doing that, and we'll be forking our JavaScript SDK to natively support Node in the next week or two.

[jordanlev]

I've never thought of this... do you have more details on how exactly you accomplish this?

[bikamonki]

When for reasons of security or server side logic we do not feel comfortable running code on the client, we run it on node and setup a simple API that mirrors the vendor's API. Say for example that you are using Firebase (we use this for a chat app) but do not want to expose keys or need to run some code on messages (validations, etc). It is not ideal b/c part of the reasons of using BAAS is to avoid maintaining a back-end component. Depending on your needs, some BAAS vendors offer a "server code" solution, for example Parse's Cloud Code, that way you still avoid setting up a back-end component on your own but still run validations. etc. Parse's in particular is well setup based on events (after or before you save an object). Incidentally, they too use node.

Naturally, for this approach, you need that the BAAS vendor offers a Node SDK (most do), or maybe some other stack (PHP, Rails, etc).

[thasmin]

The website has PHP and curl examples.

[jordanlev]

Ah, I see... so actually this is a big distinguishing factor that separates this from the other services I mentioned! Looking forward to playing around with this.

[jHoldroyd]

Great, if you need anything or have any feedback we're always available on livechat or [e-mail]