#aki_checkout-invoice-creation
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/1239547047259148298
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
also what is needed to know : im using the invoiceid inside my checkpromotion method to retrieve the invoice object and check for an used promotion code.
the problem is. after my redirect (session is paid and invoices will be created automatically), the session.InvoiceId is null
hi there!
can you share a Checkout Session ID (cs_xxx) with this issue and without this issue?
im trying let me reproduce the issue. mom*
funny part is also : when i check sessions via postman . its never nul
im also working in a .NET enviroment btw
cs_test_b1GSPWQy1uVeNPSCacRUJDq3zsrOmyDp7A7BgF8zp5cJ7v5ExcGUu29mK0
i have a breakpoint at : var promotionCode = await CheckPromotionCode(session.InvoiceId
session.invoiceId is null right now
if i retrive this id with postman i get on the invoice field : "invoice": "in_1PFxZ9F8xGnOlFmmYV0jD738"
when do you retrieve the Checkout Session exactly? when listening to the checkout.session.completed event?
idk whats happening in my backend (.NET) .. this is my code to get the session object; var session = await sessionService.GetAsync(sessionId);
after my redirect to my payment page : "http://localhost:3000/payment/?CHECKOUT_SESSION_ID={CHECKOUT_SESSION_ID}",
i have an api call that grabs the parameter to get the session object.
var session = await sessionService.GetAsync(sessionId);
it's possible the Invoice ID gets added async, so maybe a few seconds later. if you try to fetch the Checkout Session ID now, I4m guessing there will be an invoice ID?
its true a bit later i can retrieve the invoice data
yes it's not ideal but it should work
but its still not "working" in terms of tracking used promotion codes. i can retrieve afterwards some invoice data. but what i want is to check if any promotion code was used ( after payment ). even 5 second delay wont do any changes
you want to know if users entered a promotion code in the Checkout Session?
yes . but right now it is working ( i guess ). i have set the delay now to 5 secs before i do the api call to check the payment. and both use cases ( paying the checkout session with promo code and without promo code ) are working.
Hi there ๐ jumping in as my teammate needs to step away soon. Is there information that you need to get from the Invoice object specifically, or is it something that can also be gotten from the Checkout Session object itself?
aki_checkout-invoice-creation
so what we want is to give the opportunity to use promotion codes in the users checkout session. on our side of the app we are saving some of the transaction details. we do also want to save the promotion code that was used in a transaction ( we are using a sql database )
the only way i found out , that shows if a promotion code was uses, is by checking the invoice object of a session
Gotcha, do you just need to save it to your database (in which case I'd recommend using a webhook endpoint instead of a success url) or do you also need to immediately display those details back to the customer on your success page?
i know webhook would be fine deal but rn we dont have it implemented. looking for a solution without using them. we just want to keep track of the used promotion code. for my use-case "one-time payments" its acutally working.
I'd suggest them because they're a better solution. Using a success url approach relies on your customers making it to that success page and it loading. If they lose connection unexpectedly, or close their browser quickly, your downstream processes may never trigger after accepting their payment. That risk is avoided with webhook endpoints.