Consider Idempotency

[DavidAJohn]

As a reminder, the concept and practicalities around idempotency need to be considered with regard to the order process, both internally when the application saves orders and when orders are subsequently sent to Prodigi.

Here is Prodigi's reference to idempotency keys: https://www.prodigi.com/print-api/docs/reference/#order-object-idempotency-key

On a more conceptual level, here's a link to the MDN Docs: https://developer.mozilla.org/en-US/docs/Glossary/Idempotent

[DavidAJohn]

When an order is created in the application's database, MongoDb obviously generates a unique ID (or _id) for each document, so when sending an order to Prodigi, that unique Id must be sent in the 'idempotencyKey' field of the order.

[DavidAJohn]

After this commit, I'm happy that all due consideration has been given to idempotency, both in terms of orders created by the application itself and when processing responses from the Prodigi Print API.

As mentioned above, each order is initially created in the application's database with a GUID. From the Checkout page, a Stripe Checkout session is then created and only if payment is successful, the customer's name and address are captured from the Stripe session when it redirects to the success page. The Stripe Payment Intent Id is also recorded and stored with the order.

When creating an order with the Prodigi Print API, the application's original order Id is used to populate the IdempotencyKey field. This ensures that only one order can be created with Prodigi with that orderId, even if multiple requests were somehow sent to them. The application checks for this outcome ("AlreadyExists") in the response from Prodigi and logs the details at warning level.