Stripe Checkout | Hacker News Reader

Stripe Checkout

stripe.com

536 pointsilldave171 comments

One of the bread & butter services @ ConversionVoodoo.com is fixing broken UI's around checkout / carts.

I have yet to meet a retailer that we can't hit at least 15 - 25% improvement in sales by testing and fixing their checkout.

Take those gains and multiply that times the entire internet and Stripe has the opportunity to make a major impact on the GDP (I'm only half kidding).

A few years back I shared one of our "low hanging fruit" cart optimization strategies that almost always works:

http://www.conversionvoodoo.com/blog/2010/07/proper-placemen...

Despite being nearly 3-year old advice, moving security / trust symbols into the visual field of sensitive information remains an easy conversion gain that we see STILL work nearly every time to the order of 5 - 10% gains.

But the current reality is that even being able to test your checkout process on most of the leading "off the shelf" ecommerce platforms is an incredible pain in the ass (I'm looking at you Magento, Oracle ATG, etc)

If Stripe executes on this idea - scaled cart testing - every dollar that an organization pays for Stripe fees is easily cancelled out by a properly optimized checkout form. This is huge.

>I have yet to meet a retailer that we can't hit at least 15 - 25% improvement in sales by testing and fixing their checkout.

>make a major impact on the GDP

I agree on the percentages (I'm myself a big advocate for A/B testing), but I do think that a lot of those gains are made because a certain company becomes a lot "better" than their competitors by employing these kinds of techniques.

Example from my personal life today: I looked at gyms in London. After about looking at 5 I got slightly annoyed: They tried to hide their prices, generally broken UI and I felt they were trying to trick me into a high-paying contract. I then stumbled over site 6: Clear value proposition, not afraid to ask their prices and super easy to do a first training. Sold.

If every single gym out there had a great website, I still would only get 1 gym membership. Though it would probably help if it didn't cause me so much time & pain to do it. But most of the pain is not in the checkout process (punch in credit card numbers). In fact I don't think I've ever not made a purchase because the credit card form wasn't to my liking, the buy/no buy decision generally gets made much earlier and that's an issue that I don't think is for Stripe to fix, but rather for individual companies learning about & implementing great sales channels.

I live in London and need a new gym. Which one was it? Thx.

Gains eliminated once everyone on level playing field.

I don't think that's true at all. It will certainly disproportionately benefit companies that smooth out the kinks before their competitors do, and that will be eliminated with industry wide adoption.

But take the inverse; if every transaction in the world were made more difficult (eg, by removing credit cards and bank transfers, leaving cash and mailed cheques), do you believe that wouldn't shrink the economy?

Worldwide adoption of best practices certainly wouldn't suddenly increase the worldwide GDP 20%, but the rising tide of demand due to reduced transaction friction would lift all boats, so to speak.

I think people would make better and smarter purchases if things weren't so easily purchased.

That could be one effect, but another effect could be shrinking of the economy. (eg. cases where someone would have made a good & smart purchase but didn't due to amount of effort involved)

Why the high value for a constantly growing economy? GDP is the wrong set of metrics to follow anyway because if you do something that causes pollution and harm to people and the environment, it's recorded as a positive increase.

I'm not sure whether a constantly growing economy is good or bad. Seems very multi-faceted and almost meaningless, really. An economy could be growing or shrinking for so many good or bad reasons.

I think the point we're making is that if people couldn't make the transactions that they wanted to make, it would definitely shrink. That feels like a bad reason for why an economy should shrink.

Agreed.

If you dont mind, could you share some of the gym websites you mention in your comment (especially the good one)? I'm a web developer and I happen to have a lot of clients in the health club business so I am very curious to see the sites you looked at (and hope none of the bad ones were me! :)

> moving security / trust symbols into the visual field of sensitive information remains an easy conversion gain

I recommend reading Web Design for ROI for other tips such as that. [http://www.amazon.com/Web-Design-ROI-Browsers-Prospects/dp/0...]

- I am not the author, I just found this book interesting in how impactful certain ecommerce design modifications can be towards increasing sales.

> make a major impact on the GDP

I appreciate the sentiment, but it's worth pointing out that online retail I the US only accounts for about 5-7% of the market. The UK is doing probably the highest at around 12-15%. So it might make a blip, but don't get too carried away

For those of you reading Third-party JavaScript[1], check out their source https://checkout.stripe.com/v2/checkout.js (it's uncompressed!). There's a lot of stuff to learn there.

[ 1]http://thirdpartyjs.com/

That is a very interesting bit of code. It would be even nicer if you could somehow see the original CoffeeScript...

Yes. Can someone reading from Stripe please provide the CoffeeScript version? I'm really interested in checking it out.

Not original source, but close enough http://js2coffee.org/

Interesting to read that it doesn't work on iOS Chrome. I tried it on actual device, it pops the alert and tells me to use Safari.

Hey stripe listen. Redirecting to stripe.com is STRESS but its good for users because of security.

The overlay can (and would) easily be imitated by crooks who want to steal credit card details.

It would be much safer for users if you offer a paypal-like service where you store their credit details before hand. If you do this, then this is what should happen.

If the users has already logged in, then the overlay would simply be selecting the amount to pay (which coincidentally is shorter for users) and optionally, which source of fund to deduct from if user has multiple credit cards stored.

Security of funds is more important than ease of use.

Unless you are doing very simple ala carte purchases this button reduces total complexity by maybe 5%. If you are doing subscriptions, with coupons, with trial periods, creating users at the same time, wanting to show the user their coupon/trial status, last 4 of their CC, send emails on failed payments, cancel accounts on failed payments, let people update their card, etc, etc, etc it is still very complicated to get all that integration correct.

What stripe needs to do is sponsor the development of an official rails gem that handles all these things like ActiveMerchant (plus views people can then hack on like normal rails views). Many people are implementing these things over and over again, probably including stripe developers themselves for their own side projects. It is a huge waste of effort and source of bugs for everyone.

One nicely written gem that integrated easily with common practices for User models and people could integrate stripe with a simple "stripe_user :subscription, :email_notify" whatever. That would be awesome.

I realize rails is not the entirety of their business but I'm just saying it would make me and a lot of other people happy.

It would be great. But the stripe gem out now is decent, and it's probably not high on their priority list.

It's not clear to me what you are envisioning here.

ActiveMerchant is a payment gateway abstraction layer, and in fact it already supports Stripe. It has two use cases: A) legacy gateways with shitty APIs and libraries (eg. Authorize.net) and B) theoretical portability between gateways. At my company we recently swapped out AM for the Braintree gem because the lowest-common denominator made it inferior for interfacing against Braintree, and the payment interface surface area in the app is small enough anyway that the theoretical advantage if we switch payment providers is negligible anyway.

Stripe if anything has a better API and ruby library than Braintree (Stripe uses a lot of Ruby internally is my understanding), so what's missing?

A higher-level gem that gives you plugin payments would necessarily start making assumptions and compromises that would quickly whittle down the number of ideally-served use cases, whereas the Stripe API as it stands now is at the granularity to fit the maximum number of use cases without being over-complicated. If you want to make something easier I think you veer into clumsy high-level components that is more akin to Drupal than Rails.

Sorry, what I described doesn't jibe with my comparison to ActiveMerchant as you pointed out. However it would still be badass to get a dropin solution for using Stripe in more complicated applications. And I know Stripe has a better API than alternatives but that doesn't mean it isn't still tricky.

I'm not sure I agree that a higher level gem would be of limited use or only of use to a few applications. I think it can definitely be done in a way that would have helped me big time in all three applications I've integrated with Stripe despite their unique needs.

I'm hesitant to add this to https://www.bngal.com because it seems like there could be usability issues if you need to capture other information on a single checkout form (email address, shipping address, shipping method, etc.).

It seems like a customer would do the following:

- Fill out all data except billing info

- Click the "Pay with Card" button

- Overlay comes up, they enter billing info, then click "Pay $X"

- Overlay closes, token is passed back to form, form is automatically submitted via JS

The proof is in testing and data of course, but my gut tells me people prefer just a single form and button. That's why I like the original checkout method.

The mobile part is great BTW.

Collecting addresses is as simple as adding a parameter: https://stripe.com/docs/checkout

Although it is possible to collect the customer's billing address (using the 'address' option) using the Checkout form, it isn't (yet?) possible to add other, arbitrary fields.

For instance, collecting an email address would have to be done elsewhere.

Not having the ability to add an email address field to the checkout form is a real deal breaker for me. I wonder why they did not implement an optional email field.

Just confirming, this is the same solution that was earlier published as Stripe Button right?

I'm curious about this too...

Yes. The Stripe Button documentation even redirects now to https://stripe.com/docs/button

Fortunately, the "old" Button <script> still works for now. i.e. <script src="https://button.stripe.com/v1/button.js ...>

Yeah, we've had various iterations of this live on the site for a while, though we never announced anything. We renamed it to "Checkout" a few weeks ago.

Dear stripe,

Hurry up and offer a ckeckout with stripe option. I'm tired of dealing with Paypal. Thank you.

Good god yes.

That being said they're making insane progress. I am very happy with them.

This is great, good work!

It looks like `token` is the only callback you can pass to the popup and it receives nothing but the stripe token. Is there any reason not to include more information?

For comparison, this is what stripe.js gives you

  {
    id : "tok_u5dg20Gra", // String of token identifier,
    card : { // Dictionary of the card used to create the token
      name: null,
      address_line1: "12 Main Street",
      address_line2: "Apt 42",
      address_city: "Palo Alto",
      address_state: "CA",
      address_zip: "94301",
      address_country: "US",
      country: "US",
      exp_month: 2,
      exp_year: 2012,
      last4: "4242",
      fingerprint: "BzXGiNioaEH4iECL",
      object: "card",
      type: "Visa"
    },
    created : 1358552058, // Integer of date token was created
    currency: "usd", // String currency that the token was created in
    livemode: true, // Boolean of whether this token was created with a live or test API key
    object: "token", // String identifier of the type of object, always "token"
    used : false, // Boolean of whether this token has been used,
  }

My app uses this information. So as much as I want to, I can't just drop in the new code.

I could use Stripe.getToken but I don't see why I need the extra roundtrips to the server (one for stripe.js, one for getting the info about the token)

Edit: Never mind, I didn't read the docs carefully enough. The callback receives all that, my bad. In the stripe.js docs the parameter is called response and in the new one it's called token. Sorry ;)

This is kind of similar to Gumroad's Overlay: https://gumroad.com/overlay

It is, and oddly enough they both use "4242 4242 4242 4242" as the test card number.

there isn't many test numbers if I can remember correctly. 4111-1111-1111-1111 is another.

Oddly enough Stripe won't accept that as a test number.

Here's the full list of cards we let you use for testing, including some that trigger specific responses:

https://stripe.com/docs/testing#cards

Many (most?) CC processors use that number, as it is easy to remember and passes the Luhn checksum.

I believe the reason for this is that it's one of the simplest card numbers that passes the Luhn check:

http://en.wikipedia.org/wiki/Luhn_algorithm

Pretty sure it's because Gumroad uses Stripe. Heard that from a rival CEO though... So don't quote me.

Christ alive I hope Stripe get over to the UK soon.

Hell, I'll invent an app just so I can use Stripe and reassure myself that it's all going to be OK and I'll never have subject myself to the existing solutions again.

Paymill is a clone that looks nice: https://www.paymill.com/en-gb/

Please don't support that company of cloners (Samwer).

Why not? What's wrong with being the second to provide a useful service?

http://news.ycombinator.com/item?id=5086824

Oh, it's wrong to clone startups because it's wrong to clone startups. Got it, thanks.

Nevermind, I take my comments back. Sounds like you'd be a perfect customer for Paymill.

To recap, your comments were basically:

"Paymill is a cloned business, and thus they are bad".

"Cloned businesses are bad because they are cloned".

"If you won't accept my assertion without any justification, I don't want to talk to you".

Do you have any actual reason for your opinion, or do you always form your beliefs from instinct and feelings?

My reasoning is simple (and has already been stated clearly) - The Samwer brothers are notorious for cloning as many hot valley startups as they can, often pixel for pixel.

Might be legal, but it's certainly not an ethical way to do business. Additionally, I would never trust my business with a company that was in it for the money, especially if they could shut it down at any time, as they often do with other clones that aren't quickly adopted.

Lastly, it's clear you and I have a different set of values, therefore I am uninterested in persuading you of anything. The fact that you don't see anything wrong with cloning other businesses makes you a perfect customer for one that does.

Is it really so hard to understand, or are you being intentionally obtuse?

It really is so hard to understand. We've been begging Stripe to come to Europe for ages now. They still aren't here. Paymill managed to open a company in that time, and do what Stripe does.

Most companies are in it for the money, that's why they're formed. Do you think Stripe will continue existing if they don't make money? That said, the part about shutting down companies that aren't quickly adopted is the only real argument you've made in this discussion.

Copying elements from a startup is ethically dubious, sure, but Paymill is providing a valuable service to people who wouldn't otherwise have it. It's "Stripe for Europe", but why is that bad? If frozen yoghurt is all the rage in the valley at the moment, is it unethical for you to open a frozen yoghurt shop in your home town?

If you're in Europe, you can't "support" the original.

I would totally switch to Stripe if they were available in the EU. I am thankful that Paymill tries to replicate the awesomeness of Stripe.

Blasting Paymill for copying the model of Stripe is not in the same category like calling distribution of copyrighted material theft. If executed well it is a net benefit for society.

Why not?

Stripe isn't here, and any desire to support their innovation whilst waiting for them to arrive leads to European startups potentially missing opportunity.

It's our responsibility as European startups to get money through doors, and if Paymill is here doing that for us today, then give us a good reason not to use them.

If and when Stripe arrive, I'm sure that many HNers would switch to Stripe as the innovation and support is great. But fact is, they are not here yet... and the only thing that matters is how to process payments in a way that is smooth and minimises our dev time to implement.

If Stripe want our business, then on the day they launch across Europe then they can fight for it.

Until then, Stripe are not here... they aren't even a contender because they are not here. Startups are not going to wait for them on a promise that it will be "soon".

The great thing about the Paymill API is that it is such a Stripe rip-off that if we implement out payment flow based on their API, then we have in fact given ourselves the least painful route to later transition to Stripe.

Implementing Paymill gives us a more likely route to transition to Stripe than implementing one of the incumbents flows (PayPal, MoneyBookers, etc).

So of all options actually available to European startups, Paymill look pretty good.

Because these guys are notorious for copying every startup in the valley:

http://www.pinspire.com/ http://www.wimdu.com/ etc

Paymill involves a lot of paperwork and is not as straightforward as they would lead you to believe.

My advice: do not spend time integrating with their API before they authorise you to do real payments.

Yeah, first they asked for a business certificate and a photo of an id, then they asked for a sign contract, the ToS and an imprintation (or something like that), and I don't know if they'll ask for more. We'll see.

Yeah, the "imprint" is a Germany thing. Every web site needs to have the name and address of the person/company responsible for it. It's a very silly German regulation but if you want to use Paymill you have to comply with it.

Ugh, yeah, that's it. And we're not even based in Germany!

That is really nice. Love the integration hooks as well. Next up is a 'we know who you are' stripe cookie that would let you "pay with stripe" on web site A without entering any of this data. Or, for the paranoidish "Enter your StripeID: xxxx" pause "Enter the code we just texted you: xxx" thanks!

Paypal 2.0

Stripe is pretty cool. We've been using it on http://www.IslamicEventFinder.com and was the best library experience to integrate. A few things we noticed, the CVC check is not as impressive, it charges the card even if the CVC is not correct, at least we've seen in a few instances. Other than that it looks solid.

Would prefer some sort of a seal or something on the popup to indicate that their payments are safe, a few clients asked. At least an option to customize displaying that seal would be great and also may be the type of credit cards Stripe accepts.

Is this Checkout thing same as Stripe.js? I didn't get a chance to checkout (lol) this fully yet!

> it charges the card even if the CVC is not correct

Some users want that behavior. But we're rolling out tools that give you the option to decline charges if the CVC fails.

Why would any user accept cards with invalid info? That's just asking for chargebacks.

Because the assumption is it's a valid charge but the user simply mistyped their CVC (or don't understand what that number is and put in the wrong thing entirely). If these purchases are rejected, the user may never complete the sale.

I was a bit shocked to see this behavior at first and spent some time debugging it thinking it could be an issue on my side. It turned out not. It's no big deal but could bring doubts on consumer's mind if they intentionally type wrong CVC (I used to do that before on other websites!). Glad to hear that Stripe is on it and can't wait for that tool to show up.

Can you please also answer a few of my other questions including the reliability seal thing? I'm sure that would be a simple change from your side and the developers may not even have to do a thing.

More info here, close to the bottom:

https://answers.stripe.com/questions/does-stripe-have-settin...

@pc: Why would anyone want that behavior? Could you elaborate?

This is great, and I've implemented it on two different sites so far. It's great to be able to tell a client "Just go to Stripe.com, link it to your bank account, and add my email to the account" rather than setting it all up from scratch.

I'm confused, so say I put this button/form on my site.

How does my app tell the button the final price?

How does the button send the token to my app?

What does the user see after they pay? Does the button display its own receipt or do I build that?

The charging isn't done on the client, it happens later on the server. All this checkout does is turn a user's credit card into a token that you can safely send to your server. Then, server side, you can charge the card or sign the user up for a subscription.

So, in other words the price is client-side, and only used for display. The token gets submitted in a form to your server. And you build the receipt page.

Are customers not concerned that stripe is storing their CC info for any use in the future?

I normally uncheck the "Save This Card" option, with Stripe they don't allow this.

Why ask for the name on card? That's not auth'ed.

Many users want to collect names, and it can be helpful for fraud purposes. We're still evolving and testing, though. We might not keep it forever.

At a previous company, we also found it to be a usability issue. Customers were confused when they were looking for a place to put their name, but couldn't find one. Incidentally, we encountered the same problem when we removed the "State" field from the address section (we could glean it from the zip).

Sample size of one company, so take this for what it's worth.

This actually wouldn't surprise me. Similarly, not asking for the card type is confusing to some people (even though the card type is identified in the first characters of the card number).

I like having the city and state filled from the zip code. That way the user can see that it is being used and will not be confused. Plus, pushing a button to enter text that you normally would have to spend time filling out feels like a reward.

>pushing a button

Why doesn't it auto-fill when the user types a valid zipcode? Seems like cheap satisfaction.

Still not common enough that it would confuse most people.

FWIW: Getting state from ZIP would break some edge case users.

zip->state is not a many to one mapping, it's many to many.

Example: Zip code 19973 spans both maryland and delaware.

https://www.google.com/maps/vt/data=Ay5GWBeob_WIPLDYoIWcfVXx...

The dashed vertical line is the maryland/delaware boundary.

You can see there are people both in maryland, and delaware, who have that zip code. The post office is in seaford, de.

This actually came up in the real world in some elections stuff, because these folks often list their mailing address as in seaford, de, but vote in maryland ;)

