I'm at the point where I need to add billing to my app.
Looking at Stripe, it seems I have 2 options. I can add a payment form to my app and handle credit card information and payments in app with their Elements UI.
Or I can have an invoice sent to the user.
I'm leaning more towards the invoice option, since that lessens the amount of work I have to do on the frontend. I just gotta wire up a couple webhooks to receive payment failures or successes.
But i'm curious to see if anyone's had any experience with that option or if its just better to handle CC in app. Just wondering if there are any gotchas or anything I should be aware of. Or any resources to check out are greatly appreciated.
I know both can handle subscription based billing.
I just listened to the latest episode of Full Stack Radio and its making think about taking the happiest/shortest path to get billing up and running.
I am not a huge fan of this approach, as it exposes your user data to yet another 3rd party, but may be worth a look.
https://www.chargebee.com/payment-gateways/stripe/
Stripe elements makes it pretty easy to accept payments or subscriptions. I would steer clear of invoicing as it puts the effort on the customer.
What is your app stack? I may be able to help.
From their docs: "Stripe can automatically attempt to pay an invoice if the customer has a payment method on file. "
So i'm not that worried about it. They either enter their payment info once in the invoice, then i it charges them again in the future. Or i have to accept the payment on my site, and do what the invoice is going to do for me.
I'd rather not accept payments on my site.
Did not know that - thanks
Don't you have to pay extra for their billing system? Also it's not clear but this is on top of their standard credit card pricing if your customers pay via CC.
We just used their standard card charging format in our SaaS for our recurring clients and built our own recurring charging system.
I just double checked
"Free for the first $1 million of recurring charges.
After that, 0.4% on recurring charges. In addition to Payment fees"
So ya looks like.
But I mean.. thatd be a good problem to have.
Even if the app is successful, it'll take a while to that 1 milli limit. I'd need tens of thousands of users. which at that point I'm sure i could afford the extra 0.4%.
I have no comments from a technical perspective, but I would also advise going down the simplest and quickest route to monetisation... you could always build in a slicker payment form at a later date. That's the approach I'm considering for my project too,
Right on. Thats why I'm leaning towards their invoice api. Seems like less moving parts. I just got home from work, so i'm about to dive into their docs and get sh*t done. I'll update this post if anything interesting pops up