-
Couldn't load subscription status.
- Fork 3
Description
Looking at Google Reserve's Idempotency requirements, and based on discussions in the last call, we should consider something similar:
Communication over the network is not always reliable and Google Reserve may retry REST HTTP request if no response is received. For this reason, CreateOrder calls must be idempotent. Requests include idempotency tokens that uniquely identify the request, and allow the partner to distinguish between a retried REST call and a separate order request.
Examples include but are not limited to:
- A successful CreateOrder HTTP response includes the created order. If the exact same CreateOrder request is received a second time (including idempotency_token), then the same CreateOrderResponse has to be returned. No second order is created and the user, if applicable, is charged exactly once. Note that if a CreateOrder attempt fails, the partner backend should retry if the same request is sent again.
This could be achieved in the OA implementations by simply having the idempotency_token stored alongside the order in the Orders table, and having the orders table queried for a matching idempotency_token before anything is done to avoid double-booking.
In order for this to work most easily, suggest #66 is considered first.