Good call. Being able to fill out a form in my sleep is more important to me than 50% fewer keystrokes.

Does this mean the older Stripe Payment "Tag" is deprecated? We're currently using it to great success, but I'm no longer seeing it mentioned in the docs. I don't really want my users to have to press an additional button -- right now as soon as they're on the payment page the form is right there waiting to be filled in.

Yep, we think that this is a better solution than the tag (which we never really launched). But I'm glad to hear it's working well for you!

Well, for what it's worth, I think it would be worth offering the ability to embed this both as a button and as a part of an existing page without the popup. In the meantime, I'll continue to use the payment tag.

Has anyone ever tried making the credit card box freeform? Where there are no rules. Just type your credit card number, your 3 digit security code, your expiry date, and name, and the form works out what entry is what data. I wonder if it would be easier to out weight the confusion of a user trusting a computer.

Small point: You don't even need the name.

Big point: I wouldn't want it user-facing (e.g. the ubiquitous self-checkout that is online shopping), but it might be a nice tool for power users (e.g. cashiers).

Yeah, all good and well … but I just used this with a UK Visa Debit card (which are pretty strict in terms of acceptance) on Gumroad, and not only did the thing not verify without a name, but my card got flagged for fraud and frozen until I contacted my bank! I'm pretty nervous about using it now.

