Out of interest, why did you go down the avenue of hacking together your own system to handle subscriptions? Surely you've limited yourself like you've said you have to build out every time you want to attach another payment method like paypal - Is this not more expensive than looking into a Merchant of Record handling these complexities for you?
Re:Implementing API Billing with Stripe
by stickfigure on Wednesday April 03, 2019 @03:31PM
(#19566454)
There must be some sort of miscommunication here. My (SaaS) subscription system is vanilla Stripe without abstraction. My (single-purchase, tshirt) system was an abstraction across Stripe and PayPal.
I can only imagine the elevated pain of abstracting across multiple subscription systems. Ouch.
My bad must have been a miscommunication here. I was about to expand on those key differences between payment gateways vs Merchant of Records. http://bit.ly/2Us1OWM - Could still be an interesting read as it explores those key elements of what you have to juggle.
Re:Implementing API Billing with Stripe
by kowdermeister on Wednesday April 03, 2019 @05:37AM
(#19562007)
As a solo developer on a project which needs flexible payment options (also t-shirts) that's why I need to pick a payment solution that supports paypal besides other methods.
Paddle looks like the service I need on the long run:
Re:Implementing API Billing with Stripe
by james_s_tayler on Wednesday April 03, 2019 @07:53AM
(#19562582)
How did you go about implementing a referral program in Stripe?
Re:Implementing API Billing with Stripe
by stickfigure on Wednesday April 03, 2019 @03:41PM
(#19566551)
I have a polymorphic ledger table of Credit, Spend, Payout.
I scan recent invoice history periodically to keep Credits up to date. Payouts are via PayPal masspay. Spends (using credit balance to offset their SaaS bill) are created on the invoice.created webhook, which adds a corresponding negative line item to the invoice.
I considered doing everything in Stripe - you can add pending invoice items instead of credits and payouts, then 'spends' are just the natural processing of bills - but it would have been very difficult to get analytics (eg, total outstanding payout liability).
My last company processed >$100MM/yr of tshirts, split between Stripe and PayPal. Stripe was wonderful; PayPal was hell. It required a lot of engineering effort to build and maintain the system, even as simple purchases (no subscriptions). But if you're selling impulse buys online, PayPal is required.
Current company is B2B SaaS, smaller team, and I said "no freaking way" to PayPal. Built the subscription system around Stripe. Lack of PayPal has probably cost a few sales but our pace of development is much faster, and the new features we're able to roll out (like a referral program) move the needle more.
If you go the "straddle multiple billing systems" route, expect to dedicate one fulltime engineer to billing for the life of the project. That may be reasonable for a team of 10, but it's death for a team of 2.