Skip to main content
​

​
API Updates

​
Details

A card_brand field is now included on each credential returned by list-user-credentials. The field returns one of mastercard, visa, amex, or discover, so a returning user’s stored credentials can be displayed with their brand alongside card_last4.
​

​
API Updates

  • New Ledger reference guide covering transactions, transfers, and reconciliation.
  • The transaction and transfer objects now use the settlement-lifecycle model: unsigned amount, cash_in / cash_out direction, and a four-stage transaction status.
  • New Disputes section in the Card Payments guide and a dispute.created webhook delivered when a chargeback or ACH return is opened against a payment.

​
Details

The Ledger guide explains how Push records money movement as transactions and settles them into transfers on a fixed schedule, and how to reconcile that activity against your own books. It consolidates the former Settlement reference into a single guide.The Disputes section of the Card Payments guide explains how Push records card chargebacks and ACH returns as disputes tied to the original intent, how a dispute resolves to won or lost, and how to track it. Push now delivers a dispute.created webhook to the endpoint configured on the originating payment when a dispute is opened, so you learn a payment is being reversed without polling.The transaction object has been updated to reflect the settlement lifecycle directly:
  • amount is now an unsigned integer; use direction (cash_in / cash_out) to determine which way the money moved, replacing the previous signed amount with credit / debit.
  • status now exposes the full lifecycle — pending, available (cash_in only), in_transfer (cash_out only), and settled — rather than only pending / settled.
  • type is one of intent, refund, or dispute, identifying what created the transaction.
  • A transfer object is now included once a transaction reaches in_transfer or settled, linking it to the transfer that settles it.
  • The batch field has been removed.
The transfer object now reports an unsigned amount and a direction of disbursement (a net payout to your operational account) or collection (a net withdrawal from it), and its transactions array is the exact set of transactions that net to the transfer amount. See Reconciliation for how to use this.
​

​
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, Apple Pay, ACH Save, and 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. See the 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 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.
​

​
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 to issue a refund, get-a-refund to retrieve details for an individual refund, and list-refunds to query all refunds.The Apple Pay integration has been simplified — operators now call authorize-payment directly with the Apple Pay token, removing the need for a separate tokenization step. See the updated Apple Pay guide for details.The API Concepts page now includes an environments section documenting sandbox and production base URLs. Rate limits have been increased and the window has been shortened to per-minute, giving operators higher throughput for bursty workloads.
​

​
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, list-intents, get-user, and 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.
​

​
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 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 for an overview.The tag field on 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 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.
​

​
API Updates

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

​
Details

X-Idempotency-Key is now deprecated for the create-user and 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 guide.