I see what you mean, but I've never used an API where you could wrap arbitrary sets of API calls in a transaction on the remote side. In general once you are in

I see what you mean, but I've never used an API where you could wrap arbitrary sets of API calls in a transaction on the remote side. In general once you are in the distributed systems world there are no transactions. I think that would make for a very hard to use API. You would need to send all the API calls at once without receiving responses for the individual calls. So if you were doing something that requires 4 api calls you would need to send all 4, even if the first one is going to fail anyway. So you wouldn't be able to get/create a customer ID and use it in the next API call to create a subscription. You would need to generate all the IDs locally first. Even after all that, the transaction could commit on the stripe side, and you still might not get a response back that it worked. So how would you ask stripe "did this collection of API calls work?" With their API you either get a customer id back, or you get an error, or you get nothing back. Then you either get a subscription id back, or you get an error, or you get nothing back. * If you get a customer id back you go on to create the subscription. * If you get an error or nothing back you keep retrying until you get a customer id back. Then you go on to create the subscription following the same retry logic. The impotency key ensures when you get the subscription id back you have created the customer exactly once, and the subscription exactly once. Having a "dangling customer" is not a problem - when you fix whatever is wrong with your "create subscription" call you don't create a new customer - you just link that existing customer to the subscription. You'll have the customer ID at that point.