In many ways, launching in Canada is a big step for us—going from 1 to 2 is often harder than going from 2 to n—but it’s only a small piece of what we have in mind. We grew up in countries from Honduras to Kenya, and a large part of why we’re so eager to build Stripe is to help those outside the US to participate as first-class citizens in the internet economy.
I'm glad they address this before people complain about Stripe only moving to Canada.
I'm very curious to how much time they have budgeted for this - has this been consuming 50% of their time? 75%?
It's really hard for me to tell if this was a real problem for them, or if they were just working on other stuff because the competition is still non-existent.
It's probably tough to measure. I imagine most of the bottlenecking comes from communicating with external entities, which may not scale well by adding more Stripers to the task. I would be surprised if they could just pull a developer aside and say "Joe, you're off feature X. Go call up Canada and make things happen!"
While they probably don't feel external pressure due to lack of competition, I doubt they're hotdoggin' it because they are leaving money on the table.
I have yet to implement Stripe but PayPal's options without a monthly fee are downright goofy (and PayPal is the only other processor to have a no-monthly-fee option in Canada). "Buy now" buttons and IPN... eww.
Okay, now that I've officially implemented Stripe the official answer is dev time. PayPal took days to get a full solution implented (start to finish). Stripe took on the order of three to five hours. I can already tell maintenance will be almost non-existent in comparison and user experience is way, way better.
This is great news. While working with Stripe today, I noticed something a bit unnerving. The Stripe charge method will create a charge even if the CVC and the AVS fraud checks fail. It's then up to you to monitor this and reverse the charge if you feel it's too high risk (there's no fee reversal though). There are ways to get around this with custom development, but that doesn't help for people who are using software that's already integrated with Stripe. It would be great to see a fraud setting that would allow you to prohibit charges from going through depending on what checks fail.
So, if you create a customer, Stripe will check the CVC and AVS and return the results of those checks (Ctrl-F for "CVC and Address Verification Responses" on https://stripe.com/docs/api). From there, you can make a decision whether or not to create a charge for that customer.
Edit: To clarify a bit (and because I've got a couple minutes of free time), here's more details:
1. Create a customer, giving the "card" parameter with the CVC, address_line_1, and address_zip included. This can be done with Stripe.js, or whatever.
2. The returned data from the "create customer" api method will contain a "active_card" dict, with details as shown in the "Creating a new charge" section in their API docs.
3. Given this active_card dict, check the active_card. cvc_check, active_card.address_line1_check and active_card.address_zip_check values. From this, make a decision on whether to charge the customer.
4. If you've decided to make the charge, then create a new charge with this customer.
Thanks for the response and follow up details. I do realize that this is possible with Stripe, but when using software that already integrates with Stripe, doing additional custom integration is less than ideal. I would also argue that it violates the principle of least astonishment to have a charge go through when the supplied data is inaccurate.
I'm a huge fan of Stripe and find the API incredibly well designed which is why I was so surprised when I came across this today. It's certainly not causing me to migrate away from Stripe, it just means that I'll have to manually keep an eye on things for now.
It's worth noting that people often typo things like billing address or cvc code, and that the majority of these failures are not in fact fraud. At that point, it's also a usability question about what the best behavior really is. The banks do take CVC into account when deciding whether or not to approve the charge, and obviously also run their own (often aggressive) fraud prevention algorithms to deny suspicious charges.
All that being said, we're working on some tools to make this a bit easier.
Thanks Ross. I can certainly understand an address typo, but a CVC typo seems like a valid reason for denying a transaction. Glad to hear that you're aware and are working on tools to help us!
Your complaint is with the third party providers. Stripe's charge method does what it says on the tin: it charges the card. If your third party integration software doesn't expose a method to create and validate the customer data (which the Stripe API supports) prior to making the charge, ask them to fully support Stripe's API or provide you with a configurable option for what to do when the CVC/AVS checks fail.
That's certainly one way to look at it. In my opinion, Stripe should be the entity responsible for fraud management and not left up to the individual implementations, but I can certainly see your point of view as well.
The alternative is that you could end up with customers who constantly hit false positives in the fraud detection, and it becomes impossible to charge that person unless Stripe implements a way to "force charge" someone, and then you have to hope your 3rd party Stripe integration also supports and exposes that to you...
As a brief bit of background: these charges are accepted because card brands do not always decline if the CVC fails (and AVS has no effect); instead, they're taking several signals into account. We expose as much data as possible to give you full control (https://answers.stripe.com/questions/what-controls-for-fraud...).
That said, I really appreciate the feedback. We're actively working on better fraud controls that should be ready soon!
Thanks for the response. I use Stripe for 3 companies and absolutely love it! While giving us full control is nice, it doesn't help when we're using a pre-built integration, like an ecommerce platform that supports Stripe. In this case, we either need to re-write the Stripe integration or accept that we have no automatic fraud controls.
Agreed. I have a client reeling from fraudulent orders right now and looking to change payment systems. In order to suggest Stripe I'd need to show how he can set up his own rules within Stripe, e.g.:
- billing country/shipping country mis-match? DENY
- AVS mismatch or missing? REVIEW
- CVC mismatch or missing? DENY
- order over $X? REVIEW
- order from country in list X? DENY
Those are just the settings this client would prefer, but each user should be able to roll their own, regardless of whether they're using a custom integration or off-the-shelf third-party integration.
This and the mass pay option in Paypal is what keeping us from migrating. I was/am? still working on a better fraud model for Paypal that could easily be swapped out for Stripe given the similarities between the payment provider responses.
Not that I'm promoting Paypal's fraud controls in any way. They're terrible as well.
The way I see it now, Stripe made it easy. If they could lock down the secure aspect they'll run away with the game. Integrating with something like maxmind might be a good direction for them to look.
Edit: Just noticed the Stripe Apps functionality. It might suffice for an alternative to the mass pay functionality that Paypal provides. This just got a little more interesting.
There are a couple interesting differences between the US terms and the CA terms:
1) The CA terms say "you [...] will not use the Service to accept payments ..." while the US terms has the more-broad limitation "you [...] will not accept payments ...". I wonder if Stripe in the US actually cares about payments you accept using other services (seems unlikely).
2) Only the US terms ban "personal computer technical support" or "predatory products or services".
3) The CA terms have a broad ban on "any product, service or activity prohibited by one or more Card Networks".
I don't think that bans anything Twilio-based. I'd get in touch with their (usually very responsive customer service) before engaging, but it looks more like they're trying to prevent people from engaging in activities that could allow for anonymous calling.
Which kind if makes sense, if they're looking to never have to be involved in a lawsuit where someone uses said prepaid phone card or anonymous calling service to utter threats, plan terrorist attacks, or other random illegal stuff.
I'm a bit disappointed I can't use Stripe for my online, bespoke shotgun smithing company.
More seriously, from the way that's written (quite non-legally) it's clear they don't want undesirable business. If you're on the edge, I'm betting a simple call/email would clear things up.
(44) telecommunications equipment and telephone sales,
(45) timeshares,
(46) travel agencies or travel clubs,
(47) online or other non-face-to-face tobacco or e-cigarette sales,
(44) weapons and munitions
That's a risk category issue. Porn is categorized as 'high risk' and you need a different merchant account class and associated review procedure for that. You will also pay (sometimes much) higher fees, potentially you'll have to accept a hold-back period and there will be a periodical high-risk fee that you need to pay.
Is processing payments for porn sites so much different that companies that specialize in it exclusively are needed? Why can't a company like Paypal or Stripe support those merchant account classes and procedures?
It's all about the rate of chargebacks and fraud. I would hardly be surprised if your average porn site was subject to both frequent chargebacks and heavy use of stolen credit card numbers, if not both at the same time.
That and association. PayPal just doesn't want their name associated with stuff like that. It's hardly limited to just porn. Anything remotely sexual is rarely sold via PayPal or a major non-Adult-oriented payment processor.
It seems Stripe is ideal for a partnering approach - have national established payment processors hook up to Stripes backend (after a vetting/selection process, of course). That way they can expand quickly without having to internalize the many different quirks of payment systems across the world.
If there is a stripe beta in the uk sometime soon, we'd love to take part...
Is there anywhere we can join a waiting list for a uk beta? Perhaps it would be worth keeping a list per country of companies who are interested to judge demand?
This is a great step. I'm really looking forward to being able to split transactions with the Platform so I can easily create an Apple-like App Store experience (where my customers get 90% of whatever and I get 10% of the transaction).
It's also copyrighted, meaning that while you may be able to study the source and prepare your own implementation, you would be unable to use any of the assets. Open sourcing it would give you the legal right to use it verbatim according to the terms of whatever license they choose.
I don't think that's a feature anybody is pining over (with the possible exception of a very small percentage of end-customers who don't have credit cards).
Although a few web sites accept it (I think), I don't think I've ever heard of anyone actually buying stuff on-line with Interac. Anybody have any data to rebut that?
I did once use Interac for an online purchase. It was because the merchant required a "Verified by Mastercard" or some such which was impossible for me to get on my Canadian credit card without a Canadian address (I live overseas). It is a bit of an edge case, I admit, and I would still choose the credit card over the debit card most of the time, but it is once example where accepting Interac was a good thing for the consumer. Of course, I would have been happier if they just accepted my credit card without the "Verified by Mastercard" BS.
I used to pay for prepaid phone credit from Fido's website using Interac online payment. One time Fido's server failed right after the Interac server accepted my payment. As far as my bank could tell everything went through fine, but Fido had no record of any attempt at payment. I only use my credit card online now.
Right now for $1.50 or a monthly fee of $10.00 I can send an unlimited amount of money to a Canadian bank account holder. This would allow Canadians to pay Americans through their bank account.
But I made the comment really to highlight how forgotten Canada is even when it is remembered.
I'm currently on Beanstream with terms that were acceptable at the time (hard to get a Merchant Account) but are now completely unacceptable and am interested in a switch.
- 5% 6 month rolling reserve //
- 2 week + 5 day lag settlements //
- 2.8% blended + monthly fees.
Am I crazy to not switch, or should I present this to Beanstream and get better terms? Other than my terms, I have nothing but ecstatically positive things to say about BS.
Note: my terms are like so because of the nature of my business model. It is high risk, like a TPPA (third party payment aggregator). Think: Eventbrite.
Appreciate the feedback.
I say "High Risk" because that is how it was evaluated at the time. We have had our Beanstream account for over 6 months with zero chargebacks, a 100% clean record. If a Stripe rep appears here and makes an offer - jeff@goodnights.me - you have my business.
Great News! Have couple of questions though,
1. What are the PCI implications if I were to use stripe.js in my site? Will I have to get my application and deployment stack PCI verified?
2. I will have customers from both US and Europe, so what is the ideal approach to support multi currency so that customers end up paying the same (or close to same) price that they saw on my website?
It still does not let you charge in US Dollars (Yes I know the customer can pay in what ever currency they want). But from a Canadian business point of view where your large section of customers are from US. Stripe is still not a very attractive option.
Actually, you can choose to charge in either USD or CAD, but you can only choose one with your account. If you need to charge in both currencies, for the moment we recommend creating two separate Stripe accounts.
I often speak about Stripe here in France and nobody knows it. I hope it will come sooner than later because the market of credit card (well, debit card) charging only offer horrible tools (and the usual PayPal).
PayPal is really great. Buts it has oldish APIs and horrible documentation. Great to see promising services like stripe moving out of the US. Looking forward to see you guys all over the globe.
This is great news. We got into the beta for Canadian service and what a breath of fresh air. Goodbye, forever, Paypal, I look forward to watching your slow, sad demise.
I'm glad they address this before people complain about Stripe only moving to Canada.