That's extremely unlikely to be related to the Stripe checkout widget. International purchases often raise fraud flags.

An international purchase that doesn't ask for the name on your card though? (I know most check as my CC has a weird format, if it's put in wrong it doesn't validate.)

Added this to https://www.startupthreadsmonthly.com a few weeks ago and have had good success with it. Easy to implement and trigger from js. Still pulling in conversion numbers but users have said they like the flow.

Very cool. Good job.

How about the ability to subscribe someone to multiple subscriptions now?

nudge nudge.

gaaaahhh please let me play with it! Can't you come to europe, or at least UK ?!?!

pweassee

Paymill and Braintree are available, though. Try one of them.

You can be notified the moment we launch by simply giving us your email here: https://stripe.com/global

What a crazy coincidence, I just factored out my company's payment widget code into a reusable module a few days ago: https://github.com/substack/pricing-widget

Basic example: http://substack.net/projects/pricing-widget/basic/ Fancy example: http://substack.net/projects/pricing-widget/browserling/

Can you style it to match your page?

Yes, you can use your own submit button with the JS API: https://stripe.com/docs/checkout

yes, the button is no problem...everything after that is loaded in an iframe though, and so i think xss safeguards prevent you from modifying any of the elements.

Has anyone else not been receiving 'charge.succeeded' events on their Stripe webhooks? We have been receiving all events except that one, even when all charges are succeeding as verified through the management panel. This is a big problem as that is the event that's used to actually process a payment and create a new account.

