Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am just now in the process of completing a migration from Paypal PayFlow (Recurring Profiles) to Stripe (Subscriptions)

While Stripe's API documentation is MUCH easier to understand on the face there is a lot of undocumented complexity hidden away in there that was documented in Payflow Pro (mostly -- in a hard to find 400 page pdf).

In the end it is worth it for our specific use case. But like anything involving money over time it is much harder then it seems. Obviously, WAY more then "7 lines of code" to do it even halfway right.

I have to give massive credit to both organizations support engineers who helped us move the card details across without us ever seeing them. In the end they even ended up having to do a complex customer_id mapping for us to get it done in a way that allowed us to recreate the behaviour we had in PayFlow in Subscriptions



I'd love to hear more about the complexity you ran into to see if we can make it easier. Could you email me at edwin@stripe.com?


The complexity was more in our customers application logic then in Stripe. Stripe understandably enforces quite a few sensible limits that 'normal' usage probably wouldn't hit. For us the 2 biggies were:

* There is a (undocumented?) limit of 25 subscriptions per customer. Our client sells a la carte services and some large customers have quite a bit more then 25 things. Subscription items partially solve this EXCEPT everything in a subscription must bill on the same-cycle and...

* Our client had a requirement to maintain the existing billing cycles for all customers (and enforce specific start dates for new subscription).

These two limits meant we had to bundle existing services into Subscriptions during the migration and use the "trial period" feature (as a "start_date") to force the billing cycle for each bundle. The worst case customer had I believe 18 different billing cycles for their services in the end so we got lucky. (we also had to figure out a way to name the bundles in the UI and the CC statement descriptor etc).

In the end this saves on transaction fees and reduces the clutter on their CC statements but cost quite a bit of development effort to do and makes the code managing "subscription" starts and stops a bit complex.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: