Earlier quoted context omitted.
Our experience is that manual invoices are charged right away. I wonder what's different about our setups? The only thing I can think of off the top of my head is webhooks that aren't responding, which would delay the invoice closing. But I think that would make the delay 72 hours, rather than 24.
I misspoke, it's 1 hour, not 24. Can be found here [0]. Regardless, the upgrade happens _before_ the customer is charged, so unless you put a hold on your system and wait for that invoice to close, you're still giving them access before they've paid (Stripe's system will shown them as having the new upgraded plan before the invoice closes). And with the charge re-tries and back-off they use, if your webhooks aren't l…
Implementing API Billing with Stripe
61–70 of 84 posts
Re: Implementing API Billing with Stripe
#62 AAAAYYYYY GO FUCK YASELFRe: Implementing API Billing with Stripe
#63Earlier quoted context omitted.
> Vendor lock-in isn't a good plan I'll take vendor lockin over being locked into a bunch of homebrew garbage that some former developer managed to sucker the entire company into creating because of "vendor lockin". So many times engineers come up with fears about "vendor lockin" and forget how easy it is to lock the company into an unsupported, half-baked homebuilt product that has nothing to do with the company's c…
Spoken like someone who hasn't had a vendor disappear and have your entire implementation on their platform vanish.
Stripe might leave the servers online in a half broken state for a few weeks, but they will not answer tickets or phone calls about critical issues if they've decided to can a product.
https://www.pymnts.com/news/partnerships-acquisitions/2018/s...
Re: Implementing API Billing with Stripe
#64Earlier quoted context omitted.
Is there any downside to just using the payments api and not use any of the other stripe features? Subscriptions can be implemented manually right?
Yes, subscriptions can be implemented manually. We did that two years ago before Stripe had the full “Billing” API. One big win you get with Billing, though, is automatic generation of invoices each subscription period. It’s nice not to have to write that code, and the automatic invoices tie in nicely to a few other things Stripe can do better than we can, like automatic retries of payments that fail.
Re: Implementing API Billing with Stripe
#65Earlier quoted context omitted.
They often offer either the simple option or the custom-built option basically: - Stripe Checkout ( https://stripe.com/docs/checkout ) vs implementing your custom credit card form and using the API directly ( https://stripe.com/docs/charges ) - Standard, Express, Custom options for Stripe Connect (e.g. take money from someone and give it to someone else): https://stripe.com/docs/connect/accounts
Hi from Stripe! We are currently working on a new version of our Checkout product[0] and would love feedback. We are working on making the simplest drop-in integration to get up and running on Stripe, and we support Stripe Billing! Send me any thoughts you have (matt at stripe). [0] https://stripe.com/docs/payments/checkout
Re: Implementing API Billing with Stripe
#66The article is completely missing any mention of tax, be it sales tax or VAT. This is my biggest complaint of Stripe.
For a lot of us, we live in countries where we simply _have_ to start collecting and remitting tax from the very first customer.
Re: Implementing API Billing with Stripe
#67Stripe's "getting started" documentation, as well as this article, show us how easy it is to get started with Stripe - if you ignore the existence of taxation. The article is completely missing any mention of tax, be it sales tax or VAT. This is my biggest complaint of Stripe. For a lot of us, we live in countries where we simply _have_ to start collecting and remitting tax from the very first customer.
Re: Implementing API Billing with Stripe
#68A good first question to ask about a data model is, "where does the data live?" In general, we think it's a good idea to make Stripe the "one true source" for as much of your customer and billing data as possible. Our company went the opposite way, we have our own model and we abstract stripe as a payment option supported. Recently with the same model we were able to add Paypal and other country specific payment meth…
I've done it both ways. 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…
Paddle looks like the service I need on the long run:
Re: Implementing API Billing with Stripe
#69Stripe's "getting started" documentation, as well as this article, show us how easy it is to get started with Stripe - if you ignore the existence of taxation. The article is completely missing any mention of tax, be it sales tax or VAT. This is my biggest complaint of Stripe. For a lot of us, we live in countries where we simply _have_ to start collecting and remitting tax from the very first customer.
Stripe has indicated that they're working on it, but no timeline yet: https://www.indiehackers.com/forum/stripe-onboarding-integra...
Re: Implementing API Billing with Stripe
#70A good first question to ask about a data model is, "where does the data live?" In general, we think it's a good idea to make Stripe the "one true source" for as much of your customer and billing data as possible. Our company went the opposite way, we have our own model and we abstract stripe as a payment option supported. Recently with the same model we were able to add Paypal and other country specific payment meth…
Question: did you plan the abstraction by looking at multiple providers first then figuring out the abstraction that would work well for all of them or did you just look at Stripe and luckily come up with an abstraction that also worked for other providers? I'm encouraged by your success of this model. I'm currently struggling with the 'billing system as source of truth' model.
We built the abstraction around the requirements for our business model, although after some iterations it became similar to the model used by Stripe (customers, sources, plans...). We support saved payment options and on them we do recurring billing and one-stop payments.
A user for us can have multiple sources and a source is a saved external card or payment method, in the case of Stripe a source is a combination of the Stripe customer id and Stripe source token.
Most payment gateways support some kind of token that represents a saved card or similar on which you can do a charge.