1. Stripe (Best)
2. Twilio
3. Twitter (Does what it needs to do quickly)
4. Puppeteer (Amazing. Was super helpful.)
5. Google (mostly ok but could be better)
APIs I've hated working with:
1. Paypal (the worst - docs are horrible and UI is not consistent with most of the help material out there because it changes all the time. Have you tried their support? That's a beauty)
2. Facebook (same story but manageable compared to paypal)
If ever there was an example of a company with "first out of the gate" advantage leading to such a large head-start that theyy could afford to constantly give the middle finger to everyone, PayPal is it. I cannot wait for legit altternatives to catch up.
Stripe is doing pretty well, but unless they somehow tap into the casual online user they won't disrupt PayPal's stranglehold to any significant extent.
Apologies for the hijack, just wanted to say thanks.
We launched a SaaS product on the 2016-03 API version. Since then[1] the API has basically changed completely around subscriptions (even the top-level objects aren't called the same anymore), to the point it would probably be easiest to just start a rewrite from scratch (which probably would take a week or two). But the fact that the old API continues to work to this day and that we have been able to rely on it and focus on other things has been amazing. New customers get to enjoy the new API while our business continues to chug along with zero modifications to the payment parts. That is impressive from both a technical and from a business point of view, and ensures we will keep using Stripe forever.
[1] Stripe provides a very detailed and customized API upgrade guide based on your current API usage https://stripe.com/docs/upgrades?since=2016-03-07#how-can-i-...
https://github.com/Kapeli/Dash-User-Contributions/issues/201...
but this project would be much easier to do by someone inside of Stripe.
I know subscriptions have been significantly rehauled since then, but this was my only gripe. Stripe was absolutely excellent back when I used it.
[0] https://stripe.com/partners/apps-and-extensions/accounting
On the other hand, a couple mails and a quick chat on their IRC resolved most of it. But I really wish there would be a clear map/diagram of what route to take depending on what you want to achieve.
Thinking back to implementing Stripe for the first time, I remember being surprised by how painless it was. Prior to that integrating payments was something that filled me with the same kind of dread I get from dealing with legal paperwork.
I love that they've been so successful.
We had dedicated PayPal liaisons and they recommended we use a product API that wasn't fit for our task. Just goes to show even their employees can't make sense of their products and documentation.
1. Simple, distinct concepts with unambiguous names.
2. Semantics are clear, following conventions as appropriate.
3. Minimize surface area without reducing functionality.
4. Clarity and specificity of ErrorCodes and messages.
= Operational characteristics =
1. Extremely low level of 500s.
2. Low call latencies.
3. The API does what it says it does.
4. Consistency is (nearly) always within its documented SLA.
5. Do not make backwards incompatible changes.
= Social characteristics =
1. Docs are correct, up-to-date, complete, specific, and unambiguous.
2. Clearly communicate service outages and resolution timelines.
3. Seek feedback on evolving the APIs.
1. self-consistency: Every entity and operation has exactly one name, a given verb always implies the same operation, paths are always constructed the same manner
2. consistency with industry norms (eg REST)
- activate new phone number
- send SMS from that number
- deactivate number
I have not ever done that particular workflow, but I could.
Who is the Twilio of payments/fintech wherein I could perform a workflow like this:
- generate new CC number in my name
- set transaction limit(s) and expiry 10 days from now
- (go use that CC in real life)
- deactivate the CC
or maybe:
- disable existing card
- reenable existing card
I know I could do this if I wrote the API myself and had a big, complicated, sticky relationship with a bank ... but does someone let me do things like this if I am just an end-user (like Twilio does) ?
Personally, I use them for anything that doesn't accept paypal or similar payment systems. Hopefully that's helpful.
So far I’ve had cards rejected by Patreon and AT&T.
I still recommend privacy.com though.
I think a more publicly-friendly API might be created if it's merely the same credit card company providing temporary virtual credit cards that are backed by your main credit line. VCCs like that are already in use, the question is merely one of how freely accessible they are through programmatic means.
curl api.privacy.com CID:blahblah token:blahblah ... action-action-blah-blah ?
I don't actually use a Twilio CLI - I call functions with curl from my own scripts ...
There's a good reason you cannot simply create and destroy payment cards without any trusted third party keeping track. Money laundering is the obvious issue.
Also, an interesting coincidence that I've just released a case study of Stripe's success and recent $35B valuation [YouTube]: https://www.youtube.com/watch?v=nlFAbBvu7hA
It has been a constant struggle on all platforms to get the stripe widgets to behave correctly.
Since payment is not exactly an optional step in a product, this has been very painful.
Really excited to get to use these tools. Already integrated with stripe for my projects, but this will allow for more cool testing. Thank you stripe team!
It sounds like you won't have to configure tools like ngrok anymore to accept webhooks on a local connection. That's a huge win because with the free version of ngrok your subdomain would change a lot which means having to goto the Stripe dashboard to update it there. It was pretty tedious.
ssh -R $DOMAIN:80:localhost:$PORT serveo.net
I was going to test the waters with https://www.dollardeploys.com/ (not functional yet), wasn't sure how to differentiate it between ngrok/serveo.
You can just run lt -p 8080 --subdomain whateveryouwant ;)
You can also resend events by doing `stripe events resend <event_id>`.
We'll see about documenting both better!
My experience with Stripe has been great, but payments can still get into the weeds through no fault of Stripe's.
We would love to understand what went wrong so that we can keep improving the integration experience. If you are interested in talking to us, please email me at sebas@stripe.com
They're by far the fastest way to prototype functionality, and a dream for the QA team.
Hopefully CLI wil work :)