5 ms·
You can search HN and find this question many times. My 2 cents, I don't trust any company owned by Paypal as Paypal has a very strange, aggressive and non-tra
by davismwfl 10y ago
You can search HN and find this question many times.
My 2 cents, I don't trust any company owned by Paypal as Paypal has a very strange, aggressive and non-transparent and inflexible process to holding funds from businesses, charities etc (even after providing all the extra "evidence" they ask for).
Stripe has a lot of advantages, API being a huge one. I have heard of a few people that complain about delays in responses from them, but at least for me I have never had that. In fairness too, 99% of the time the answers I have needed are in their documentation.
If I were you, no matter who you choose to integrate, I'd encapsulate it behind your own payment "service" so that even if you have to switch or you need to add more then one (highly recommended), then you can. Some will argue this is overkill, but I have done a lot of payment integrations, with specific banks, First Data and Stripe, Paypal etc. Having it encapsulated means a little more design but a lot less breakage and lets you minimize risk if a vendor decides to shut you down or freeze funds etc.
IMO if you are accepting payments you should already have encapsulated your payment vendor, as a real risk to business continuity exists if they decide to freeze your ability to charge or like Paypal freeze funds during charge back windows etc.
- FunnyLookinHat 10y ago"If I were you, no matter who you choose to integrate, I'd encapsulate it behind your own payment "service" so that even if you have to switch or you need to add more then one (highly recommended), then you can." This is the best advice in the comments. I've seen my own code and others become overly coupled to a specific provider's terminology, mechanisms, and expectations - leading it to be exceptionally painful when you inevitably have to migrate away to a new provider (or support more than one).
- newton10471 10y agoFor those in the ruby/rails world, there's a gem which does this (make it easy to switch between payment vendors) for you: Active Merchant (http://activemerchant.org/ http://activemerchant.org/).
- maerF0x0 10y agoYeah, but is there a gem for allowing me to switch payment abstraction gems?
- dopamean 10y agoActiveActiveMerchant.
- patrickgordon 10y agoAwesome gem, thanks for that!
- asadlionpk 10y agoDumb question, wouldn't rolling a wrapper over existing payment service also require me to store credit cards myself somewhere so I can easily switch integration later? If so, isn't that risky.
- misframer 10y agoYou could just ask your users to input their billing details again.
- adyus 10y agoGenerally, payment processors give you a token once a client gives them a credit card. You just need to abstract away the processor-specific code that uses that token.
- larrik 10y agoNo, not at all, as long as you aren't afraid to ask for someone's credit card again. You should also be able to transfer credit card information between services (which usually takes weeks and costs thousands, though).
- davismwfl 10y agoIt is not unacceptable to ask for updated payment details every so often, so users don't generally have issues with this and it saves you from having to store the actual card details. You just have to store the token as others pointed out. Also, if you do integrate multiple providers early on, you can break users up over them so that again your risk is minimized. This does come with some accounting pain, but it mitigates some risk so it is worth it. So essentially if you had to move away from one vendor it isn't your entire customer base all at once.
- brianwawok 10y agoIf you do a capture for say recurring monthly charges, not sure you can (legally and easily) capture card numbers to easily switch down the road? For one off charges it is easy to switch, but not for recurring, which is where I think these platforms "get you" by being sticky.