> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pushcash.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Product updates and announcements

<Update label="June 2026">
  ## API Updates

  * Reorganized the documentation site around a focused set of core integration guides.
  * Published the Apple Pay withdrawals flow.
  * Published the ACH Save integration guide.

  ## Details

  The documentation site has been reorganized around a focused set of core integration guides — [Card Payments](/card-payments), [Apple Pay](/apple-pay), [ACH Save](/ach-save), and [Webhooks](/enabling-webhooks). Supplementary topics such as stored credentials, withdrawals, refunds, manual review, and multiple settlement accounts are now folded into the guides they belong to, and webhook event types are documented alongside the [Webhooks guide](/enabling-webhooks#webhook-types). See the [welcome guide](/welcome-guide) for an overview.

  Apple Pay now supports withdrawals (`cash_out`). A returning user can withdraw to a debit card they previously deposited with — no separate account linking required. See [Withdrawals](/apple-pay#withdrawals) in the Apple Pay guide.

  ACH Save is now documented. ACH Save recovers eligible declined card transactions by retrying them over ACH through an authenticated bank flow, lifting authorization rates on otherwise-lost volume. See the [ACH Save guide](/ach-save).
</Update>

<Update label="March 2026">
  ## API Updates

  * Refunds are now supported via the API, including issuing and managing refunds.
  * Simplified Apple Pay integration flow
  * Increased rate limits

  ## Details

  Operators can now issue refunds and track their status directly through the API. Use [create-refund](/apireference/refund/create-a-refund) to issue a refund, [get-a-refund](/apireference/refund/get-a-refund) to retrieve details for an individual refund, and [list-refunds](/apireference/refund/list-refunds) to query all refunds.

  The Apple Pay integration has been simplified — operators now call [authorize-payment](/apireference/authorization/authorize-payment) directly with the Apple Pay token, removing the need for a separate tokenization step. See the updated [Apple Pay guide](/apple-pay) for details.

  The [API Concepts](/api) page now includes an [environments section](/api#environments) documenting sandbox and production base URLs. [Rate limits](/api#rate-limiting) have been increased and the window has been shortened to per-minute, giving operators higher throughput for bursty workloads.
</Update>

<Update label="February 2026">
  ## API Updates

  * New `brand` field returned on card objects in intent and user responses.

  ## Details

  A `brand` field is now included on card objects returned by [get-intent](/apireference/intent/get-an-intent), [list-intents](/apireference/intent/list-intents), [get-user](/apireference/user/get-a-user), and [list-users](/apireference/user/list-users) endpoints. The field returns one of `mastercard`, `visa`, `amex`, or `discover`, enabling operators to display card brand information without maintaining their own BIN lookup.
</Update>

<Update label="January 2026">
  ## API Updates

  * New integration guides and restructured documentation.
  * Support for dynamic type assignment by omitting the type parameter in requests to the API
  * New `tag` field on the [authorize-payment](/apireference/authorization/authorize-payment) endpoint.

  ## Details

  The documentation has been completely refreshed with new step-by-step integration guides covering the full payment lifecycle. The previous hosted payment experience, card-only, and legacy integration guides have been retired and replaced with focused guides for each core workflow. See the [welcome guide](/welcome-guide) for an overview.

  The `tag` field on [authorize-payment](/apireference/authorization/authorize-payment) allows operators to supply an internal transaction record ID alongside the payment request for easier reconciliation.

  The `type` field on the [create-user-url](/apireference/user/create-user-url) request body is now optional. Operators who wish to have the payment type determined dynamically from the card BIN and operator configuration can omit the parameter.
</Update>

<Update label="July 2025">
  ## API Updates

  * Deprecation of idempotency header for create-user and authorize-payment endpoints.

  ## Details

  `X-Idempotency-Key` is now deprecated for the [create-user](/apireference/user/create-user#body-tag) and [authorize-payment](/apireference/authorization/authorize-payment) endpoints. Developers can continue to submit requests with the parameter, but it will no longer be read or used in the de-duplication of requests.

  For more details on how our API idempotent request handling logic works, see our [API Concepts](/api#idempotency) guide.
</Update>