#dragonlord_api
1 messages · Page 1 of 1 (latest)
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1306038190712291379
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- dragonlord_api, 4 hours ago, 69 messages
- dragonlord_api, 5 days ago, 9 messages
- dragonlord_api, 5 days ago, 16 messages
I want to apply the invoice balance to the billing credits
Hello again! The issue you're running into is that the Invoice isn't reaching our minimum amount thresholds.
If you increase the amount of the Invoice beyond the minimum charge amount you should see the behavior you're expecting.
Interesting
\Stripe\InvoiceItem::create([
'customer' => $customer_id,
'amount' => "100",
'currency' => 'usd', // Set your desired currency
'description' => 'Custom charge for specific amount',
]);
// Create the invoice for the customer
$invoice = \Stripe\Invoice::create([
'customer' => $customer_id,
'pending_invoice_items_behavior' => 'include',
'auto_advance' => true, // Automatically finalize the invoice
]);
// Finalize the invoice to apply any available credits
$invoice->finalizeInvoice();
so I changed it to a dollar and now my issue it does not finalize the invoice even though the cutomer has credit to cover the invoice
What do you mean by "it does not finalize"? Are you getting an error when you call finalizeInvoice()?
like the invoice stays open instead of changing to paid through the user's billing credits
What do you mean by "stays open"? What is the status of the Invoice?
It says open and the charge says incomplete
Okay, so that means it was finalized. If it wasn't finalized it would still be in draft status. It sounds like you want to call the pay endpoint to actually attempt payment: https://docs.stripe.com/api/invoices/pay
You need to be much more specific about exactly what's happening. What does "it does not apply the billing credits" mean? Did the pay request succeed or fail? Can you give me the Invoice ID so I can take a look?
it succeded and the invoice is in_1QKTxyR1C6SBGhQQnRJrN6b9
However, this customer has 1010 billing credits ballance it should apply to the invoice but it is not
Oh, wait, so you're trying to get the Customer's existing credits to pay for this? If so that won't work, as I explained to you earlier today, as a one-off invoice charge isn't eligible: https://docs.stripe.com/billing/subscriptions/usage-based/billing-credits#credit-grant-eligibility
okay so it only applies to subscription invoices
Yes, specifically ones that link to a billing meter price.
interesting
Billing credits are part of the usage-based billing and billing meters system. In order to use them you have to use the entire system. You can't use just one small part of the system in isolation.
Yes that makes sense, but at the same time it feels as you should be able to but I guess stripe does not see the reason for my use case yet
is their a way to link these mesages to customer support to request this feature?
No, if you want to make a feature request you should write out full details when contacting Stripe support. You can copy and paste from these threads if you want, but I recommend writing a full, detailed use case with very clear and verbose descriptions about exactly what you want and exactly why the system as it is today won't work for you.
okay will do thank you so much
I do think the system we have today will work for you, but you would need to read up on it and implement the entire thing.
So it won't we do not want the user to pay for a subscription to get credits.
Not sure if you are familiar with E-ZPass
We want the user to prefill their account x amount of credits.
That's exactly what this system is designed to do.
Yes but I can not charge the user credits as low as one cent for example, and once it reaches 0 or a low threshold the user will realize they need to prefil theit card again
I want to update the billing credits but their is no endpoint to do so
If you need to charge someone a penny Stripe as a whole isn't going to work for you. You would lose money on the transaction due to fees.
I was thinking that would be the issue too
How do people pay you a single penny now? Cash?
What are they paying a single penny for?
It is a feature for sending out emails for example and the user pays for credits as they use it. Sending out an email is cheap so that's the logic
So are they actually paying you a penny or are they paying you like $5 and then they get 500 emails they can send?
so for every email sent succusfully we want to update their credits we know we can implement it ourselves but we thought this was a cool way to do that so we do not need to store any data
we want to update for each succusful email sent
Hang on, I think you still have an incorrect understanding of how this system is designed to work...
Let's forget entirely about Stripe for a moment. Tell me, at a high level, what you want the experience to be for your customers. When do they pay? What do they pay? How often do they pay?
this is how it all works
1.User wants to use this email sending feature
2. User fills their account with 20 dollars which is 2000 credits
3. each email sent succusfully is one credit
4. deduct one credit for each email sent
5. The user can prefill their account as they see fit depending on their usuage of this feature
That is exactly the scenario this system is designed for. I think you're misunderstanding some key part somewhere.
For #2, you would take a one-time payment from the user for $20. You would then give them a billing credit for the $20.
For #3 and #4, each time they send an email you record their usage by creating a meter event to record that use.
For #5 it's the same as #2.
I think the misunderstanding is that there's not a direct relationship between the billing credits the customer gets and the usage recorded.
So I already did steps 1 and 2 and it works well
They're separate things, not the same thing, but they impact one another.
3 and 4 I am trying to create an meter event and it's not working properly
so maybe I have to look into more and see.
Does a meter event reduce the user's credits automatically?
I need to reduce the user's credits automatically if this is possible let me know
No, that's the part I think you're getting hung up on. The meter events record usage, but they don't immediately decrement the credits. The credits are used when you invoice for the usage.
okay so should I invoice the ussage once it reaches 50 cents for example?
or the maximum of credits they have
Probably not, but it depends on your use case. Do you want people to be able to go over the amount of credits they've paid for? Meaning if I paid $10 for 1,000 emails, can I send 1,001 emails or will that 1,001st email not be allowed?
I do want them to go over the amount they paid for
like if we send one extra free message it's fine but we do not want the invoice not to be paid because the user removed their card
Okay, so let's say I paid $10, then I sent 1,500 emails. That means I owe you $5, right?
sure yes
The way this system works is that you create an Invoice to bill me for my usage, which is 1,500 emails at 1¢ a piece for an Invoice of $15. The Invoice would first attempt to use billing credits, so my $10 credit I already paid for would apply first, brining the Invoice total down $5. The remainder can then be paid with card or however else you want them to pay.
Typically people create Invoices on a regular cadence, like monthly.
The amount of time between each Invoice is goverened by the period of the associated Subscription and the Price you use for all of this.
yea that makes sense I think its best if we store it ourselves and do the calcuation because we would lose more money if we do it with stripe
How so?
Would not each invoice charge us even the value is 0 or no?
No, I don't believe so, but I'm also not an expert on our fees. As far as I know, though, if the amount is zero there aren't fees.
okay intresting
We would already have charged processing fees on the initial amount paid up front.
yea I understand that, okay I will play around with it more and see what happens
thanks a bunch again
Happy to help!
One other thing...
If you want a simpler system, albeit one where you'll probably have to do a bit more work on your end, you might want to take a look at the Customer credit balance: https://docs.stripe.com/billing/customer/balance
That's not associated with usage-based Billing or anything else we've been talking about. It's a simpler system where you can give a Customer a credit balance that will be applied to their next Invoice. It might be a closer fit for what you want to do/how you're thinking about this, but the usage-based Billing approach we've been talking about before might also be more appropriate.
I recommend you read up on both and figure out which best suits your needs, use case, development resources, etc.
The issue is we do not want it to affect other subscriptions the user already pays for
Ah, gotcha. Customer balance is out then.
yea that's what I assumed
Unless you used separate Customers or separate Stripe accounts or something like that.
yea it would easier just to store it in the database then
An even simpler approach would be to store their balance in metadata on the Customer.
But that would require a lot of logic/work on your end.
that's not a bad idea but the issue might arise if a mechanism tries to read the data the same time it is trying to update it but that cause an issue with the update if I am not mistaken
Yep, that's possible and something you would need to account for on your end. The usage-based billing approach is much more robust and powerful.