The developer experience for Paypal integrations leaves... much to be desired. I don't know how to convey the magnitude of the difference without forcing you to implement code against a Paypal API.

Maybe, for a taste of it: Paypal ships API documentation as X00 page PDF files. Their Payflow Pro product, being relatively simple, requires only 176 pages.

Or, in terms of design decisions, consider all the fun of writing software which implements a case statement that maps error code 100 to "Invalid transaction returned from host (Processor), in the case where the processor is Global Payments East or Central." to, well, whatever the heck you're supposed to do when that happens.

Thanks Patrick, really enjoy your blog. Um this doesn't look so bad tho.

https://developer.paypal.com/docs/api/#create-a-payment

https://github.com/paypal/PayPal-node-SDK/blob/master/sample...

EDIT

I've been googling and heard such bad things about PayPal but it looks fine. Am i crazy?!

Note that you can't use their REST APIs with the product whose pricing you want.

Aha! There it is. Thanks!

Very true.

I found a particular customer using it very smartly - to configure multiple gateways via system like ours (ChargeBee) - and splitting his payments across his Authorize.Net, PayPal Payflow & Stripe accounts.

The biggest fear you have with PayPal is getting access to support & being shutdown when there is sudden activity & also risk of "high risk" profile customers purchasing it. One way to mitigate risk is to route all address verified transactions via PayPal (by getting country info upfront before card entry).

He also does it very neatly by spreading transactions across gateways during peak sales. When he does promotions & is expecting volumes he makes Stripe as default & onboards customers.

I need to speak with the customer to learn & implement these as features on our product. :)

One exciting thing I found was that if you buy (say) a wordpress plugin from the US that integrates with a particular PayPal api/membership level, PayPal will helpfully give that same API or membership level a different name in the UK and slightly tweak the permissions, but not document it anywhere.

> Am I missing something?

Yes, a merchant account. "Start accepting credit cards using your existing merchant account."

PayFlow is just a gateway. A gateway cannot process credit cards without being attached to a merchant account; it is just an API to bridge the web with the processing network of the merchant account provider. You can't use it to charge credit cards for $25 and $0.10 per transaction, you pay that _on top of_ the processing fees charged by the merchant account provider.

PayFlow was previously a Verisign product that PayPal acquired in 2006.

That isn't to say you can't save money over Stripe with PayPal. PayPal Payments Pro is their integrated gateway and processing solution, and discounts below Stripe's rates start at $3,000 per month of volume instead of $80,000 per month.

https://www.paypal.com/us/webapps/mpp/merchant-fees

There is a decent range of businesses who are well-served by going the Payflow route -- government offices, non-profits, Universities, etc... Generally small-to-mid-sized businesses with small-to-mid-sized payment processing needs.

It's been a while, but I've set up a few Payflow-based systems, and it's been a great way to go... Payflow allows you much more control and detailed logging than, say Stripe. Yes, it's a bit of a pain to get it all set up at first, and there are a few tricks with error handling, but it's a good way to go to implement your own payment system.

First mind share. If you are a developer and you want payments, currently you think Stripe.

Second, ease of use reputation. Paypal is not known to be easy to integrate with and use.

Third, reputation in general. Paypal has a history and reputation (whether deserved or not) of freezing your accounts and leaving you in the worst situation etc.