#benjamin_api

1 messages · Page 1 of 1 (latest)

drifting wharfBOT
#

👋 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/1494242883266412635

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

austere edge
#

I could see this with two other customers as well. I suppose there are more

robust quest
#

hello! Gimme a while, we are looking into this

drifting wharfBOT
maiden scaffold
#

Hey! Taking over for my colleague. Let me catch up.

#

That invoice was issued from this Checkout Session cs_live_b18rR9GOXMpQHvArNy8EgDJObg9INxaJUOQCRTAL97ktOJO3SC1EBJ1PRq which was created and completed on 2026-03-20

#

The customer used an async PaymentMethod (SEPA in this case)

austere edge
#

Well but the invoice started existing 10 days later

#

Which is documented by the invoice created event

maiden scaffold
#

The object invoice was created when the Payment was succeeded (the sepa payment atttempt successfully)

austere edge
#

I know that my application queried for invoices at the 21th, this one was missing

maiden scaffold
#

the created date was backdated in this case to the daythe customer made the Payment

austere edge
#

That’s why i started investigating in the first place

maiden scaffold
#

Stripe doesn't create the invoice untill the payment is fully succeeded when using Checkout Session

austere edge
#

So isn’t the createdAt wrong?

maiden scaffold
#

I understand that this may look confusing for the async payments

#

The createdAt isn't for the object creation in the database, it's for the date when the invoice was issued, which is the date of the payment

#

if you send the invoice with the date 31, your customer will claim that they did the payment on the 20th

austere edge
#

That is a huge problem; it breaks my application logic and I'm sure plenty of others too

maiden scaffold
#

Yes I agree, this is confusing for the async payments

austere edge
#

We have no efficient way of finding out if this happened in the past

maiden scaffold
austere edge
#

We synchronize data. To do that, we go by createdAt regularly

#

So today (16th of April), we get all invoices created yesterday

#

tomorrow, we get todays invoices

#

But if suddenly invoices are injected with a faked createdAt date, this logic breaks and the invoice is never considered

#

The only workaround would be to query the full invoice history very often, which would be a monstrous performance problem

maiden scaffold
#

This flow won't covers the async payments. Stripe doesn't issue the invoice untill the payment is completed. So you need to update your workflow accordignly I think

austere edge
#

But there is no option to account for this, is it?

maiden scaffold
#

So that you don't miss any one

austere edge
#

This means to multiply all my calls by 2 at least

#

and it still has practical problems

#

The gap is 11 days here

#

Means if at the 9th of april I make my taxes (which many people do) it can be that an invoice from March is missing

maiden scaffold
# austere edge The gap is 11 days here

Think about that the payment will fails here. If you get the invoice.created on the 20 and on the 31 (11 days after) the payment fails, you'll need to update the invoice again... if this happens in two different months this will lead to other accountant issue too

#

so that's why Stripe won't generate the invoice untill it's sure that the payment is succeeded

austere edge
#

Yes, but that's a correct handling then

#

Create the invoice which means revenue. if not paid, book it out. thats how it works

#

Actually the way stripe does it here is not even compliant with german law

#

Because if you create the invoice at the 31th, that date needs to appear on that invoice

maiden scaffold
#

That's for the billing/recurring payments but not for one time payment with the Checkout Session

#

If you want to have a better handling, you could generate the invoice manually first, then use it's PaymentIntent to accept the payment with Stripe Elements for example

#

You need an advanced integration in this case, not using the Stripe hosted page (Checkout)

austere edge
#

This is not in my control

#

I am provider of a software for data synchronization

maiden scaffold
#

So that you have the invoice object when the customer submits the payment, then, you handle the failure as you said

austere edge
#

I can not control how my clients create invoices

maiden scaffold
#

Ah I see, sorry then, you need to adapt your integration to your client's integration

#

Or ask them to update it for better flexibility

austere edge
#

I know that you can not offer a solution right now, but this is really bad

#

It makes Stripe Billing not conform with gemran law

#

I guess barely anyone will notice, but theoretically, this would make the use of stripe billing illegal

maiden scaffold
#

There are multiple ways to use Stripe billing, it's a global product.So it's merchant needs to adapt the integration according to their need, that's why we provide the flexbility of integrating the products in different way

austere edge
#

I fear so

maiden scaffold
#

What I suggested above with creating the invoice, is part of Stripe billing actually.

#

I understand your frustration here and I'm sorry for that. But there is a solution as mentioned above if you need more flexibility with an advance control on the flow.

austere edge
#

I see. Thanks for clarification, I need to make plan to work around this.

#

Have a nice day!

maiden scaffold
#

Happy to help!