Add PayPal to your Stripe integration
hyperswitch.io
hyperswitch.io
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.
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
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?
Why don't you try this out?
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)?
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-...
Misleading..
Code is open-sourced; feel free to use it.
https://stripe.com/docs/payments/paypal
I believe support for US based accounts is coming soon as well.
> 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.
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.
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?