On a personal level, I'm very excited to know that I won't have to try and integrate Alipay in any of our products anymore. It's nightmare to deal with, even for our Chinese team.
But for Stripe, it's a huge step forward into tapping in a massive market. Most Chinese people can't (or won't) use card to pay online; they simply have Alipay connected to their bank account or use prepaid cards. Good move Stripe.
This is a huge deal. I'm currently in Shenzhen and Alipay (支付宝) is a common and convenient way to make payments, on Taobao, in person, or otherwise. Alipay is an interesting product in its own right, even if examined independently of the Alibaba Group. It has a money market service, Yu'E Bao (余额宝) that is currently a top 3 global money market fund with $89B AUM. That's a taste of the scale of the market in China.
Same here, working in Shanghai, building a few products and we could not really find an elegant way to integrate payment in those targeted to the Chinese audience. Using Stripe for all of the payments is an awesome news!
A question which no one has asked yet: what are the fees? Alipay charges a flat 3% while Stripe normally (for credit cards) charges 2.9%+$0.30. The variable cost to Stripe from a credit card processor is (of course) lower than 2.9% (so Stripe has a margin), 3% is (clearly) not (the fixed $0.30 only helping for small transactions). Will Stripe be charging more (variable, to have a margin) and/or less (fixed, to pass on the lack of a fixed interchange fee to customers) than its usual credit card processing fees when a customer is using Alipay? (An answer may also shine some light on whether Alipay is profit sharing with Stripe to get Stripe's support or if Stripe is being forced to charge on top of Alipay to get access to their users.)
This is great news for those using Stripe Checkout. Are there any plans to offer Alipay to Stripe customers who are utilizing the API for subscriptions, invoicing, and recurred payments?
As an aside, we also get a load of client requests for PayPal as an alternative simply because many people don't have a US-based credit card. If you're making the moves to support global markets, it's tough to side step them.
I really wish PayPal brought back their digital credit card which you could preload with cash and use online like a real credit/debit card. It would solve all of our problems with users who don't have a CC!
The Alipay integration with Checkout works just like Stripe.js, in that it will return a token that you can charge instantly, or attach to a customer and utilize for subscription, invoicing and recurring payments.
Thanks for the response. To narrow down the scope of my question a bit: Do you have any plans to open up API endpoints that would afford us the privilege of choosing a gateway on our own?
I'm asking because our checkout is completely devoid of Checkout or Stripe.js, i.e. the "building the whole payment form" route you mention on the checkout page: https://stripe.com/docs/tutorials/forms.
No, just whether or not you'd implement Alipay into your API in a manner that would allow for us to handle the frontend UI ourselves (letting our users chose between Alipay or credit card).
We felt that Checkout was the best integration point because it let us do some nice dynamic authentication logic instead of Alipay's usual redirect-based flow. Given that subtleties involved, Alipay's constraints, and the fact that it'll no doubt need to evolve in the future (as compared to the static standardization of credit cards), I think it'd be pretty tough to expose it via a straight API.
That makes sense. Given the fact Checkout simply returns a token, I think it's safe to say that it can still work with existing backend API solutions in conjunction with webhooks.
Which is amazing. Serious kudos for making it so darn easy. Once you have a token, you no longer have to care what the original payment method was. Absolutely how it should be.
Seriously PayPal, get on this. I just asked for the same thing in the comments further down. We've got an international base of clients asking for PayPal support and we're using Stripe. Rather than force us into two flows on our end, work with Stripe so we can just utilize them and you collect $$.
This is awesome, and you are awesome Patrick. Gotta have serious respect when the founder of Stripe, who I have to assume is quite a busy guy, shows up to personally respond to comments, encourage new features, and drop his personal email.
Tough to say. I know that Recurly has gone the approach of supporting any number of gateways (http://recurly.com/gateways/). Is there a technical limitation of Stripe that doesn't allow for this?
I was under the impression PayPal does allow charges with their Direct Payment API (i.e. Payments Pro). Are you specifically referring to the fact you have to be redirected to their site for login to do so?
1 - Will you handle micropayments (i.e. not rake 30 cents on top of 3%)? Alipay excels at this.
2 - Can some/all of the RMB sent to the Alipay account not get exchanged to USD and auto transferred to the Stripe account holder's bank account? This is a common use case to pay for China-side costs and not have RMB exchanged to USD and exchanged back to RMB to pay partners/vendors.
3 - Will you have servers inside China? If you don't you will need some incredibly fault-tolerant javascript and page load magic as some of your interactions with non-China servers will fail.
This is a very interesting development, partly for being a useful feature for some merchants in its own right, but perhaps also if it signals a more general move from Stripe toward supporting a broader range of payment methods through a unified API. That strategy seems to dovetail neatly with accepting payments in multiple currencies, which was something else Stripe developed not so long ago but isn't much use alone where the local conventional payment methods don't involve credit cards.
I wish there was a non-JS version of Stripe Checkout. Rather than throwing up the modal window, I'd prefer to redirect my users to a Stripe hosted checkout page where they can make payment and we can deal with it via webhooks. Similar to how PayPal works really.
Currently I'm integrating with the API directly to do this but I'd have preferred to use a page hosted by Stripe, especially considering they are starting to open up to other payment methods.
As a buyer, I hate when pages do that. It jolts me out of the smooth experience of buying a thing. Since I've never done a PayPal integration, seeing the PayPal logo as part of that experience is a big chunk of the reason I believe it when other programmers say that PayPal is super-annoying to integrate with.
Stripe would need a page that doesn't have its branding but instead only has yours.
Alipay payments will all be nominated in Yuan (RMB). How does Stripe convert this back to USD? The laws of converting currency in China are very restrictive.
Wow this is awesome. I had to integrate Alipay into a checkout process in ~2010 and it was a complete nightmare - and not even as a result of the language barrier. The API was just so so bad. Glad this is in Stripe now.
How does Stripe deal with the currency conversion? Is this tracked by Alipay on an individual level (i.e. so consumers can't spend more then the legal conversion amount of 50k USD)?
How is that annual 50k USD monitored/enforced now? If I have multiple bank accounts, will I be prevented from withdrawing a combined 50k from overseas ATMs?
So, the bank will report these currency exchanges (including overseas ATM withdrawals from an RMB account) to some central authority like PBOC, who will then combine it with info from other banks, and thereby know if I've breached the annual limit?
There is an real-time system shared by all banks. I can see my remaining quota immediately updated whenever I made an exchange.
In your example, if you have RMB in your China bank account and withdraw RMB overseas, these are no currency exchanges at all. It's not relevant to the $50k exchange cap.
As a Canadian, I'm most interested in when Stripe will start supporting our Interac debit cards. At that point, from my point of view, it'll have taken over the world. :)
How often do you actually buy things online with interac? I think I've maybe done it once, and the redirect-to-the-bank flow is pretty awkward. My sense is that this isn't ever a barrier to conversion for Canadians (except maybe for very large purchases?), but I'd be curious to hear otherwise.
I don't count as a user, since I am relatively affluent, tech-savvy, and always pay off my credit card every month.
I'm thinking of the average person who buys with Interac to avoid debt, and feels an impedance to buying online because of credit-card-only. I'd love to have the ability to enable those people's purchases through Stripe.
(I agree that the bank-redirect flow is awkward slash awful. However, you solved exactly that problem with your Alipay integration! :) )
People don't do it because there is very limited ability to do so currently. Only certain websites accept it and it only works with certain financial institutions.
It'd be nice, but you could fit 40 Canadas into China (population-wise), and most of us already have credit cards due to our proximity with the US. It's sad but completely rational that so many American services don't bother with us as a country.
Not for now. Part of the reason Alipay was comfortable with this new flow is because it's served as part of Checkout. If we were to provide Checkout-less APIs, we'd probably have to go back to the old redirect model, which (among other things) just doesn't work well on mobile. I expect we'll always offer APIs for "standardized" instruments, though (ACH, Bitcoin, cards, etc.).
Just to be clear, are you saying that this new payment method will only be supported (at least for now) for those with a checkout.js integration, not those using stripe.js and their own front-end/branding?
Obvious feature request #1: Support it via stripe.js and the usual APIs as soon as possible.
Obvious feature request #2: In the meantime, provide a version of checkout.js that is (a) stable and (b) simplified to support Alipay only (so those of us who prefer to accept other payment methods can still do so via stripe.js without winding up with multiple confusing options and bad UX).
Can you say more about "(a) stable"? If you mean that you've had problems with robustness or availability, I'd love to hear about that, because in general we believe it's been very good on those fronts.
If you mean that it the UI changes from time to time, then (for better or worse), that's a fundamental property of Checkout: we are continually iterating and optimizing and adding new features (like Alipay!). We do understand that it's not for everyone, but a lot of people use it for exactly that reason.
Sorry, I didn't actually answer your initial question: yes, Alipay is only available through a checkout.js integration, not a stripe.js integration. I think it's unlikely that we will do a stripe.js integration for Alipay - as Patrick mentioned above, it would probably have to be a redirect model like Alipay's other integrations.
However, it's possible that we could do a special alipay.js, which I think is what you're getting at with #2. This wouldn't be Stripe Checkout, exactly, but a standalone Alipay product where we provide the UI is certainly something we'd think about down the line. We don't have any specific plans here but feel free to email me at avi@stripe.com if you want to talk more about that.
By stable, I meant something that doesn't have the unpredictable UI variations of checkout.js, which for some of us is a significant concern. (See various previous HN discussions about Stripe, particularly around the time the phone number/remember me changes came in.)
When there was always the alternative of using stripe.js (as also repeatedly mentioned in previous HN discussions) this wasn't a huge deal, because anyone who wanted stability could just go the other path. I think some of the concerns before were more about how many of us didn't realise that Stripe sees checkout.js as an ever-evolving test bed.
If that no longer applies then there is now a need to choose between instability with checkout.js and losing features with stripe.js. When I first joined this discussion today, I was happy at the idea of Stripe starting to support a broader range of payment options. As I'm reading more, my joy is turning to concern that checkout.js is becoming the preferred integration method with significant downsides for those who don't comply.
I do understand that there may be good reasons for locking in your choice of payment UI. On the other hand, this is not the first time I've dealt with a payment service where you can't cleanly integrate the whole process into your own brand/UX, and interrupting that flow rarely turns out happily for conversion rates or, sometimes, brand reputation.
With that in mind, if proper support isn't available for Alipay, then some sort of alipay.js as you mentioned would certainly be welcome, particularly if it allows at least basic styling customisation to match the colour scheme and typography of the merchant's site.
Thanks very much for the feedback. (Feedback helps! As you may remember from the previous thread, we did change the Remember Me + phone number fields to be optional, in large part because of the feedback we got on HN.)
Each new payment method comes with its own constraints. We'll always try to give our users as many options as possible while working within those constraints. The constraints with Alipay are particularly tight, and for now the only way we can satisfy them is through checkout.js - but over time, if we can relax that, we will. We're definitely not moving to a model where Checkout is always the first or only way to integrate a new feature. For example, the two other alternative payment methods we have in beta right now are ACH and Bitcoin, neither of which are built into Checkout. We do hope to eventually support both of these in Checkout, of course, but in those cases, it was easiest to do the API first; in the Alipay case, it was by far the easiest thing to do Checkout first.
(Feedback helps! As you may remember from the previous thread, we did change the Remember Me + phone number fields to be optional, in large part because of the feedback we got on HN.)
That's good to know. FWIW, I hadn't heard anything about that change, which would have been of immediate interest to at least one team I worked on that was still relying on checkout.js at the time.
Each new payment method comes with its own constraints. We'll always try to give our users as many options as possible while working within those constraints. The constraints with Alipay are particularly tight, and for now the only way we can satisfy them is through checkout.js - but over time, if we can relax that, we will.
Understood, and thanks again for taking the time to explain.
But for Stripe, it's a huge step forward into tapping in a massive market. Most Chinese people can't (or won't) use card to pay online; they simply have Alipay connected to their bank account or use prepaid cards. Good move Stripe.