to something like https://checkout.stripe.com/v2/checkout.js is like night and day. JS vs. compiled CoffeeScript. One large, monolithic file vs. obviously concatenated files. Variable naming, commenting, etc.
It's interesting -- I wonder what kind of code style guidelines they have over there, if any.
We have a mostly per-project set of code style and tooling guidelines. Most (if not all) of our larger projects are coffeescript and commonjs based. That's mostly because they all share at least some code. As long as a project is internally consistent and the team agrees with each other, we don't force any specific styles or tools (within reason). We have expertise with the tools we use the most though, so a lot of times the best fit is our own tools.
However, the comparison is a little bit apples and oranges. The JavaScript is optimized for reading, and maximum coherence by outside developers (an example), and the other is a compiled application for execution. The actual _source_ of the checkout project (which is not open-sourced) internally is broken up into neat files and uses modules, etc. It's quite readable for those working on the code, and the output there is generated by a computer and not really intended for humans.
Hope that helps give some insight into our process and reasoning.
Which one is compiled CoffeeScript? The second one? I went to a Node 0.10.0 talk [1] at AirBnB and Isaac Schluetter had some pretty funny comments for people programming in CoffeeScript.
Is it possible to take payments using Stripe without having to ask for or provide the billing address with the transaction?
I'm looking at the docs right now and it says the "address" field is optional... But how could that o.k. the transaction without the validation process (fraud check) comparing the CC's billing address (from the card network) against what the buyer supplied?
The reason I'm asking is I sell software and the billing/shipping address is useless to me.
Yes, you can charge people without the address field. You still need the CVV code for fraud protection.
I read somewhere that credit card companies charge lower rates if the address is provided as well. If that's the case, it seems like Stripe normalizes the price for you.
With the store, you are asked for email and CC info first.
With the demo, you are asked for email and address info first.
It would be interesting to see which info entered gets the user to commit to the transaction better... That is, which one makes he/she less likely to back out; or more likely to start it.
I had been hearing some rumors that this was going to be the new version of checkout.js, but this is actually better. I like it, thanks for open sourcing!
[+] [-] sync|12 years ago|reply
to something like https://checkout.stripe.com/v2/checkout.js is like night and day. JS vs. compiled CoffeeScript. One large, monolithic file vs. obviously concatenated files. Variable naming, commenting, etc.
It's interesting -- I wonder what kind of code style guidelines they have over there, if any.
[+] [-] slexaxton|12 years ago|reply
We have a mostly per-project set of code style and tooling guidelines. Most (if not all) of our larger projects are coffeescript and commonjs based. That's mostly because they all share at least some code. As long as a project is internally consistent and the team agrees with each other, we don't force any specific styles or tools (within reason). We have expertise with the tools we use the most though, so a lot of times the best fit is our own tools.
However, the comparison is a little bit apples and oranges. The JavaScript is optimized for reading, and maximum coherence by outside developers (an example), and the other is a compiled application for execution. The actual _source_ of the checkout project (which is not open-sourced) internally is broken up into neat files and uses modules, etc. It's quite readable for those working on the code, and the output there is generated by a computer and not really intended for humans.
Hope that helps give some insight into our process and reasoning.
[+] [-] joeblau|12 years ago|reply
[1] - http://www.youtube.com/watch?v=zM-gUM9C5SA&t=2770
[+] [-] joeblau|12 years ago|reply
[+] [-] powertower|12 years ago|reply
I'm looking at the docs right now and it says the "address" field is optional... But how could that o.k. the transaction without the validation process (fraud check) comparing the CC's billing address (from the card network) against what the buyer supplied?
The reason I'm asking is I sell software and the billing/shipping address is useless to me.
[+] [-] jhuckestein|12 years ago|reply
I read somewhere that credit card companies charge lower rates if the address is provided as well. If that's the case, it seems like Stripe normalizes the price for you.
[+] [-] pbiggar|12 years ago|reply
[+] [-] themgt|12 years ago|reply
[+] [-] e12e|12 years ago|reply
I wonder if it would make sense to port this to deployd and/or helios?
I thought google app engine looked a lot more interesting when I learned of appscale -- I'd love for there to be something similar for parse.com.
Side note: deployd looks nice, although I don't think I'll be using mongodb for my projects any time soon.
[+] [-] mattschmulen|12 years ago|reply
[+] [-] powertower|12 years ago|reply
With the demo, you are asked for email and address info first.
It would be interesting to see which info entered gets the user to commit to the transaction better... That is, which one makes he/she less likely to back out; or more likely to start it.
[+] [-] callmeed|12 years ago|reply
https://github.com/2tablespoons/thylacine
[+] [-] zrail|12 years ago|reply
[+] [-] reustle|12 years ago|reply
[+] [-] hunvreus|12 years ago|reply
[+] [-] alaskamiller|12 years ago|reply
Link this up with https://www.shirts.io and you get an instant t-shirt shop with no hassles.
[+] [-] Killswitch|12 years ago|reply
[+] [-] AwesomeTogether|12 years ago|reply