Having paypal available within stripe integration would simplify a lot of things (not sure if it would really help save cost), I think Stripe has already made this possible for Europe. It is probably coming soon for the US as well
True, we have seen people really liking this feature. Although, the adoption numbers are not public there seems to be a positive sentiment around it. Hence, having this is in our product suite makes a lot of sense.
I wouldn’t hold out on paypal coming to US Stripe integration. I believe it’s available in Europe because of legislation requiring Paypal to support this.
I don't think it's because of regulation. PSD2 related open-banking regulations are broadly about letting customers have access to their bank's functions via API.
> PayPal enables XS2A use cases for TPPs through PayPal’s REST stack. Through PayPal's reliable and proven APIs, TPPs can access the same PayPal systems that power all of PayPal's merchant and consumer experiences.
Stripe isn't a TPP and even if it were to use an external TPP (Tink, Truelayer etc) to allow users to initiate a transaction from a user's PayPal account (similar to A2A transfer), it would be significantly "less integrated" of an experience. There are many problems with the UX around Open Banking A2A payments and it would harm conversion. Because of these reasons, I think it's a bespoke integration/deal between Stripe and Paypal
Based on other commenters, it seems like PayPal was widely preferred as a payment mechanism in Europe, so Stripe had to offer it to remain competitive.
That competitive pressure isn't nearly as strong in the US, and Stripe would be loath to be sending money to their direct competitor if they don't have to.
> PayPal’s goal of acquiring customers gets in the way of user experience requiring them to collect way more input fields than Stripe on their card payment UI.
Isn't this a consequence of different rates the card processing networks charge dependent on how much data you provide? Like, only a CC # pays the highest rate, CC+CVV or CC+Name pays a bit lower, and the full set of CC+CVV+Name+Billing address pays the lowest rate?
For B2B transactions it's possible to unlock lower interchange rates by providing L2 or L3 data (this data is more transaction-related though and not the customer billing address, CVV, etc. mentioned above).
Looking at payments for Pinboard for this year, it's about a 50/50 split between Stripe and PayPal. Integration with the latter is painful and unpleasant compared to Stripe, but there are a lot of users (international users especially) for whom Stripe is not an option.
I also like not having a single payment provider have the ability to cut off my revenue if some kind of issue arises. For that reason I would avoid integrating PayPal via Stripe even if that option were offered.
I would like to have multiple options for that reason, but right now we have Stripe integrated with Taxjar (Stripe owns Taxjar) which handles all our sales tax calculations and filings. If we add paypal separately, that would throw a huge wrench into that whole system, unfortunately.
Stripe supporting paypal in Europe does not seem to be a customer driven decision. Both Stripe and paypal are not as big as they are in the states so they are probably more willing to collaborate here. I doubt they would be willing to work together in the US.
In the early years of ListenNotes.com , one of the most impactful decisions I made was to integrate PayPal, in addition to Stripe. It's true that PayPal's integration process is less developer-friendly; I had to devote considerable time and energy to comprehend the intricacies of PayPal and Braintree, and there was a substantial period of trial and error. However, once completed, the system has proven to be impressively robust. In fact, I haven't had to modify the code for around four years.
The outcomes have been more than satisfactory:
- When it comes to Listen Notes, PayPal dominates as the preferred method of payment outside the US.
- In terms of managing chargebacks, PayPal has significantly outperformed Stripe for us. With an approximate win rate of 100%, it far exceeds Stripe's virtually zero success rate.
This experience underscores the need to look beyond initial developer convenience and consider factors such as global user preferences and chargeback management. Despite the initial time investment, the long-term benefits of integrating PayPal have been remarkable.
What do you mean by "day-to-day operations with multiple dashboards"?
I seldom log into either the PayPal or Stripe dashboards. I've developed several integrations into our internal tools to streamline processes. For example, these integrations allow us to view all payment transactions across different platforms and handle refunds.
Both PayPal and Stripe have been configured to automatically deposit payouts into our company's bank accounts each day. This feature initially required us to contact PayPal to enable it (via PHONE CALL!), while with Stripe it could be activated with a single click.
> consume a significant amount of your dev efforts
If managing revenue is a core component of your business, as it is for most non-startup companies, in-housing a handful of API calls then transforming storing and visualizing the data is a worthy investment.
As the OP indicated they've barely had to touch it for 4 years. A couple weeks of effort and a few hours of maintenance here or there can be superior to another ephemeral third party vendor that can grind your core business to a halt with an outage, acquisition, pricing change, etc.
As you accrue more experience in the software industry, whether as an engineer or a technical founder, it's not as though you become capable of writing code ten times faster. What truly increases isn't your typing speed, but rather the leverage you gain from developing an intuition for discerning what to build versus what not to build, as well as what to purchase versus what to create from the ground up.
Furthermore, the situation isn't always black and white. There's a middle ground. Initially, you might lean on third-party solutions, gradually replacing them with in-house solutions bit by bit. You may even find yourself with a mix of in-house and third-party solutions. There's no need for it to be an absolute 100% in-house or 100% third-party solution. You could have a 49% in-house and 51% third-party mix, or perhaps an 80% in-house and 20% third-party split.
There are no standard templates to follow. It's all on a case-by-case basis. However, a general principle I found useful is that the more closely a decision ties to revenue generation, the more control you should ideally exert over it.
I use PayPal when buying digital products priced in USD because local banks approve those transactions automatically. When I try to pay via card directly, I have to call them to enable those transactions which is a hassle. It's not surprising PayPal is popular internationally.
Stripe is great in some ways but definitely far from perfect and I've spent many hours chatting with support for multiple clients, and while it's cool you can instantly get someone to start chatting with you, not all the support agents are equal in understanding. It's also cool that their API has so many options, but sometimes I feel like there's so much there that it's hard for their docs to keep up and you can get lost in the weeds occasionally. So recently when I saw the Jumpstart Rails guys were mentioning Paddle, I wondered if paying a premium would be worth it for something that's more of a "full-service" option. For a long time, many developers have been scared away from Paypal, but when you are focused on solving business problems, what looks most awesome to developers (Sripe) isn't necessarily what's most awesome for cutting to the chase on solving business problems and handling things that are going to cost the business more in the long run, e.g. Paypal or Paddle going to bat for you, or like when Paddle handles some other financial minutiae that they're good at such as handling taxes internationally, etc.
I have a side business ~1k€ MRR (~3k€ total if including other payment methods) on paddle and I have more weird issues with customers not being able to pay or having issues with payments. I had to create a yearly plan just so that people wouldn't have to face issues every month.
Fees are a bit higher than stripe (but not that much, especially if stripe charges you forex conversion fees).
Not dealing with european taxes is great and completely worth it (my side business would not be viable if I had to do vatmoss accounting, F U Europe).
Refunds are on them which is nice.
Api integration was significantly worse than stripe.
They didn't migrate customers from stripe because I didn't have enough customers.
They seem to be technically poor but it's a good business idea.
I hope this is not costing me customers, albeit I have other ways people can subscribe to.
So... a mixed bag. I'd try lemonsqueezy if I were you.
Revin looked great a few years ago but it's quite pricey these days for small businesses.
I can understand using PayPal if it's an option because you can't be bothered getting your card and typing in.
How many people would not do a purchase just because of this? It's a non zero number but I'm not sure if it warrants their fees.
I hate PayPal with a passion (I get paid with PayPal and I know how shitty is the other side) so I try to make the effort and use my card to not give them money.
We have a Stripe-based store and I "integrated" PayPal by simply sending users to "paypal.me/<username>/<price>" after checkout because I didn't want to deal with PayPal's full integration with webhooks and stuff. Unfortunately it is very popular. Users love PayPal. I will probably need to do a proper integration eventually.
Genuinely surprised to hear all the love for PayPal, recently. I don't use it much these days (did, years ago but found the experience fairly neutral) but remember a period of everyone seemingly hating PayPal because... I actually don't know? Maybe something about niche cases where it was harder to get them sorted out via PayPal vs other services (which I can imagine to be annoying)?
Consumers love Paypal. Its easy and fast no hassle. Business owners hate Paypal. Too much commission, random account suspensions, locked accounts, too much consumer protection and more.
Getting ganked by one processor for excessive risk/chargebacks and ‘instantly switching over’ to another is guaranteed to get you some real quick ‘fuck around and find out’ business lessons.
Does anybody actually use PayPal, deliberately, as a 'digital wallet' & like and want that to continue? That aside, I assume just for card payments Stripe has at least as many card types built-in as PayPal offers?
What is the source of those numbers? Those don't match my reality at all or what I've observed when I've provided Apple Pay and Google Pay (normally it's 70% Apple, 30% Google).
I'll have to be be forced to implement PayPal and thankfully, while it's been asked for, I been able to say no in all my projects. My audience is domestic-only (US) and since you can put a card on file easily or use Apple/Google Pay I haven't heard from any customers asking for it (only organizers that pay for the software, and only off-hand). If anyone were to push I'd just quote an absurd number to implement it.
I know Stripe isn't perfect/flawless but I'll do everything in my power to avoid doing business with PayPal.
It probably comes down to how many have actually added their cards to GPay and Apple pay, best to experiment and check if adding paypal improves your conversions
Uh, might be really bad timing on that integration there, as indeed PayPal has been a major missing option for Stripe for a very long time.
But that actually changed extremely recently. PayPal is now fully supported with Stripe, even payment settlement happens in Stripe, Connect is supported etc.
Its availability is limited - based on the merchant's Stripe account. It's not available in the US yet, but I can't imagine it'll be far behind. For EEA + UK + Swiss Stripe accounts, you can accept PayPal for US customers
It seems that it was launched very quietly, not crystal clear why. Maybe PayPal are trying to avoid cannibalisation of their own payment processing services
Had to wait a few days for recurring/subscription payments to be "approved", but going great since then
We noticed is that it doesn't expose any info about the region/country of the connected account, so we had to make a little adjustment to stop relying on that
Also I think the pricing is a little on the high side, but PayPal people do really seem to like PayPal so not really a concern
> Since PayPal is not available as a payment method within Stripe, you would have to render the PayPal checkout button separately
That's what my SaaS[1] does, and I have found that 25% of paying customers checkout with their PayPal credentials while the majority enter their credit card in a Stripe checkout form.
> you’ll have to figure out how to unify payment analytics or learn to live with two separate dashboards
The WordPress plugin[2] does this already but it is only available in the WordPress admin dashboard on desktop only. I've been developing an open-source mobile app / PWA[3] that displays payment analytics for Stripe and want to expand it to include PayPal
71 comments
[ 1.8 ms ] story [ 133 ms ] thread> PayPal enables XS2A use cases for TPPs through PayPal’s REST stack. Through PayPal's reliable and proven APIs, TPPs can access the same PayPal systems that power all of PayPal's merchant and consumer experiences.
Stripe isn't a TPP and even if it were to use an external TPP (Tink, Truelayer etc) to allow users to initiate a transaction from a user's PayPal account (similar to A2A transfer), it would be significantly "less integrated" of an experience. There are many problems with the UX around Open Banking A2A payments and it would harm conversion. Because of these reasons, I think it's a bespoke integration/deal between Stripe and Paypal
That competitive pressure isn't nearly as strong in the US, and Stripe would be loath to be sending money to their direct competitor if they don't have to.
Isn't this a consequence of different rates the card processing networks charge dependent on how much data you provide? Like, only a CC # pays the highest rate, CC+CVV or CC+Name pays a bit lower, and the full set of CC+CVV+Name+Billing address pays the lowest rate?
I also like not having a single payment provider have the ability to cut off my revenue if some kind of issue arises. For that reason I would avoid integrating PayPal via Stripe even if that option were offered.
How are you going about this currently? Have you integrated Paypal separately or do you have any other processor along with stripe?
https://stripe.com/docs/payments/paypal
I believe support for US based accounts is coming soon as well.
Misleading..
https://hyperswitch.io/pricing
Code is open-sourced; feel free to use it.
> 81% of US millennials, 79% of Gen-Xers, 65% of Gen-Zers and 68% of baby boomers use PayPal in the US
If you're in a competitive market, foregoing PayPal can be an expensive choice.
The outcomes have been more than satisfactory:
- When it comes to Listen Notes, PayPal dominates as the preferred method of payment outside the US.
- In terms of managing chargebacks, PayPal has significantly outperformed Stripe for us. With an approximate win rate of 100%, it far exceeds Stripe's virtually zero success rate.
This experience underscores the need to look beyond initial developer convenience and consider factors such as global user preferences and chargeback management. Despite the initial time investment, the long-term benefits of integrating PayPal have been remarkable.
I seldom log into either the PayPal or Stripe dashboards. I've developed several integrations into our internal tools to streamline processes. For example, these integrations allow us to view all payment transactions across different platforms and handle refunds.
Both PayPal and Stripe have been configured to automatically deposit payouts into our company's bank accounts each day. This feature initially required us to contact PayPal to enable it (via PHONE CALL!), while with Stripe it could be activated with a single click.
If managing revenue is a core component of your business, as it is for most non-startup companies, in-housing a handful of API calls then transforming storing and visualizing the data is a worthy investment.
As the OP indicated they've barely had to touch it for 4 years. A couple weeks of effort and a few hours of maintenance here or there can be superior to another ephemeral third party vendor that can grind your core business to a halt with an outage, acquisition, pricing change, etc.
As you accrue more experience in the software industry, whether as an engineer or a technical founder, it's not as though you become capable of writing code ten times faster. What truly increases isn't your typing speed, but rather the leverage you gain from developing an intuition for discerning what to build versus what not to build, as well as what to purchase versus what to create from the ground up.
Furthermore, the situation isn't always black and white. There's a middle ground. Initially, you might lean on third-party solutions, gradually replacing them with in-house solutions bit by bit. You may even find yourself with a mix of in-house and third-party solutions. There's no need for it to be an absolute 100% in-house or 100% third-party solution. You could have a 49% in-house and 51% third-party mix, or perhaps an 80% in-house and 20% third-party split.
There are no standard templates to follow. It's all on a case-by-case basis. However, a general principle I found useful is that the more closely a decision ties to revenue generation, the more control you should ideally exert over it.
The payment side of revolut is great and what modern banking should look like.
Virtual cards, flexible limits, don't bother you much with retarded Anti Money Laundering checks
Fees are a bit higher than stripe (but not that much, especially if stripe charges you forex conversion fees).
Not dealing with european taxes is great and completely worth it (my side business would not be viable if I had to do vatmoss accounting, F U Europe). Refunds are on them which is nice.
Api integration was significantly worse than stripe.
They didn't migrate customers from stripe because I didn't have enough customers.
They seem to be technically poor but it's a good business idea.
I hope this is not costing me customers, albeit I have other ways people can subscribe to.
So... a mixed bag. I'd try lemonsqueezy if I were you.
Revin looked great a few years ago but it's quite pricey these days for small businesses.
I hate PayPal with a passion (I get paid with PayPal and I know how shitty is the other side) so I try to make the effort and use my card to not give them money.
Good to know about chargebacks.
Why don't you try this out?
https://xkcd.com/1205/
Genuinely surprised to hear all the love for PayPal, recently. I don't use it much these days (did, years ago but found the experience fairly neutral) but remember a period of everyone seemingly hating PayPal because... I actually don't know? Maybe something about niche cases where it was harder to get them sorted out via PayPal vs other services (which I can imagine to be annoying)?
Does anybody actually use PayPal, deliberately, as a 'digital wallet' & like and want that to continue? That aside, I assume just for card payments Stripe has at least as many card types built-in as PayPal offers?
It adds an extra layer of indirection from my credit and debit cards, and makes things much easier to cancel.
I know Stripe isn't perfect/flawless but I'll do everything in my power to avoid doing business with PayPal.
But that actually changed extremely recently. PayPal is now fully supported with Stripe, even payment settlement happens in Stripe, Connect is supported etc.
https://stripe.com/docs/payments/paypal
Its availability is limited - based on the merchant's Stripe account. It's not available in the US yet, but I can't imagine it'll be far behind. For EEA + UK + Swiss Stripe accounts, you can accept PayPal for US customers
It seems that it was launched very quietly, not crystal clear why. Maybe PayPal are trying to avoid cannibalisation of their own payment processing services
The setup took maybe 15min, and an hour later we had already received our first PayPal payments.
Had to wait a few days for recurring/subscription payments to be "approved", but going great since then
We noticed is that it doesn't expose any info about the region/country of the connected account, so we had to make a little adjustment to stop relying on that
Also I think the pricing is a little on the high side, but PayPal people do really seem to like PayPal so not really a concern
Very smooth on the whole
That's what my SaaS[1] does, and I have found that 25% of paying customers checkout with their PayPal credentials while the majority enter their credit card in a Stripe checkout form.
> you’ll have to figure out how to unify payment analytics or learn to live with two separate dashboards
The WordPress plugin[2] does this already but it is only available in the WordPress admin dashboard on desktop only. I've been developing an open-source mobile app / PWA[3] that displays payment analytics for Stripe and want to expand it to include PayPal
[1] https://last10k.com/register
[2] https://www.paidmembershipspro.com/add-ons/pmpro-add-paypal-...
[3] https://github.com/hbcondo/revenut-web