#sam-porter-bridges_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/1328493849525489739
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hi there
No, this isn't currently possible
Well, a "rollback" isn't possible. In this specific scenario, you could void the credit note and void the invoice but those would be two separate, manual calls
Would an idempotency key on the request to create the credit note prevent an error on the 2nd attempt if the request parameters are identical?
We do issue voids on decline at this point
Customers pay for a programming class date and time with us, we put that on an invoice and they pay for it.
Then if they want to change class times, we credit the prior invoice and create a new one, then pay the new invoice And in theory, the new invoice amount is $0 because the line item amounts are the same between classes
Just trying to use the most robust method of dealing with errors/interruptions in that process
not sure I follow this question
Are you asking if you can void the credit note if you passed an idempotency key when creating it?
No, asking if I can prevent stripe from creating the credit note a 2nd time with an idempotency key
That would avoid needing to issue a void
it wouldn't be transactional either, but it would allow me to repeat the same code without needing to write void logic and without needing to write something that checks for an existing credit note before creating a new one
Okay, I'm still not quite sure what you're getting at but maybe this will help
If you make a Request A to create a Credit Note with an idempotency key 123 and that request succeeds, making Request B to create a Credit Note with the same idempotency key 123 will just return the results of Request A. A duplicate Credit Note won't be created
Conversely, if you make a Request C to create a Credit Note with an idempotency key 456 and that request fails, making Request D to create a Credit Note with the same idempotency key 456 will just return the results of Request C. No new Credit Note will be created
that makes sense