The problem seems to have been going over for around 8 hours now.

We've received no reply from their support in 4 hours.

Anyone have any ideas how to get in contact with them at this time?

This is cool but Im confused about the workflow

On a signup form:

1. Enter email

2. Enter password

3. Click the Stripe checkout button, div popup, fill in and click pay, popup goes away, Token created and added to the form

4. User clicks submit on the original form

Is that right?

The idea is clicking submit on the host form would trigger the Checkout. Then, after you enter your payment details, the whole thing submits.

Ah! got it, thanks

Great looking checkout form. Stripe's adding some clutch features, somewhat seem to be evolving for just payments for developers to payments for developers and others.

The site describes the popup as an "overlay." Another commenter used the words "div popup."

I'm writing this on a machine with Chromium and Firefox on a nearly new Linux Mint 14 install (all packages are up-to-date) with no browser extensions or other weirdness. When I click the "Pay with Card" button in the article, both browsers open it in a new tab.

Are my browsers broken, is Stripe's code broken, or is there some miscommunication about what the button is supposed to do?

Recurring payment friendly?

I wasn't able to find any documentation about using the button for recurring/subscription billing. I hope that's a feature coming soon.

Yeah, you can definitely use this with recurring payments. Once you attach the token created by the Checkout to a customer, you can bill the customer whenever you like. (There's more at https://stripe.com/docs/checkout)

That link is broken (has an extra period).

Thanks, fixed.

Checkout simply creates a token, that you can use to set up a one-time payment, recurring payment, or even to just create a new customer object in Stripe.

Does anyone know of a tutorial or some skeleton code samples that allows you to build an embeddable website widget like this?

From what I can see, there are 2 iframes for the button and the hidden overlay. Clicking on the iframe button enables the overlay via some sort of iframe to iframe communication on the parent(host) page

Can anyone point me to a tutorial showing me how to integrate stripe with Django?

I think it would be clearer if I saw some examples.

Here's one integrating Stripe with Flask - https://stripe.com/docs/checkout/guides/flask

I haven't used the checkout button yet, but here's what I learned from rolling my own: the form comes in with a token which you then charge with the stripe Python API, and on successful payment, you receive a callback at your webhooks url (which you set in the stripe settings). Take a look at the Django-Zebra app (https://github.com/GoodCloud/django-zebra).

Wow looks nice. Is an SSL certificate still required since the JS is on Stripe's secure server?

Yes, absolutely 100% yes an SSL certificate is still required. Look up mixed content warnings and why they're a bad thing.

You get a mixed-content warning for HTTP on HTTPS, but not HTTPS on HTTP as you're already insecure on the original page anyways.

Yes. Otherwise an attacker could serve a page that looks just like your page, but has different javascript that ships them the credit card numbers.

If you're not using SSL, you should just assume that an attacker can break your page in every conceivable way.

fwiw -- my site is hosted with a company that doesn't have ssl, and we just direct our payments over to a heroku page, which is served by ssl on their free plan.

Is there a way I can dynamically change the data-amount, data-name, and data-description fields with Javascript depending on what the user clicks?

I'm picturing the user clicking a checkbox for an add-on product without having to make a round-trip back to the server.

Yeah, there's a full JavaScript API for setting these dynamically. Check out (no pun...) https://stripe.com/docs/checkout.

This is going to lead to phishing. Obviously the possibility is already there, but something tells me that once users get used to this, it will be lead to credit card fraud.

Not on a secure site? Well, the stripe widget just popped up, so it looks legit...

You get the idea.

You shouldn't use it on an insecure site, just like any other site requesting credit card credentials. If the site's insecure someone can MITM the whole thing.

Any Stripe employees want to comment on the idea of integrating this with a native iOS app via a web view? My guess is it will still be too clunky vs building your own, but the benefits of continued improvement may be worth it.

Does Apple allow that, without taking their 30%? I was under the impression that's why Amazon doesn't allow you to purchase books through the Kindle app anymore.

Apple's cut doesn't apply to physical goods, which is how the main Amazon app gets by. If you're selling some real widget you're in the clear.

I feel like an idiot for only just realising that this is why eBooks can't be purchased from the Amazon app, but can be from the mobile site.

Stripe already works with several companies that accept payments and bypass Apple's cut, such as OrderAhead and Exec. There are some types of purchases that must go through Apple, however, such as digital goods/content.

Yeah I'm interested in using this to sell physical goods, outside of Apple's domain.

Very neat.

Just wanted to add, the demo works if you use the 4242 sequence for all fields (YMMV).

I don't think I've ever seen a demo card that doesn't accept any valid string for expiration/name/CVC.

I tried with all ones (after the card #) and it would not accept the expiry date. I admit, I might be part of the problem. ;)

The expiration must be in the future

That makes a surprising amount of sense.

PayPal's PayFlow Pro product would return valid for 1XX, 2XX, 3XX CSCs and different errors (mostly CSC verification related) for 4XX, 5XX, 6XX, 7XX, 8XX, 9XX. Was quite useful for testing.

I think you just pointed out about the only useful thing out of the entire PayPal integration experience.

I'd love to know how it got through their formal Make Developers Hate Us processes.

There's a full list of test cards available here: https://stripe.com/docs/testing#cards

I love it, but for my app we charge subscriptions with a free trial up front. Do you have any suggestions on how to phrase the wording so it's clear that the charge isn't going to happen right away?

Yes -- you can change the text of the button in the overlay. See the "panel-label" config option: https://stripe.com/docs/checkout.

Hmm. Thanks for the tip! So, I'm setting:

  data-panel-label="Begin Free Trial"

But on the button I'm still seeing:

  Begin Free Trial $20.00

Not sure if this is the intended behavior, but I just can't see how it makes sense for a free trial.

Ah; right, we should change that/add an option to override. Can you email me? patrick@stripe.com.

I think if you avoid passing in "data-amount" it will not show that text.

Keep in mind that this checkout dialog does not charge the customer anything, so the amount is purely cosmetic.

Thank you for mobile support! You guys are truly awesome. If only you would allow me to accept payments without a business and bank account number, like PayPal does...

Do you not have a bank account?

Not yet for my startup/side project, no :/. No business number either.

Why not use your personal bank account?

Yes, I could use my personal bank account. I guess the real blocker is the business number.

We don't require a business number of any kind, you can sign up as an individual (the question will be "business type", and individual is one of the options).

I did this the first time I used Stripe, in a little project where I was mainly gauging interest for whether I'd persue it further. Just opened up a second checking account and linked Stripe to that. No cost or pain for me.

Stripe, When are u going to support Micropayments??

What do you recommend if I need to support users without Javascript? (I'm guessing this button isn't for me?)

Make users turn on javascript or just use a regular form.

Does it do address verification?

Yep; see the "address" configuration option at https://stripe.com/docs/checkout

Looks great. Any plans to include a coupon code field with this?

Good idea but I hate the box rising from the bottom.

   data-amount="2000"

It looks nice but every payment solution where the client can arbitrarily change the amount they're going to pay is inherently flawed.

The amount is just for display purposes. You then charge whatever amount you want on the server.

Could you deliberately deceive the user then? Put say, amount=500 and actually charge $20?

Sure -- but you can always deceive the user.

I guess my real question is - is there another page where it securely says the actual amount? (Does that make any sense?)

The amount is charged server-side, no way.

You should take a closer look at Stripe before jumping to such conclusions. It's hands down one of the smartest, cleanest and best-documented APIs in the history of the Internet.

They would not make a glaring mistake like this (though their users easily could).

Is this what HN has come to now? People jumping to ill-informed conclusions simply for the sake of triumphantly finding an ostensible flaw are voted higher than people who know what they're talking about?

Awesome! I'm ready to use this.

I'm going to use this to replace Paypal's "Buy now" button on my blog

Finally!

It's nice that you say it works in all major browsers, but the mobile support is poor. No chrome.

Short-sighted... Mobile is growing at a crazy rate in ecommerce.

Needs support for a list of items (like PayPal shopping cart API functionality), not just one item.

Reply on news.ycombinator.com