Skip to main content
Some API endpoints support custom Prefer headers to indicate preferences for specific server behaviors during request processing. This allows the API to evolve, adding new features, while maintaining backwards compatibility where possible. The Prefer header is optional for all API requests. Endpoints that don’t support specific Prefer values ignore them without causing errors.

​
Prefer: resource=<resource_type>

Currently, only the Prefer: resource header is supported by the API. This header allows a merchant to opt into a different resource to return. Both the void and capture endpoints support this header to opt into returning a specific resource type.
  • Void
  • Capture
For example, by setting the Prefer: resource=transaction-void on a void call, the response type is a transaction-void resource, rather than the standard transaction returned by this API.
Request
POST /transactions/1a032928-abc0-4fb8-971e-fb917291e75f/void
Prefer: resource=transaction-void
Response
{
  "type": "transaction-void",
  "status": "failed",
  "code": "service_error",
  "raw_response_code": "1001",
  "raw_response_description": "Internal error, please retry",
  "transaction": {
    "type": "transaction",
    "id": "1a032928-abc0-4fb8-971e-fb917291e75f",
    ...
  }
}
Please note that HTTP header names are case-insensitive, as per HTTP standards, so you can use prefer, PREFER, or Prefer. The value of a header is case-sensitive and needs to be lower-case to match both the resource key and the <resource_type> value.