Hi Jack -- The response includes the created charge in context with the current invoice. It will be the first charge record in the DOM. In XPath, that's //charge[1]. Are you using a client lib of any kind? As an example, the PHP lib returns a DOM Document object which can be easily queried via XPath.

Hi Jack --

I've just tried to create several charges and looks like your answer is incorrect: newly added charge will be the last one (not the first one).

You're correct, my mistake. The convention is to reverse order records in the API response but it seems that charges does not follow that convention.

This also leads to potential race condition where one cannot be sure if he fetched charge he just created or charge that was created at the same moment by another process.

Good catch. I appreciate you more each time we have a discussion :) Requests that modify records are generally atomic when necessary (add-item-quantity comes to mind). I don't recall if creating a charge is atomic but I think it is. I'll have to research that in more detail to find out for sure. If it's not, it would only be the generation of the response itself that could potentially be done concurrently with another simultaneous request. In other words, multiple charges cannot be created concurrently but the response may be created concurrently.