4 ms·

Open-Sourcing Stripe Shop

104 points by DanielRibeiro 13y ago

sync 13y ago
Comparing this code ( e.g. https://github.com/stripe/shop/blob/master/public/assets/js/shop.js https://github.com/stripe/shop/blob/master/public/assets/js/... ) to something like https://checkout.stripe.com/v2/checkout.js 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.
- joeblau 13y ago
  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. [1] - http://www.youtube.com/watch?v=zM-gUM9C5SA&t=2770 http://www.youtube.com/watch?v=zM-gUM9C5SA&t=2770
  - deleted 13y ago
    [deleted]
  - rcsorensen 13y ago
    Bullet points of the CoffeeScript comments: * People don't compile to JS before publishing to NPM, making it harder to use CoffeeScript written modules. * I don't know CoffeeScript, so it's harder to debug. * The language is bad, introduces things from Ruby he doesn't like, there are ambiguities introduced. When asked about ambiguities introduced, there was a reference to a "different require implementation in CoffeeScript", which has possibly since been fixed.
    - deleted 13y ago
      [deleted]
- slexaxton 13y ago
  Hi, Stripe Developer here. 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.
  - rcsorensen 13y ago
    What are you using to stitch the modules together? Stitch, browserify, grunt/grunt-contrib and friends, something home grown?
    - slexaxton 13y ago
      This varies from project to project based on needs. The checkout stuff uses sprockets-commonjs, browserify and require.js are used in other projects though. The decision is often made based on the backend (is it already ruby/sprockets?), and the needs of the project (would rebuilding the full file on each change be prohibitive). For the most part though, the build system remains transparent to all but one person (me, these days).
  - e12e 13y ago
    Any plans for open sourcing the source, as well? Why/Why not?
    - slexaxton 13y ago
      Many important parts of checkout are open-sourced via our jQuery.payment plugin [1]. It allows you to build your own checkout flow from component parts. As for open sourcing (capital C) Checkout entirely, we're working hard to provide a high-touch, consistent experience for checking out and we haven't been able to reconcile that with a bunch of small (maybe less thought-out) variations on the same thing floating around. We're always trying to think about ways to make this stuff better, though. We're definitely not against the idea, we just wanna do it right (i.e. allow non-programmers to customize without making things work incorrectly or look bad). 1. https://github.com/stripe/jquery.payment https://github.com/stripe/jquery.payment
joeblau 13y ago
I just got my Stripe shirt last week :). Thanks for open sourcing this. I needed something simple like this for selling tickets.
zrail 13y ago
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!
AwesomeTogether 13y ago
gee. i thought you had to use a javascript framework to build an spa.
alaskamiller 13y ago
Man, so Stripe just makes payments so easy. Link this up with https://www.shirts.io https://www.shirts.io and you get an instant t-shirt shop with no hassles.
- Killswitch 13y ago
  Yeah man, these dev friendly API companies are awesome. Stripe, Shirts.io, EasyPost (https://www.easypost.com https://www.easypost.com) Loving them all.
themgt 13y ago
Well, now all we need is an open source Parse-compatible server.
- e12e 13y ago
  My thoughts exactly. I looked at the code, the demo, and then: Ok, so how can I self-host this? 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 13y ago
  hey, thats a good idea ! actually a great idea ...
callmeed 13y ago
It hasn't been updated in a while (and isn't as pretty), but I have an open-source shop for selling a digital good with Stripe: https://github.com/2tablespoons/thylacine https://github.com/2tablespoons/thylacine
powertower 13y ago
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.
powertower 13y ago
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.
- pbiggar 13y ago
  Yes, you can. You also don't need their card name or CVV.
- jhuckestein 13y ago
  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.
  - simonk 13y ago
    Nope, Stripe doesn't require the CVV either.
    - Killswitch 13y ago
      It's optional but highly recommended. I've spent a lot of time in the Stripe docs over the last couple weeks building my new project integrating Stripe.
hunvreus 13y ago
I have to ask: is that a 草泥马 wearing that shirt?
reustle 13y ago
This seems to be a response to Shopify POS being released and now they are both creeping closer and closer to each other.

