A sale adjustment changes the amount of a sale (a single-step authorization and capture) after it's been processed but before its batch settles. Use it when the final billed amount changes shortly after checkout, so you correct the transaction in place instead of refunding and rebilling. You always send the new total amount, not the difference. For the full field list, jump to the Request reference.

An adjustment is a PUT to the payment with paymentType: Adjustment. It works only while the sale is in Approved status and its batch is still Open; once the sale settles, adjust it with a Refund instead.

Common use cases

• Add a tip to a closed-out check (restaurants)
• Apply a promo code or discount a customer forgot at checkout
• Correct a tax or pricing error caught the same day
• Reduce the amount when an item is removed before settlement

Make your first adjustment

First confirm the sale is still adjustable (its status is Approved and its batch is Open), then PUT the new total to /checkout/v3/payment/{id} with paymentType: Adjustment.

PUT /checkout/v3/payment/4100000000748656

{
  "merchantId": 1000157980,
  "tenderType": "Card",
  "paymentType": "Adjustment",
  "paymentToken": "PFBeGZaziZXBgCufaqPuVRLY6FlyJhGL",
  "amount": 55.00,
  "source": "API"
}

A successful adjustment returns 200 OK with an empty body. Confirm the new amount by retrieving the payment:

GET /checkout/v3/payment/4100000000748656

{
  "id": 4100000000748656,
  "status": "Approved",
  "amount": "55.00",
  "type": "Sale"
}

Before adjusting, verify the sale is still open with either check:

• GET /checkout/v3/payment/{id} — the payment status is Approved, not Settled.
• GET /checkout/v3/batch/{id}?echo=true — the batch status is Open.

Scenarios

Every sale adjustment is the same PUT with paymentType: Adjustment and the new total; the business context only changes the amount and its direction.

Scenario 1: Restaurant tip added to a closed-out check

Business context. A casual-dining restaurant processes a $45 sale when the customer pays. The customer adds a $10 tip on the printed receipt. Before the nightly batch closes, the server adjusts the sale to $55.

PUT /checkout/v3/payment/4100000000748656

{
  "merchantId": 1000157980,
  "tenderType": "Card",
  "paymentType": "Adjustment",
  "paymentToken": "PFBeGZaziZXBgCufaqPuVRLY6FlyJhGL",
  "amount": 55.00,
  "source": "API"
}

Returns 200 OK (empty body). A follow-up GET shows amount: "55.00", status: "Approved".

Scenario 2: Promo code applied after checkout

Business context. A customer completes an $80 online checkout, then remembers a 10% promo code and contacts support. Because the batch is still open, support adjusts the sale down to $72 instead of refunding.

PUT /checkout/v3/payment/4100000000748701

{
  "merchantId": 1000157980,
  "tenderType": "Card",
  "paymentType": "Adjustment",
  "paymentToken": "PRwek0WKzSOrnS5ce8WORn0zYs6231AA",
  "amount": 72.00,
  "source": "API"
}

Scenario 3: Upward correction (tax fix)

Business context. A retailer applied a 7% tax rate to an order shipping to a 9% jurisdiction, charging $107 instead of $109 on a $100 pre-tax order. The error is caught the same day and the sale is adjusted up to $109.

PUT /checkout/v3/payment/4100000000748755

{
  "merchantId": 1000157980,
  "tenderType": "Card",
  "paymentType": "Adjustment",
  "paymentToken": "PXm3kZ1aQ0rnS5ce8WORn0zYs6231BB",
  "amount": 109.00,
  "source": "API"
}

Track the payment

Confirm an adjustment by retrieving the payment with GET /checkout/v3/payment/{id}; the amount reflects the new total and status is Approved (or Declined on an upward adjustment that failed). The full status model is in Payment Lifecycle.

Request reference

Send a PUT to /checkout/v3/payment/{id}, where {id} is the original sale's id.

A successful adjustment returns 200 OK with an empty body. Retrieve the payment to see the updated amount and status.

Validation

PCE validates the adjustment synchronously before sending it to the card network. If validation fails, nothing changes on the payment. Checks include required fields, correct formats, and that the sale is still Approved with an Open batch. An adjustment on a settled sale is rejected. See Payment Response Codes and Handling Declines.

Statuses

An approved adjustment leaves the sale in Approved with the new amount, and it settles with the batch. An upward adjustment that the issuer declines returns Declined and leaves the original amount in place. Accept Payments uses the shared Payment Lifecycle.

Go live

The shared pre-production checklist is in Getting Started. Specific to sale adjustments, also confirm:

• A downward adjustment returns 200 and a follow-up GET shows the lower amount.
• An upward adjustment returns 200 and shows the higher amount.
• An upward adjustment on an underfunded card returns a decline your code handles.
• An adjustment on a settled sale returns an error, and your code falls back to a refund.

Best practices

General practices are in Getting Started. Specific to sale adjustments:

Next steps

See also

• Authorization Adjustment: adjust before capture
• Capture Adjustment: adjust after capture, before settlement
• Void a Payment: cancel entirely before settlement
• Refund: return funds after settlement
• Payment Lifecycle: statuses, tracking, and settlement