How to work with idempotency keys and support retries without creating duplicate data
Idempotency refers to the ability to call an endpoint multiple times and receive the same result, without causing additional side effects.
When processing a payment, we want to prevent double-charging customers. Consider the following scenario, where an intermittent error in the Cash App Pay API requires the API client to retry a request:

HTTP 500HTTP 201 When the HTTP 500 is returned, the API client doesn’t know if a payment was created or not, because it doesn’t have visibility into the cause of the error.
To prevent duplicates, the Cash App Pay API requires the API client to provide an idempotency_key, which acts as a unique identifier for the payment creation request. When the API client retries the request, if Cash App Pay already finds an existing payment created with the given idempotency_key, it will return it instead of creating one.
idempotency_key to avoid any issues or while troubleshooting.Idempotency keys must be 1 to 64 characters long and unique across all requests made to a single endpoint. We recommend using UUIDs for this, but any string that fits the requirements will work.
Every endpoint in the Cash App Pay API is idempotent, either implicitly (i.e., read operations) or explicitly (where an idempotency key is required).
X-Region header (see Regions for more info) provided in the request. This allows Cash App Pay to run in multiple regions at once and achieve higher availability and lower latencies.X-Region of PDX, an API client creates an on file payment. The API client then retries the request with an X-Region of IAD X-Region. Idempotency is not guaranteed to span across regions. If a request is retried with a different X-Region header, it may create duplicate data.IDEMPOTENCY_KEY_REUSED error is returned.