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.
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.
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.
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.
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.
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 ;)
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?
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.
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.
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.
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)
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.
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 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.
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.
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! :)
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
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.
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.
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.
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).
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'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.
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.
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.
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?
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.
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.
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.
175 comments
[ 4.5 ms ] story [ 217 ms ] threadJust wanted to add, the demo works if you use the 4242 sequence for all fields (YMMV).
pweassee
How about the ability to subscribe someone to multiple subscriptions now?
nudge nudge.
Sample size of one company, so take this for what it's worth.
Why doesn't it auto-fill when the user types a valid zipcode? Seems like cheap satisfaction.
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 ;)
They would not make a glaring mistake like this (though their users easily could).
If you're not using SSL, you should just assume that an attacker can break your page in every conceivable way.
Fortunately, the "old" Button <script> still works for now. i.e. <script src="https://button.stripe.com/v1/button.js ...>
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?
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.
>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.
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 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.
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.
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
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.
For instance, collecting an email address would have to be done elsewhere.
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?
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.
I normally uncheck the "Save This Card" option, with Stripe they don't allow this.
I think it would be clearer if I saw some examples.
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.
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.
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.
[ 1]http://thirdpartyjs.com/
"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?
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?
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?
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.
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.
http://www.pinspire.com/ http://www.wimdu.com/ etc
My advice: do not spend time integrating with their API before they authorise you to do real payments.