4 ms·

I've just finished a Stripe integration[0]. Given Stripe's developer first reputation I thought this would an easy job that wouldn't take more than a couple of

by LeonM 8y ago

I've just finished a Stripe integration[0]. Given Stripe's developer first reputation I thought this would an easy job that wouldn't take more than a couple of days. Boy was I wrong! In the end, it took me about 3 weeks. Small disclaimer here, I was implementing Stripe Billing, not Stripe Payments. The Billing suite is a lot more complicated compared to the Payment suite. Nonetheless I took me a really long time to figure out all the special cases such as: renewing a card, switching to a different payment method, up/downgrading a plan, multiple currencies, etc. At some point you'll be almost finished with the integration and only then do you find the need to implement webhooks for certain asynchronous payment methods (especially needed when you are in Europe). Once implemented, webhooks give you endless new workflows to handle, and many race conditions between your frontend and backend. So it constantly feels like one step forward and two steps back. I don't think it's Stripe's fault though that my implementation took so long. Stripe's documentation is pretty solid. It's just that billing touches just about every part of your stack (frontend, backend, database, testing, tooling, accounting) and it's painful if you find out you have a bug that caused you to over/undercharge a customer. You need to take your time to get it right. [0] shameless plug: https://www.mailhardener.com https://www.mailhardener.com

warent 8y ago
It didn't take me nearly as long to implement Stripe Billing (a couple of days) but that's because all they can do is sign up for my one subscription plan, cancel, and update their card. There are surprising edge cases that crop up. For example, canceling a subscription and then restarting it is actually somewhat painful. But yes, their documentation is stellar!
kwindla 8y ago
I'm a Stripe fan, so my perspective on this is that Stripe has done an incredible job making "easy things easy," and a pretty good job making "hard things possible." There are things I'd love to see added to the Stripe Billing APIs (some of which I mentioned in the article), but I have a really healthy respect for the amount of good work that's gone into the design of an API that, as you say, touches just about every part of a potential customer/payments workflow. Stripe's API has consistent naming, a clean design of the core data objects, consistent data formatting and request patterns, good dashboard tools for seeing what's happened in requests and webhooks, and great documentation. All of which are non-trivial, and basically none of which any of the other "name brand" APIs I've used in the last year or so do. :-)
- LeonM 8y ago
  Yes and no. Some parts of the documentation can be clarified in my opinion. For example: if you change the default payment method of a Customer, the default payment method of all this customer's Subscriptions is not changed. The documentation is not clear about that. Also, if you remove a payment method from a customer, the subscriptions seems unaffected. If you're not careful you might still end up charging this customers card when the subscription auto-renews. I'm still a fan of Stripe though. I have my fair share of experience implementing other PSP's and they were an unbelievable PITA. As far is my experience goes, Stripe is miles ahead of their (european) competitors.
- benologist 8y ago
  Stripe's generally consistent, except for three different ways to enter a name: name account_holder_name first_name + last_name And four different structures for addresses: address_line1 address.line1 legal_entity.line1 (a personal address, old as of new version) legal_entity.personal_address.line1 (personal address when the prior is a business, old as of new version)
- chrsstrm 8y ago
  You're right, their documentation is great and the API is nice to work with, but you are forced to do things their way. I was recently working with Billing and ran into a pretty big issue: A customer on a recurring plan upgrades to a more expensive plan. As long as the customer has a valid source on file, the upgrade is processed. Stripe's default is to adjust the payment to be collected and charge it on the next invoice, which comes at the end of the billing period. If you want to charge the difference immediately, you can by manually forcing an invoice. The problem is that the invoice doesn't close for 24 hours and you can't force it to close any faster. If the customer's payment source is declined when the invoice closes, you just gave them 24 hours access to your premium upgrade which you now have to detect and rescind after being alerted via a webhook. There's nothing in the documentation that warns about this or offers a solution, and worse yet, rolling the user back to their previous plan is not an option. For some use cases, it might not be a big deal, but for most businesses that is a nightmare. The easy stuff is indeed easy, but once you start to wander off of The Path, things can get very difficult.

by LeonM 8y ago

warent 8y ago

It didn't take me nearly as long to implement Stripe Billing (a couple of days) but that's because all they can do is sign up for my one subscription plan, cancel, and update their card. There are surprising edge cases that crop up. For example, canceling a subscription and then restarting it is actually somewhat painful. But yes, their documentation is stellar!

kwindla 8y ago

I'm a Stripe fan, so my perspective on this is that Stripe has done an incredible job making "easy things easy," and a pretty good job making "hard things possible." There are things I'd love to see added to the Stripe Billing APIs (some of which I mentioned in the article), but I have a really healthy respect for the amount of good work that's gone into the design of an API that, as you say, touches just about every part of a potential customer/payments workflow. Stripe's API has consistent naming, a clean design of the core data objects, consistent data formatting and request patterns, good dashboard tools for seeing what's happened in requests and webhooks, and great documentation. All of which are non-trivial, and basically none of which any of the other "name brand" APIs I've used in the last year or so do. :-)

LeonM 8y ago
Yes and no. Some parts of the documentation can be clarified in my opinion. For example: if you change the default payment method of a Customer, the default payment method of all this customer's Subscriptions is not changed. The documentation is not clear about that. Also, if you remove a payment method from a customer, the subscriptions seems unaffected. If you're not careful you might still end up charging this customers card when the subscription auto-renews. I'm still a fan of Stripe though. I have my fair share of experience implementing other PSP's and they were an unbelievable PITA. As far is my experience goes, Stripe is miles ahead of their (european) competitors.
benologist 8y ago
Stripe's generally consistent, except for three different ways to enter a name: name account_holder_name first_name + last_name And four different structures for addresses: address_line1 address.line1 legal_entity.line1 (a personal address, old as of new version) legal_entity.personal_address.line1 (personal address when the prior is a business, old as of new version)
chrsstrm 8y ago
You're right, their documentation is great and the API is nice to work with, but you are forced to do things their way. I was recently working with Billing and ran into a pretty big issue: A customer on a recurring plan upgrades to a more expensive plan. As long as the customer has a valid source on file, the upgrade is processed. Stripe's default is to adjust the payment to be collected and charge it on the next invoice, which comes at the end of the billing period. If you want to charge the difference immediately, you can by manually forcing an invoice. The problem is that the invoice doesn't close for 24 hours and you can't force it to close any faster. If the customer's payment source is declined when the invoice closes, you just gave them 24 hours access to your premium upgrade which you now have to detect and rescind after being alerted via a webhook. There's nothing in the documentation that warns about this or offers a solution, and worse yet, rolling the user back to their previous plan is not an option. For some use cases, it might not be a big deal, but for most businesses that is a nightmare. The easy stuff is indeed easy, but once you start to wander off of The Path, things can get very difficult.