104 points by DanielRibeiro 13y ago

sync 13y ago

Comparing this code ( e.g. https://github.com/stripe/shop/blob/master/public/assets/js/shop.js https://github.com/stripe/shop/blob/master/public/assets/js/... ) to something like https://checkout.stripe.com/v2/checkout.js 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.

joeblau 13y ago
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. [1] - http://www.youtube.com/watch?v=zM-gUM9C5SA&t=2770 http://www.youtube.com/watch?v=zM-gUM9C5SA&t=2770
- deleted 13y ago
  [deleted]
- rcsorensen 13y ago
  Bullet points of the CoffeeScript comments: * People don't compile to JS before publishing to NPM, making it harder to use CoffeeScript written modules. * I don't know CoffeeScript, so it's harder to debug. * The language is bad, introduces things from Ruby he doesn't like, there are ambiguities introduced. When asked about ambiguities introduced, there was a reference to a "different require implementation in CoffeeScript", which has possibly since been fixed.
  - deleted 13y ago
    [deleted]
slexaxton 13y ago
Hi, Stripe Developer here. 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.
- rcsorensen 13y ago
  What are you using to stitch the modules together? Stitch, browserify, grunt/grunt-contrib and friends, something home grown?
  - slexaxton 13y ago
    This varies from project to project based on needs. The checkout stuff uses sprockets-commonjs, browserify and require.js are used in other projects though. The decision is often made based on the backend (is it already ruby/sprockets?), and the needs of the project (would rebuilding the full file on each change be prohibitive). For the most part though, the build system remains transparent to all but one person (me, these days).
- e12e 13y ago
  Any plans for open sourcing the source, as well? Why/Why not?
  - slexaxton 13y ago
    Many important parts of checkout are open-sourced via our jQuery.payment plugin [1]. It allows you to build your own checkout flow from component parts. As for open sourcing (capital C) Checkout entirely, we're working hard to provide a high-touch, consistent experience for checking out and we haven't been able to reconcile that with a bunch of small (maybe less thought-out) variations on the same thing floating around. We're always trying to think about ways to make this stuff better, though. We're definitely not against the idea, we just wanna do it right (i.e. allow non-programmers to customize without making things work incorrectly or look bad). 1. https://github.com/stripe/jquery.payment https://github.com/stripe/jquery.payment

joeblau 13y ago

I just got my Stripe shirt last week :). Thanks for open sourcing this. I needed something simple like this for selling tickets.

zrail 13y ago

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!

AwesomeTogether 13y ago

gee. i thought you had to use a javascript framework to build an spa.

alaskamiller 13y ago

Man, so Stripe just makes payments so easy. Link this up with https://www.shirts.io https://www.shirts.io and you get an instant t-shirt shop with no hassles.

Killswitch 13y ago
Yeah man, these dev friendly API companies are awesome. Stripe, Shirts.io, EasyPost (https://www.easypost.com https://www.easypost.com) Loving them all.

themgt 13y ago

Well, now all we need is an open source Parse-compatible server.

e12e 13y ago
My thoughts exactly. I looked at the code, the demo, and then: Ok, so how can I self-host this? 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 13y ago
hey, thats a good idea ! actually a great idea ...

callmeed 13y ago

It hasn't been updated in a while (and isn't as pretty), but I have an open-source shop for selling a digital good with Stripe: https://github.com/2tablespoons/thylacine https://github.com/2tablespoons/thylacine

powertower 13y ago

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.

powertower 13y ago

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.

pbiggar 13y ago
Yes, you can. You also don't need their card name or CVV.
jhuckestein 13y ago
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.
- simonk 13y ago
  Nope, Stripe doesn't require the CVV either.
  - Killswitch 13y ago
    It's optional but highly recommended. I've spent a lot of time in the Stripe docs over the last couple weeks building my new project integrating Stripe.

hunvreus 13y ago

I have to ask: is that a 草泥马 wearing that shirt?

reustle 13y ago

This seems to be a response to Shopify POS being released and now they are both creeping closer and closer to each other.