One of the most serious problems a payment system can have is to double charge a customer. When we design the payment system, it is important to guarantee that the payment system executes a payment order exactly-once. At the first glance, exactly-once delivery seems very hard to tackle, but if we divide the problem into two parts, it is much easier to solve. Mathematically, an operation is executed exactly-once if:
1. Let's say the client is required to generate a UUID every request and that becomes the idempotent key.
Q1) What happens when the client doesn't send this information, how should the server behave?
Q2) Should this UUID be considered unique for each request, if not, then should there be a time frame set for a particular one, after which u can send the same UUID but different information?
Q3) Should the idempotent key be mapped with the domain forming a composite, otherwise multiple clients can end up sending the same UUIDs.
Thank you for posting.
I have a follow up questions to this:
1. Let's say the client is required to generate a UUID every request and that becomes the idempotent key.
Q1) What happens when the client doesn't send this information, how should the server behave?
Q2) Should this UUID be considered unique for each request, if not, then should there be a time frame set for a particular one, after which u can send the same UUID but different information?
Q3) Should the idempotent key be mapped with the domain forming a composite, otherwise multiple clients can end up sending the same UUIDs.
why do we put the key in HTTP header not request body? I'm not familiar with payment.
stripe recommends V4 UUIDs to be used as a best practice