# Create a payment authorization Verifies a payment method and block the amount of fund that will be used for payment. Endpoint: POST /payment_methods/{payment_method_id}/authorize Version: 2025-11-12 Security: bearerAuth ## Path parameters: - `payment_method_id` (string, required) Payment Method Id ## Header parameters: - `zuora-track-id` (string) A custom identifier for tracking API requests. If you set a value for this header, Zuora returns the same value in the response header. This header enables you to track your API calls to assist with troubleshooting in the event of an issue. The value of this field must use the US-ASCII character set and must not include any of the following characters: colon (:), semicolon (;), double quote ("), or quote ('). - `async` (boolean) Making asynchronous requests allows you to scale your applications more efficiently by leveraging Zuora's infrastructure to enqueue and execute requests for you without blocking. These requests also use built-in retry semantics, which makes them much less likely to fail for non-deterministic reasons, even in extreme high-throughput scenarios. Meanwhile, when you send a request to one of these endpoints, you can expect to receive a response in less than 150 milliseconds and these calls are unlikely to trigger rate limit errors. If set to true, Zuora returns a 202 Accepted response, and the response body contains only a request ID. - `zuora-entity-ids` (string) An entity ID. If you have Multi-entity enabled and the authorization token is valid for more than one entity, you must use this header to specify which entity to perform the operation on. If the authorization token is only valid for a single entity or you do not have Multi-entity enabled, you do not need to set this header. - `idempotency-key` (string) Specify a unique idempotency key if you want to perform an idempotent POST or PATCH request. Do not use this header in other request types. This idempotency key should be a unique value, and the Zuora server identifies subsequent retries of the same request using this value. For more information, see Idempotent Requests. - `accept-encoding` (string) Include a accept-encoding: gzip header to compress responses, which can reduce the bandwidth required for a response. If specified, Zuora automatically compresses responses that contain over 1000 bytes. For more information about this header, see Request and Response Compression. - `content-encoding` (string) Include a content-encoding: gzip header to compress a request. Upload a gzipped file for the payload if you specify this header. For more information, see Request and Response Compression. ## Request fields (application/json): - `account_id` (string) A customer account identifier. Either account_id or account_number is required. Example: "2c92c0f86a8dd422016a9e7a70116b0d" - `account_number` (string) A Human-readable customer account identifier. Either account_id or account_number is required. Example: "RC-00000011" - `amount` (number, required) Amount to be authorized. - `gateway_id` (string) Identifier of the payment gateway that Zuora will use to authorize the payments that are made with this payment method. If you do not set this field, Zuora will use one of the following payment gateways instead: The default payment gateway of the customer account that owns the payment method, if the payment method is associated with a customer account or the default payment gateway of your Zuora tenant. Example: "8ad093d07ae636bb017ae97518762aa3" - `gateway_options` (object) A hash containing gateway-specific parameters. Example: {"key":"value"} - `gateway_order_id` (string, required) A merchant-specified natural key value that can be passed to the electronic payment gateway when a payment is created. If not specified, the payment number will be passed in instead. Gateways check duplicates on the gateway order ID to ensure that the merchant do not accidentally enter the same transaction twice. This ID can also be used to do reconciliation and tie the payment to a natural key in external systems. The source of this ID varies by merchant. Some merchants use their shopping cart order IDs, and others use something different. Merchants use this ID to track transactions in their eCommerce systems. When you create a payment for capturing the authorized funds, it is highly recommended to pass in the gateway_order_id that you used when authorizing the funds by using the Create authorization operation, together with the authorization_id field. - `statement_descriptor` (string) A payment gateway-specific field used by Orbital, Vantiv and Verifi. - `statement_descriptor_phone` (string) A payment gateway-specific field used by Orbital, Vantiv and Verifi. - `mandate` (object) - `mandate.type` (string) Indicates the type of mandate, if any. Enum: "multi_use", "single_use" ## Response 200 fields (application/json): - `auth_transaction_id` (string) Identifier of the authorization transaction from the payment gateway. - `gateway_order_id` (string) A merchant-specified natural key value that can be passed to the electronic payment gateway when a payment is created. If not specified, the payment number will be passed in instead. Gateways check duplicates on the gateway order ID to ensure that the merchant do not accidentally enter the same transaction twice. This ID can also be used to do reconciliation and tie the payment to a natural key in external systems. The source of this ID varies by merchant. Some merchants use their shopping cart order IDs, and others use something different. Merchants use this ID to track transactions in their eCommerce systems. When you create a payment for capturing the authorized funds, it is highly recommended to pass in the gateway_order_id that you used when authorizing the funds by using the Create authorization operation, together with the authorization_id field. - `state` (string) The status of the payment authorization. Enum: "approved", "queued_for_submission" ## Response 400 fields (application/json): - `type` (string) - `errors` (array) - `errors.code` (string) - `errors.parameter` (string) - `errors.message` (string) - `retryable` (boolean) ## Response 401 fields (application/json): - `type` (string) - `errors` (array) - `errors.code` (string) - `errors.parameter` (string) - `errors.message` (string) - `retryable` (boolean) ## Response 404 fields (application/json): - `type` (string) - `errors` (array) - `errors.code` (string) - `errors.parameter` (string) - `errors.message` (string) - `retryable` (boolean) ## Response 405 fields (application/json): - `type` (string) - `errors` (array) - `errors.code` (string) - `errors.parameter` (string) - `errors.message` (string) - `retryable` (boolean) ## Response 429 fields (application/json): - `type` (string) - `errors` (array) - `errors.code` (string) - `errors.parameter` (string) - `errors.message` (string) - `retryable` (boolean) ## Response 500 fields (application/json): - `type` (string) - `errors` (array) - `errors.code` (string) - `errors.parameter` (string) - `errors.message` (string) - `retryable` (boolean) ## Response 502 fields (application/json): - `type` (string) - `errors` (array) - `errors.code` (string) - `errors.parameter` (string) - `errors.message` (string) - `retryable` (boolean) ## Response 503 fields (application/json): - `type` (string) - `errors` (array) - `errors.code` (string) - `errors.parameter` (string) - `errors.message` (string) - `retryable` (boolean) ## Response 504 fields (application/json): - `type` (string) - `errors` (array) - `errors.code` (string) - `errors.parameter` (string) - `errors.message` (string) - `retryable` (boolean)