#Wasabi - Billing
stray perch
obsidian patrol
Let us say a user pays for quantity=10 on a subscription at a 10$/month plan. This means that they will be charged 100$ USD initially. Then if they downgrade to 1 user at the midway point, in the next month’s invoice they will get a prorated credit and not a refund. Is that right?
- How long does it take for a subscription to become active, given that the customer has a valid source? What is the recommended way to check for this ?
- what is "applied balance" ?
- Creating a new subscription. Question: Do you have any guidance around using payment_behavior=error_if_incomplete + collection_method=charge_automatically in order to guarantee that creating a subscription only succeeds if the first payment succeeds? Do customers often use this? Any gotchas?
stray perch
👋 Okay let me read this through and think about it
- You're correct, you would issue refunds and these are distinct from credits
1 a. Default behavior is to credit the user for the prorated amount. You can also adjust the proration_behavior when changing a subscription
2. The best way to check for this is to use webhooks and listen for the customer.subscription.created event. Examine the subscription object that is returned with that event.
3. Can you provide more context here?
4. Looking for docs. So far the only thing I see on this is
Use error_if_incomplete if you want Stripe to return an HTTP 402 status code if a subscription’s first invoice cannot be paid. For example, if a payment method requires 3DS authentication due to SCA regulation and further user action is needed, this parameter does not create a subscription and returns an error instead. This was the default behavior for API versions prior to 2019-03-14. See the changelog to learn more.
obsidian patrol
Hello
Re 3) on the invoice page, Applied balance is shown as grey, what does this mean in this context?
pliant lily
Hello! That's the Customer credit balance that was applied to this Invoice: https://stripe.com/docs/invoicing/customer/balance
obsidian patrol
Hi @pliant lily - oh so applied balance = to customer credit balance?
pliant lily
Yeah, this Customer had a credit of $20 that was applied to this Invoice, leaving $29 outstanding from the $49 total.
obsidian patrol
thank you!
A couple more questions
- Webhooks. We are beginning to learn more about webhooks. What are some common gotchas around using them and important safeguards to keep in mind? Our biggest concern is around monitoring and alerting if for some reason we broke something on our end and are not receiving webhooks anymore (e.g. say we broke the receiving route). What does Stripe provide for alerting us in cases like these?
- Domain verification for Stripe-sent emails. Question: What is the process for this? How long does it take?
pliant lily
5: Our webhooks system has a robust retry system, so if you go down for a bit we'll retry delivery several times to make sure you receive the events. There are details about best practices and retries on this page: https://stripe.com/docs/webhooks/best-practices
obsidian patrol
7 ) do we have any guarantees about a credit card when creating a token?
Can the credit card still be invalid even after creating a token? - my guess is yes card can still be invalid
pliant lily
6: We have documentation about setting up a custom domain for emails from Stripe here: https://stripe.com/docs/email-domain
7: What do you mean by "invalid"?
obsidian patrol
Re 6) the user is still concerns about too many events and also when events is down due to Stripe server is down. What would you be your recommendation here?
or when something is broken on the user's server, and not receiving webhooks in that instance
obsidian patrol
7: What do you mean by "invalid"?
as in the card number we pass to tokenize is invalid (wrong number perhaps)
pliant lily
We cover that in the documentation linked above. We recommend a queue system with delayed, sequential processing of events to handle large numbers of events. If something on the receiving server breaks as long as it gets back online within the retry window (three days in live mode) the events will be resent. If it takes long than that the missed events can be retrieved from the API for up to 30 days: https://stripe.com/docs/api/events/list
When tokenizing we perform basic checks like length of the card number and luhn check, but that doesn't mean the card issuer considers it to be a valid, active card.
obsidian patrol
Re card valid or not, it sounds like tokenization can happen and a card could still be invalid?
pliant lily
Depends on what you mean by invalid specifically, but yes?
Like, invalid based on luhn check? No.
Invalid as in it might decline? Yes.
obsidian patrol
What are the possible card invalid definitions when tokenizing?
Do we have to actually make a charge to check the validity of it (is an active card)?
pliant lily
Let's back up a bit, what are you actually trying to accomplish at a high level?
obsidian patrol
mostly curious if bank funds issues are the only way a payment can fail after a token is created.
How much can we trust that token?
pliant lily
You can't trust it at all, really. Tokenizing to Stripe only creates a representation of card details you can then reference. Creating a token doesn't validate the card or guarantee it can be used successfully.
Can we go a level higher than that? What are you building? What's your use case?
obsidian patrol
We wanted to consider the case where we give access to the customer when subscribing to a paid billing plan while the credit card payment is getting processed.
I was curious if we can have some guarantees from credit card tokenization so we can lower the risk of doing this process.
pliant lily
There are a few different approaches you can take. Is this more of a free trial situation, or is it more wanting to guarantee that a certain amount will be paid after a period of time?
obsidian patrol
I'll circle back on this one @pliant lily
Another question — is it possible to opt out of accepting payment on the hosted invoice page? Meaning that we only show info on the invoice / receipt (top panel in screenshot).
https://stripe.com/docs/invoicing/hosted-invoice-page
I want to host the invoice on the URL (top half) but not have the payment dialog in the bottom half
pliant lily
Let me check, hang on...
obsidian patrol
There are a few different approaches you can take. Is this more of a free trial...
this is for the initial subscription creation on regular checkout, we charge immediately
pliant lily
For the hosted Invoice page, you can disable paying there by setting payment_method_types to an empty array in the API for the Invoice: https://stripe.com/docs/api/invoices/create#create_invoice-payment_settings-payment_method_types
obsidian patrol
For the hosted Invoice page, you can disable paying there by setting `payment_me...
just to confirm what it sounds like the docs are saying, doing so will NOT stop the invoice payment to be attempted automatically by the subscription, right?
pulsar steppe
Yes, I think so, per the explanation