Voiding cancels a payment before it settles, releasing the hold on the customer's card. Use it to cancel an approved authorization or an approved sale that hasn't settled yet, for example when an item is out of stock or the customer changes their mind. Because no funds have moved, a void leaves no charge on the customer's statement and avoids the fees of capturing and then refunding. For the full field list, jump to the Request reference.

Once a payment has settled, you can no longer void it; issue a Refund instead.

Common use cases

Cancel an authorization when an order can't be fulfilled
Reverse an approved payment your risk checks reject after the fact
Cancel the duplicate when a customer is authorized twice
Cancel a same-day sale before the batch closes

Make your first void

Voiding is a single DELETE against the payment's id. First confirm the payment hasn't settled (its status is Approved, not Settled), then void it.

DELETE /checkout/v3/payment/4100000000869748

The void returns a 204 No Content with an empty body. Confirm the result by retrieving the payment: its status is now Voided.

GET /checkout/v3/payment/4100000000869748

{
  "id": 4100000000869748,
  "status": "Voided",
  "amount": "33.33",
  "type": "Sale",
  "reference": "600607253032"
}

The endpoint is documented at DELETE /checkout/v3/payment/{id}. To void a payment that has already settled, pass force=true (this issues a return).

When to void

Every void is the same API call; the business context only decides when you void. Void whenever a payment is approved but not yet settled and you need to cancel it.

Situation	Action	Why void instead of refund
Authorization placed, item out of stock	Void the authorization	No funds moved; nothing appears on the statement
Authorization approved, risk checks reject the order	Void the authorization	Releases the hold before any chargeback risk
Customer authorized twice (double-click)	Void the duplicate	Prevents a double charge; use idempotency to prevent recurrence
Customer cancels a sale the same day, before batch close	Void the sale	Avoids interchange on both a charge and a later refund
Unused hold after a partial capture	Void the authorization	Releases the remaining hold immediately

📘
Check settlement state first. If the payment's status is already Settled, a plain void fails because the funds have left the issuer. Issue a Refund instead, or void with force=true to issue a return.

Track the payment

Confirm a void by retrieving the payment with GET /checkout/v3/payment/{id}; the status changes to Voided. The full status model and settlement flow are in Payment Lifecycle.

Request reference

Parameter	Required	Description
`id` (path)	✓	The `id` of the payment to void, from the original authorization or sale response.
`force` (query)	Optional	If `true`, void even if the payment has settled (issues a return). Default `false`.

Validation

PCE checks the void synchronously; if it fails, nothing changes on the payment. Submission checks:

The id resolves to a real payment for your merchant account.
The payment has not settled (unless you pass force=true).

A void attempted on an already-settled payment (without force) returns an error. See Handling Declines and Payment Response Codes.

Statuses

A voided payment moves to Voided, and no funds are transferred. Voids apply only before settlement; a Settled payment must be refunded. Accept Payments uses the shared Payment Lifecycle for every status.

Go live

The shared pre-production checklist (production credentials, webhooks, idempotency, sandbox testing) is in Getting Started. Specific to voids, also confirm:

Voiding an unsettled authorization and an unsettled sale both return 204 and show Voided on a follow-up GET.
Voiding a settled payment without force returns an error, and your code falls back to the refund flow.
Your integration checks the payment status before attempting a void.

Best practices

General practices (idempotency, webhooks, sandbox testing) are in Getting Started. Specific to voids:

Practice	Description
Check settlement state first	Retrieve the payment and confirm `status` is `Approved`, not `Settled`, before voiding.
Void, don't refund, pre-settlement	A void avoids interchange fees and leaves no charge on the statement; a refund posts a charge and a credit.
Void promptly	Cancel as soon as you decide, so the pending hold doesn't linger on the cardholder's statement.
Prevent duplicates at source	Use a unique `replayId` on the original payment so retries don't create duplicate authorizations to clean up.
Log the void reason	Store why you voided (out-of-stock, fraud, duplicate, customer request) with the `id` for reconciliation.

Next steps

Refund

Return funds once a payment has settled.

Authorization and Capture

Reserve funds and capture later.

Void a Payment

Make your first void

When to void

Track the payment

Request reference

Validation

Statuses

Go live

Best practices

Next steps

See also