1) Many countries still only allow depositing a single currency (i.e. Aus/AUD), doubling the cost of transaction due to the currency conversion, even tripling when we have to convert it back to pay our bills. I always get told either "soon", or "not possible due to the law", despite competitors doing it.
2) If we were an EU company, we'd get charged 1.4%+25c on transactions in the EU, where most of our customers are. Instead, because we're selling from Australia, we get charged 2.9% for some arbitrary reason. This coupled with 1) puts our all-in transaction fees at 5%+ :(
3) I think billing the vendor for refund fees is a really retrograde step - it increases friction in the decision for us when a customer asks for a refund, and industry wide is going to cause less happy customers and less card users online. It's already hard enough convincing Dutch/German customers to use a credit card online.
If any non-EU companies know a cheaper way to process transactions in the EU, I'm all ears...
On (1), we started an FX team this year. (There are a lot of legal complexities here around how the funds move, who has title to what at which moment, and so on.) But we're investing significantly in improving it and it should get better soon. On (2), the core issue is card network pricing rules -- by design, they discriminate on the basis of where the business is located. We happily extend EU fees to all EU legal entities, however, and would be happy to work with you to set that up. On (3), refunds aren't free for Stripe, and we were previously in a position where businesses with a lot of refunds were being subsidized by those who didn't. We want to give this margin away more sensibly.
Still, all the issues you bring up are real and I'd like us to find better solutions.
Customer Service, UX and speed are amazing. But it took me a while to convince US companies to accept this structure.
I hope Stripe which is amazing will never have anything to do with TransferFraud.
We've moved hundreds of thousands of dollars through them over the last couple of years with no problems on their end (we've had problems with banks failing to transfer correctly though..)
My only issues with TransferWise have been having to ask recipients for their full addresses and then manually having to translate address schemes into something that fits in the boxes TransferWise provides in their forms. Sometimes things don't map over 1-to-1 (some Japanese and Taiwanese addresses, for example). I've also found that some Japanese banks only have one branch without a name and Transferwise requires a branch name. I eventually figured things out by researching the branch number online though.
All minor gripes though. Transferwise has let my business operate smoothly and make connections to vendors that would otherwise be cost-prohibitive to pay.
OTOH, I'm in Canada, and I've only used them for personal transfers. I have no idea how they perform for businesses, nor do I know whether they work well for individuals in other countries.
I am biased, but IMHO using a service like Routefusion solves all of these problems. Companies like Elliot use our API's to settle CC transactions that are in different countries. You hook your Stripe account in and then they re-patriate the money to wherever it needs to go.
Check us out! developer.routefusion.co
I understand they're not free, but I also understand Stripe does get a considerable portion back that they are no longer passing on?
Couldn't this just have been applied to the problematic businesses then rather than all?
In our analysis in making this change, we saw that this simply makes little difference for the vast majority of businesses. For example, if you're processing $100k/year and refund 5% of your payments (which would be on the high end of normal), it works out to about $12/month.
While refund rate of course is not definitively coupled to the quality of a business, we do see across our portfolio that it is strongly correlated. Given a basket of possible fees (for example, higher fees on Amex, which most other providers have), we prefer the fees that, on the margin, are least consequential for the businesses that are doing the best job of serving their customers.
Having said all of that, none of our pricing is cast in stone, and we always genuinely appreciate feedback, including contrary views.
Stripe has made the right call here - though the silent and vast majority won't have anything to complain about so won't be on here posting.
Do you know how often I have people buy something and then call me only to let me know they may have bought the wrong thing?
If you ISL6258AHRTZ & ISL6259AHRTZ, your refunds are likely not due to "business quality."
If you sell NXP610A3B and NXP1608, your refunds likely don't "business quality."
They reflect reality in a world where most people aren't savants with random long strings of seemingly meaningless letters/numbers that make up product codes for chipsets.
I used to employ a competitor in this field. We have taken different approaches to obtaining customers, and in setting up our respective online stores to be as simple as possible - to try and inform people what fits what even if they don't know what they are doing.
But lots of people don't read, then they buy things by mistake anyway.
>While refund rate of course is not definitively coupled to the quality of a business, we do see across our portfolio that it is strongly correlated. Given a basket of possible fees (for example, higher fees on Amex, which most other providers have), we prefer the fees that, on the margin, are least consequential for the businesses that are doing the best job of serving their customers.
What metrics are being used here to judge the quality of a business? How is whether a business is "quality" or not being judged by a credit card processing provider? What information is obtained to make judgments according to these metrics?
I've been in different online and in-person businesses. Some businesses have low refund rate with poor quality, others high refund rate with fine quality. I can say with certainty 100% of the refunds I gave when people sent back a product that was not the product I sent them(or even a product I sell) after they filed a chargeback had nothing to do with the quality of our business - the only thing the merchant would have access to is a he-said-she-said list of jpg files and ranting paragraphs. Hardly fitting information to judge the quality of a business on.
Honestly, I've looked as Stripe's offerings - I pay 2.15% right now with 40/60 online card not present/in-store card present and refunds are free. How is it with a 2.9% fee that people who rarely refund their customers have to pay the fee for those customers for the model to make sense? I'm not asking Stripe to match the fee of a large bank - but can we not charge an additional .7 percent and then say "it has to be done so we don't lose when people refund?"
This is outside the greater implications of this policy - if more merchant services take this on, we will be left with a world where only Amazon, eBay, and Walmart can offer "cancel" buttons on their site. Who will want to do business with small businesses if even something as basic as hitting the cancel button incurs fees?
If I buy a TV, or an ultrasonic cleaner, or a stereo, or some furniture from a small business vs amazon and I mess up something in my order, I have to pay a $45 fee - but when I buy it from amazon, I don't? Screw them, I'll use amazon.
If this is adopted by every single business, it will be just one of many factors that pushes customers in the direction of using Amazon over small businesses. It's hard enough competing with trillion dollar companies as is without erroneous fees being added in that were outside the overton window of business discussion 10 years ago.
To be clear, I have no problem with people choosing to make purchases from Amazon. I do have an issue with the industry slowly adding barriers to small businesses having the ability to compete on a level playing field. I'm all for them earning a good reputation, but we shouldn't be working to put sour tastes in the mouths of every customer who f'd up and made an order in error with someone that they will not have with a larger company.
> They reflect reality in a world where most people aren't savants with random long strings of seemingly meaningless letters/numbers that make up product codes for chipsets.
If you're selling products to people who aren't intimate enough with the product to tell them apart, and not doing a good enough job of guiding them before they put down their hard earned money, you're failing your customers. So it is very tied to business quality.
You should have warnings, or clear break downs of product descriptions they can use to confirm.
-
A refund is not free for the user either, now they have to go and get a refund, hope they caught it quick enough for shipping, maybe ship it back.
So there is, almost by definition, no situation where you have a high refund rate, and aren't making your customers suffer, and that's not how a quality business is run
Patrick, please don't do that. It's scummy maths and unworthy of you. Either "if you're doing $8k/month it work out to about $12/month" or "if you're doing $100k/year it would work out to about $145/year" would be better. Using different units for the two different figures to make them look further apart is the kind of thing done by people trying to mislead with data.
Most people think of those kinds of expenses in monthly terms, maybe you're not aware of that. This isn't a press release, it's someone's comment off the top of their head.
This way regular members are not penalized by big refunders...
developer.routefusion.co
we will solve all of those nasty FX problems your customers are having. Already doing it for a few other e-comm platforms that link into Stripe.
However, Stripe offers SEPA direct debit, which is usable with any European bank account and may work better for you.
EDIT: This seems to have sparked some confusion. I'm not saying Germans don't do card payments, I was only speaking of credit cards. We do all have and use debit cards, however, those are of a national scheme with wonderfully low fees, but no online usability.
I have a credit card, but it is paid in full at the end of the month automatically, so for all intents and purposes it's essentially another debit card. Everyone I know in Germany who has a credit card uses it this way. In fact, my bank didn't even ask me if I wanted it set up any differently, so I have to imagine it's not just my social circle handling it this way.
Many UK banks used to issue Switch/Maestro cards which interoperated with the German bank card system so were accepted in German supermarkets, but these got phased out for Visa / MasterCard debit around 10 years ago meaning I had to start using cash everywhere.
When the EU capped the interchange fees in 2015, many retailers started accepting MasterCard and Visa here. AMEX is exempt from the regulation since it's a three-party system and less commonly accepted. I'm not aware of any retailers that accept MC/Visa debit, but not credit cards or vice versa.
How come Germany is so cash positive? Personally I think Sweden has gone a bit far, where some old people have been put in a weird spot where they can't pay because they're technologically illiterate.
As for why we're so cash positive: one of the factors is privacy. If you pay for everything electronically both your bank and merchants are in the position to build a profile on you. If you use a non-local scheme (e.g. MC or Visa), they can too.
I think the confusing part of your comment was where you consider non-credit cards (debit, prepaid etc.) to be distinct from VISA/Mastercard. That is not the case in most countries. It used to be the case in Germany, but is slowly changing as more and more debit cards are VISA/Mastercard cobranded.
which wouldn't be a problem for shopping online if they had a Visa or MasterCard cobrand, as these can be debit and tied to your bank account as well.
It's only slowly changing with some Sparkassen issuing MasterCard debit cobranded cards in late fall (https://www.f-i.de/News/ITmagazin/Archiv/2020/Einfach-mobil-...)
That's a peculiar choice, but I assume the decision was made to appeal to the typically skeptical German market. I do wonder why it wasn't made opt-in, though.
When asking around I got several answers. Everything from a cultural aversion to debt (and spending via cash makes it easier to track your spending), not wanting to be tracked where you shop due to not wanting the government to know (comes from Nazi/East German past), and just being culturally conservative and not really liking change all that much.
I didn't like it as being a tourist meant I was eating out a lot, etc. I had to carry a lot of cash around that I'd only have to pay a fee to convert back if I had any left.
Debit card means you're responsible and take money out of low/zero interest checking account at the principal bank where we Germans hoard our money.
Credit card means you're on shaky financial ground, deal with credit card companies with their fine print, risk punitive overdraft charges, and have probably no idea if you have any money left.
Sadly, things are changing and many people seem to take on irresponsible loans (i.e. for anything except real estate).
Associating Mastercard and Visa to credit and not debit as well.
Mostly banks and retailers colluding together to use a cheap domestic-only POS-only scheme (think Przelewy24, but offline or LINK but at POS).
In Germany, most banks still see these use cases as an opportunity to upsell their loyal customers on their expensive credit card products (not in terms of interest really, but rather because of high monthly and foreign use fees).
The interesting thing however, we A/B tested with and without SEPA and basically saw no difference. Only German people used it, but when it wasn’t available they managed to find a credit card or use PayPal.
I’d love it if banks were making instant payments simple and verifiable, but SEPA feels like something from the 70s to me.
These concerns still apply to direct debits, unfortunately. The reason being that there's barely any authorization for direct debits, you just need the bank account number and name. Isn't the situation somewhat similar to CC transactions without 3D Secure/whatever it's called? I seems to recall reading in my bank's terms that I can chargeback transactions for something crazy like a year. You always need a "mandate" to debit an account and if you get that properly signed by the customer, you should be able to get the bank to reverse the reversal, but I can appreciate the bureaucratic overhead.
I was only offering it as a potential solution if getting people to sign up is genuinely difficult.
The thing with PayPal is: they offer direct debit to customers and I'm assuming that's how most people who would've otherwise used direct debit directly with you ended up paying. It is my understanding that PayPal is also aware of the risks associated with this and offers merchants the option not to accept payments through it. I can't seem to find an article just now, but I remember instances where PayPal told me something along the lines of "this merchant does not accept payments via direct debit, please use a credit card instead". I can only assume this is because they at least partially pass on the risk.
That's unfortunately not true. There is no recourse to direct debit returns; there is no dispute resolution process or anything like that. The presence or absence of a mandate only impacts the timeframe for returns to be files, as far as I understand.
You are aware that this is possible with credit cards as well, right?
1) SEPA has an 8-week no-questions no-appeal refund model, which is fundamentally incompatible with a SaaS business
2) Stripe doesn't support SEPA on Checkout
3) Stripe doesn't support SEPA on non-EU/US accounts
Regarding 1): is it? Credit card payments can also be charged back, often for a period longer than 8 weeks. And both "aaS" products as well as certain retailers selling and shipping physical goods, do offer direct debit. I can't quote any fraud rates, but it certainly seems possible to do it.
SEPA doesn't. You have to sue your customer if you want the money back.
https://www.williamfry.com/newsandinsights/news-article/2013...
This used to be very common in supermarkets. Every time you had to sign the receipt this was happening. It's not as common nowadays as the fees are now more or less the same.
A lot of subscription based businesses were built around "no-hassle refunds" as a core feature enabled by Stripe and will now need to rethink this.
I deal a lot in USD as an Australian company but stripe won’t allow us to charge in USD and settle into our USD bank accounts. But others will.
Also the refund issue is crazy, no other provider we use does it.
By the way, my company has the opposite problem. Our Stripe account is registered in the UK and even though we process payments for Australian customers in AUD their local banks still charge them an extortionate "foreign transaction fee". This means that we had to open a separate Stripe account registered in Australia just to avoid that.
We charge in USD because we serve primarily US customers.
I pay for the business expenses in USD.
I've opened a US/USD bank account with Transferwise.
But I can't use it with Stripe [1]. Their only choice is to have them convert our USD earnings to AUD and pay out to an AUD bank account.
So when I pay those business expenses, I'm either:
a) paying on an Australian debit or credit card, which charge us another 3% for every international transaction (3% seems to be the standard rate across all of our banks here), or
b) carefully managing our cash flow to transfer AUD to our Transferwise account, use TW to exchange to USD, and then pay with our TW card.
We did (a) for a while, now trying (b), but I'd love to see (c): Stripe pays our USD earnings to our USD bank account.
[1] Funnily/strangely enough, I can actually ADD the USD bank account to our Stripe account. It just sits there, lonely, with a 0.00 USD balance. It took reading through the docs to realise that USD payouts are not supported for Australian Stripe accounts.
Depending on your volume, it's really not expensive to setup a legal entity in the UK. Since UK is leaving (unsure if EU financial access will continue) Ireland is a good alternative. A UK company costs < £100/yr to maintain. Depending on your volume, it may be worth exploring with your lawyer/accountant.
Perhaps there's merchant-of-record services too, that are incorporated in the EU and I believe legally act as an agent to sell your product.
A UK company costs < £100/yr to maintain
Off the top of my head, the Companies House filing fee of around £15/yr, an address for the company (around £50/yr) are all you require to hold a UK company.
For a tech company that uses Xero and feeds in invoices programmatically filing the statutory returns by an accountant might cost £1000/yr (or 0 if you wish to DIY, the UK's HMRC makes self-filing easy unlike the IRS). Plus £360/yr for Xero (free accounting software probably won't cut it).
VAT returns and PAYE returns are pretty easy to self-file; Xero does them automatically and HMRC provides free software for it. The annual statutory accounts are more difficult, and you probably want an accountant.
Rough figures: if you want to be cheap, use Xero discounts and DIY, it's around £500/yr. With an accountant, but you still doing some of the work, perhaps £1500/yr.
Care flicking me an email at [email protected] or DMing @StripeAustralia?
We are one of the larger SaaS companies and as a personal lover of Stripe, it was surprising to me that you couldn’t customise these systems, esp at our volume.
We switched to Ayden and saw very significant revenue increases in those countries; because valid cards stopped getting declined.
I used the "beta" react hooks integration, and the UX of getting it all set up was basically flawless. I found the documentation (especially the quickstarts/tutorials) to be incredibly helpful.
Four pieces of constructive feedback:
- There seemed to be 3 or so quickstarts/tutorials for the same developer flow, at varying levels of detail (good), but they all had similar names and were difficult to distinguish from each other. My impression was that they were built on top of each other (i.e. one was X years old, another one X-2, etc.), but the old ones weren't removed? Unsure.
- I found the API documentation to be very good on big screens, but relatively painful on smaller screens.
- On my personal laptop (an older thinkpad), scrolling through the docs was unresponsive at times. In general, I'm a fan of the "everything-on-one-page" approach, because it makes grepping the docs easier. But I think that the quantity of dynamic elements in the API interferes with this approach :/
- I don't appreciate applications that hijack ctrl+f. I appreciate that you can double click to get native browser search, and that this is explained in the modal, but I really wonder if this helps people navigate more efficiently. I appreciate that the work that's gone into this feature must be very impressive, but I'd prefer a search bar with a different hotkey than ctrl+f. Might be worth AB testing.
Ending on a note of praise, the dashboard experience is incredible. Huge kudos on how far it's come, and how easy it is for nontechnical people to use and discover.
Second this. Stripe's documentation is generally great, but when looking for recipes/tutorials you run into a lot of seemingly duplicative content which makes it confusing to figure out which is right for you. I had this issue trying to create Connected Payments, specifically.
Eventually I just picked one and it seemd to work out really well though. I've also recently been working with the slack docs and they're the total extreme, 8 different guides with similar names and various different deprecation notices around.
On the upside I felt like having both recipes was really useful to get a good overview of the options and possibilities. I'm really happy with my implementation now and I don't think slotting in Connect should be too tricky. Using the stipe docs was a breath of freshair compared to the Slack api docs which I've been using recently and have been an abysmal experience filled with hundreds of open browser tabs.
Not something I'm likely to be looking at in the nearish future, but the next time I need to do some refactoring/rolling out a new Stripe feature, I'll definitely drop you a line with my thoughts. Thanks for the heads up!
One thing I'd love you guys to do is create your own QuickBooks connection app. Most companies offer their own - yours is through Sush.io with your logo and bad ratings. I can't get it to work and I'm not the only one.
What are the strategies/thoughts in the industry? Holding and batching payments on a per-user basis? Trying to get agreements so you can batch payments on a per-processor or per-network agreement? Hourly? Daily? Weekly?
That's pretty much the story :-). And so the questions are then whether we subsidize the transactions, batch them (as you say, though that makes refunds and statement descriptors tricky), get card networks to change their policies, or somehow shift how the payments are made (e.g. encouraging cheaper payment methods).
The various US credit card & processing companies have an extraordinary thing going for themselves. Visa and Mastercard have cartel-like margins (Visa's operating income margin for 4Q19 was 66%, you don't see that outside of maybe illicit drug operations or Facebook's monopoly in its earlier thinner incarnation pre-Russiagate). They're super sensitive to giving any ground on their fee levels, out of fear (correctly so) that they'll never get them back.
Before the market drop, Visa was worth more than all publicly traded banks in Europe combined (frankly that may still be true post market drop, as Visa hasn't declined all that much).
Visa etc are now only allowed to charge a percentage, 0.2-0.3%, but the intermediate (Stripe etc) can still add a flat-rate fee.
If Stripe were willing to allow third parties to act as a batching passthrough (or if I was wrong and you do!), this seems like a low-cost way to let the market decide what an acceptable refund/statement descriptor regime should look like.
Maybe batch them per user per website, that will solve statement descriptors a bit
Payment requests are accumulated and batched, combined with "capping" of travel costs (eg max/day, weekly discounts etc).
I haven't used a debit card in years to maximize benefits (altho I sometimes use cash when required by small businesses), but the Capital One debit card advertises $0 Fraud Liability https://www.capitalone.com/bank/debit-card/.
This also makes me more aware of my spending, since I need to manually keep topping up the account.
Faster checkout. And improved trust (somehow).
I hear you folks acquired fast.co which seems to be a step in this direction. Entering card details on every site is problematic. Some customers are still worried about it and prefer to use PayPal. Indeed, when I offer both as an option, and make clear Stripe payments go via Stripe and we don't see details, about 80% of people choose to pay with PayPal.
Stripe Checkout, being on your platform and not our sites, seems to be a step in the right direction. I'd also like to see faster payments. My opinion: checkout takes too long. Sites making people create accounts, go through 4 pages and then enter card is bad.
--------
I think, honestly, integrating fast.co into Stripe and making it highly encouraged is the future. Go a step further and encourage sites to stop making users create accounts. SSO-style system, perhaps, but easy to integrate. Authentication is a pain for me as a customer on sites - I have too many accounts and it drains a lot of time combined. I really think your company has the power to make a difference to this problem.
1) Stripe docs are inaccurate. They frequently don't work exactly as they describe for given subscription workflows. Sometimes an API call is entirely wrong, sometimes it doesn't return the data the docs indicate, and sometimes the arguments it describes just doesn't exist. (Yes, I've ensured I'm using the latest API version in use).
2) The docs have no changelog. There's an API changelog that indicates when API's change, there's nothing indicating when entire chunks of the documentation change on the website, along with the recommended way to integrate. The most obvious example of this is that the subscription workflow docs got a huge makeover in the past year (sometime), with some really great flowchart diagrams. But back to point #1, some of the API calls listed here are not actually valid. If I've just missed the changelog for the website docs, please point me in the right direction. :)
For reference, I'm using Node at the moment, but I've also integrated with Python, and there were breaker bugs in those docs as well. I eventually end up reading the HTTP API docs, then going through the SDK's to see where they went wrong, or the docs went wrong.
It would be great if Stripe Checkout included VAT-related features:
* Detect country and - if needed - add appropriate VAT
* Allow customer to add a valid VAT number, so that when appropriate tax is not charged
* Offer clear reporting on what VAT has been collected for each jurisdiction
I realise this is a big, big can of worms. But that’s why we use Stripe, right? For help handling that big can of worms that is international payment collections. :)
But I've been asking Stripe for this since 2015. I don't know what info I can possibly offer you that you surely haven't heard from tons of customers over the years.
The only reason we are not using Stripe is the lack of support for Finnish payment methods - around 70% of our retail website customers pay using the local "bank buttons" and 10% use local mobile payments (MobilePay, Pivo).
Either way, thanks for the feedback!
To explain where we're coming from here, I personally learned a classic first-time entrepreneur lesson the hard way some years ago: if we're not a payments business then we should focus on what we are, not on payment mechanics.
The first time I started a B2C, I naively thought I could do better, and to be fair, I really did implement a simple, robust, flexible system that fit our needs well. But over time, even the better payment services started breaking APIs and neglecting documentation and dropping customer service standards and increasing prices, and maintaining those integrations became painful. Governments started changing their regulations and tax rules, and updating our systems to keep up with the ever-changing compliance and tax obligations become painful too. We also found that fraud and chargebacks weren't a significant problem for us, but surprisingly, churn due to unreliable card charges was unbelievably bad and could turn an otherwise healthy growth rate negative all on its own, which was not a good combination with the aforementioned drop in standards at the payment services.
What we're now looking for, in a nutshell, is a service to which we can outsource payment processing, subscription management, and all of the sales tax collection, reporting and remittance obligations. I don't want to use APIs or webhooks any more than I absolutely have to. I want to fill in correct, context-aware, all-inclusive prices on our pricing page with ideally one line of code. I want to hand our customers off smoothly to a well-designed, batteries-included sign-up flow with ideally one line of code. I want a simple notification to reach my server when a customer has paid us so we can have our systems respond accordingly, and I want simple notifications if anything has gone wrong so we can contact our customer or payment service and deal with it.
I do not want to know what the current sales tax rates are in Western Nowhere, Somecountry, and I certainly do not want to have to sign up for a government programme and file reports and remit taxes there because once upon a time we had one customer who signed up for one month and we collected 1.50 Nowheredollars in sales tax.
I do not want to have any UI on my site and therefore any code behind it for upgrading, downgrading, cancelling, refunding, retrying failed charges or sending flowers on my customer's birthday, except to the extent that we provide a simple way for a customer to indicate they want to do something and we can then hand off the mechanics to the payment service if we agree, again ideally with one line of code.
I do want a simple, effective dashboard facility on the payment service that lets me see and control all of those things (well, maybe not the flowers) and any other relevant settings if I want to, and I want it to be somebody else's problem to implement and maintain that facility.
I don't know what proportion of our revenues we'd be willing to give up for a service like that, but it would be far higher than anything we pay to any payment service today.
Then we read their legal terms, found about half a dozen obvious deal-breakers, and lost all interest.
1. reserves the right to unilaterally vary the contract in any way, with immediate effect and without actively notifying the merchant
2. ensures that if anything goes wrong, any legal action against it by its merchants would have to be taken in another country and under another legal system, even if Paddle operates in the merchant's own country
3. takes extensive control of the product or service they are selling on their merchant's behalf, to the extent that they can sell it to whoever they want, sell it at whatever price they want, give demos to whoever they want, etc.
4. requires that any software it is selling on behalf of its merchants be bug-free, and that the merchants accept liability for anything bad that happens if it isn't.
It's hard to take any service seriously when it has terms like that in its standard agreement. Unless these kinds of terms are unenforceable where you are (or where Paddle is, given the above?) and you have a legal opinion telling you so that you trust enough to bet your entire business on it, it seems like you'd have to be crazy to accept them.
I've seen some very one-sided terms from other payment services before, but I take them at their word that those terms are typically required by the giants behind the systems like the card networks and banking groups. I think some of those should be also be unenforceable by law, but right now that seems to be the price of admission. I've never seen anyone else seriously suggesting the kinds of terms that Paddle is, though.
Edit: Changed to present tense, after checking Paddle's legal terms of use at the time of writing at https://paddle.com/legal/ to confirm that these criticisms are still current. The first two points above are in the preamble at the start of the document. The third is under 4.2 and 6.1. The fourth is under 13.1(ii) and 13.2(ii).
That might have been the intent, but I see nothing in the terms that restricts the scope of those I mentioned to that situation.
And the general "we can change anything we like and you can't easily sue us ever" would be inappropriate even in that situation.
I assume their legal teams have scoured through Paddle's terms of use
I respectfully suggest that this is an extremely dangerous assumption when you're talking about a binding legal agreement and the future of your business.
I've occasionally had a real lawyer look at the terms for some very popular online services that we were considering using, particularly when I thought they looked risky, and received formal advice along the lines of, "Run away. Don't walk. Run."
Chargebee does this on top of Stripe.
(There are hacky workarounds - but likely not worth the effort)
We had one hick-up, which was the fault of a wrong PHP setting and we got several duplicate orders as a result. In the stripe dashboard I could clearly see failed webhooks in the post mortem. So if there were some kind of email alarm if an error threshold is exceeded that would be nice. I did not find any such feature, if I should have missed it please point me towards the right direction. Cheers.
There must be hundreds (thousands?) of apps using this integration and all of them have been stuck in limbo for many months now. We would like to enable SCA, but the beta version of this project doesn't seem to have documentation beyond a few comments in github issues here and there, and the discord is almost solely populated by people asking how to use the beta and no one can answer them.
I think whichever of the major payment platforms extends a hand out to the React-Native community first, with a confident, well documented official project, will be celebrated and would cement themselves as THE payment platform for people using React-Native.
@chris_trag from Stripe here. The React Native situation is very much top-of-mind and we're working on the right lasting solution for your business and the RN community.
When we had submitted the PRs to provide 3D Secure / SCA support, we had not anticipated the work would be left on an experimental branch for this amount of time.
This spring we've been able to connect with the previous maintainers and understand the business situation behind this community repo. With all things open source, we want to be mindful of projects that are run by the community while determining which key libraries not in active development/maintenance.
All this to say, peace of mind and clarity on how React Native devs can implement Stripe with ease is a priority and I apologize for the limbo you've been in.
Thank you so much for your patience as we pull the remediation together.
Happy to chat directly as well -> trag at stripe dot com
The company I work for is in the travel industry and we've received a large number of charge backs compared to normal. Our agents are working as best as they can, but our tools were never really designed for 5000+ tickets to be active at 1 time, so it's slow going for them as they contact the guest, then contact the provider, then talk to the guest, etc.
Are you going to offer some lenience to companies who have gotten a huge spike in charge backs just due to an increase time in support tickets?
We are trying to find ways to just refund the guest where we know the hotel has closed, but there's no master list of that so we can't just blindly refund everybody
Many companies in travel (and similarly affected industries) are having challenges shaped similarly to yours. There is a very active conversation in the industry about what we can do about the standard process for chargebacks to support this better. (Chargebacks were never designed to be a massively high-volume simultaneous event.)
Concretely you could imagine some specific consequences of chargebacks. I don’t have anything specific that I can share as of this exact minute with respect to each of those concrete consequences, but we’re working on this very actively. A lot of this work requires coordination with other firms. Chargebacks are broadly adjudicated by banks with reference to the rules established by the card networks, so we have limited control over per-chargeback decisions, but the industry is moving quickly on trying to decide what to do about this sort of chargeback given the circumstances.
As always, we’re in the corner of companies trying to do the right thing. As you get through this, if there’s specific things we can help on, please flag them to us; we can’t promise saying yes to every request but we can promise you’ll have our attention.
So much so that we are actively implementing a new provider as backup so we aren’t stranded if we get cut off.
"Since US Covid shutdown (as of March 13th) Stripe US processing volume is up X% or $Y billion."
This general information would provide great context to the health of the US economy and e-commerce. I know other companies such as payroll processing (ADP) release numbers and the stock market uses those as an input to the health of the economy.
Based on many support conversations with me trying to get a feature built here over the last year, Stripe's "official position" appears to be "never test your production application." Sometimes they say "do it but only for $1 every other month", which is functionally the same as saying "don't ever test production." if you don't have any products or services for $1 and do regular deployments.
I understand the reasons why you don't want people using live credit cards to test in production (e.g. factoring), but that isn't what I think most users want to do (it is not what we want to use). We don't want to use real cards at all but we want to test production.
The best answer to customers who want to test in production is to give them the ability to safety test live cards. Please see the attached specification I pulled together which would solve this problem for Stripe, card networks, and your customers. If Stripe cannot implement some feature like "Safe Live Testing", then we will ultimately be forced to migrate away from Stripe. This is a critical feature for us, and I am sure many customers.
https://tidy-static-websites.s3-us-west-2.amazonaws.com/Stri...
We thought our integration with stripe was down in production last week, and we could not run any checks to tell if that was actually the case. This would have fixed it for us.
I think there is also a cultural issue here because I believe any mention of "production testing" is currently falling in the compliance camp of Stripe. Which means their job is to prevent fraud, but nobody seems to say "its ok to want this. The response every time from support and compliance teams is basically "you are bad to test in production, never do it." But they instead should say "I totally understand why you would want to test your production site. This is a gap on our side, and we should fix it." If there is an issue with Visa/Mastercard agreements or something, then they should say "I totally understand why you would want to test your production site. We are completely unable to support it because Visa has this rule that says X, we are working with them to change it. Here is how you can contact Visa to express your support for the rule change, we are spearheading a campaign to ensure customers can do this."
I hope this feedback is helpful, and while the "spec" is not very good, I did put substantial effort into thinking through a solution here, so I hope you review it and get it to the right team. I will also email, thanks!
Many of our customers prefer this method over card payments. Then Stripe would fully cover our payment use-case; I'd love to use Stripe alone for payment, analytics and security. Right now we can't :(
I imagine, with the huge spike in ecommerce, your platforms are crushing it, but curious to hear your take.
- Enterprises pivoting -- brands going direct-to-consumer, malls pivoting to online business models (seriously), and other things like that.
- SMBs going online: see this thread[0] from a French fruit seller, for example, or this thread[1] from a bar in Milwaukee. The restaurant down the street from where I used to live is now running a rapidly-growing online wine club.
- Totally new startups are getting started in response to new needs.
[0] https://twitter.com/FlorentSchmahl/status/125028359535832678...
[1] https://twitter.com/danimalnelson/status/1240004111669460992
Will you continue to originate new Strike Capital offers? When?
If someone makes a purchase of a $1500 ultrasonic cleaner from me, and then realizes they made a mistake, I now have to tell them there’s a $43.50 restocking fee, even if they call me 2 minutes after they place the order. This will leave a disgusting taste in the customer’s mouth, but I have to do it, because I can’t expose myself to a $43.50 fee for something I have zero control over. That customer may eventually notice that Amazon, eBay, Walmart, etc, do not charge such a fee. The customer has no idea why – they just know dealing with Amazon means less friction. The customer will now utilize Amazon more.
Many will say that this is a dumb gripe. “If you don’t like it go somewhere else!” PayPal instituted this policy as well. They backed down temporarily after people made a stink about it, but months later continued forward with the policy. I currently use a merchant services provider that does not implement these fees, but for how long?
My time in my industry has taught me that companies will often wait for one “outlier” to make controversial reforms to their platform/products before doing it themselves. Whether it is gluing the battery inside of a cellphone, or adding strange fees to transactions. Once a profitable, anti-consumer move succeeds with the company not going out of business, it emboldens other firms to do the same.
My merchant services provider doesn’t charge this fee. Yet. But they saw Stripe charge it, and get away with it. They saw PayPal charge it and have another more profitable quarter. The outrage lasted a week, the increased profit lasted forever. “Gee, it isn’t a business killer after all. Maybe we should do it too!” will come up in corporate boardrooms across America.
Then, we’re left with a landscape where the only companies left in ecommerce who can offer customers friction-free order cancellations are Amazon, eBay, and Walmart. Who wants that? Yes, people can say “just absorb the fee if you don’t want your customers to be mad at you.” How? I am already competing as a dude with no outside financing with a trillion dollar company – I’m winning if I am making any sales at all! Now I’m expected to compete on price when I have to absorb fees when customers cancel an order?
Let’s say you manage to claw your way into a market by offering a better product, or after sales service on that product to the point where you can compete with Amazon. That is a miracle in and of itself. To then have to deal with a minefield of additional charges that your competitor doesn’t have to is just another nail in the coffin of small-business ecommerce.
I find it awful, and I protest using these services. I cut my exposure to paypal by about 95% and dodged a bullet in not signing up for stripe. I suggest the same to my listenership anytime someone brings up or mentions a merchant services provider that I know charges this fee. Even if they say it won't affect their business much because they do not deal with lots of cancellations, it is the greater implication I make them aware of. No one wants a market where the only companies with a free "cancel order" button on their site are eBay and Amazon.
Scott Galloway also has a lot of excellent content with arguments on breaking up Amazon. Whether or not one agrees with his solutions or assessments of the problems Amazon creates and how to fix them – it is clear that they are dominating the race. I am not suggesting that we hold Amazon back – just that we don’t purposely trip companies doing their best to keep up.
I'd like to add a few points, especially those considering Stripe vs Paypal
This: Billing through PayPal is playing with fire. They can and do freeze accounts and it can take months to get the issue resolved.
We are very thankful to Stripe because Paypal left us high and dry
We found out they were calling up our customers and pretty much forcing them to do disputes
They also locked our funds FOR SIX MONTHS
If we did not have backup funds and if we did not have Stripe we literally would not be able to continue as a company
Paypal basically have ZERO consideration of the fact that you are running a business and that your payment provider should not just randomly end the business arrangement
Our dispute rate for the last $1.5 million processed through Stripe is roughly 0.3% whereas with Paypal it was considerably higher. I even have saved emails from our customers of Paypal asking them to open disputes even when they said they were happy and did not want to
Even eBay stopped using Paypal, and switched to Adeyn
consider how extreme things have to be if the company from which you were spun off as a separate company (eBay spun off Paypal), even they stop working with you
Stripe is much, much better than Paypal
Most importantly, it is much more dependable, much more small business and startup friendly, and developer first mentality
Paypal always has the attitude of - We're big and we don't give two hoots about you
Whereas Stripe they will always talk to you as a fellow human being
*
Stripe: The CEO is coming here to Hacker News and personally responding As are various members of the Stripe Team
Paypal: Will freeze your account for no reason at all. Will not even respond. The lady on the phone will shout at you even though you are politely asking why account is frozen. Plus as a bonus they will freeze funds for SIX Months
They froze funds equal to TWENTY TIMES the total disputes and refunds combined total from the Past 5 years. For SIX MONTHS
Also, if anyone at PayPal reads it: screw you, I will never give you a damn cent.
That said, we've seen a big spike in signups over the past few weeks. If any HN readers have integrated recently and have feedback, we're always eager to hear it. Feel free to email me at [email protected] and I'll route to the right team(s).
As always, thank you to the many HNers who are also active Stripe users!