An authorization adjustment changes the amount on an existing authorization before it's captured. It's essential when the final charge isn't known at authorization time, as in fuel, hotel, and car rental scenarios. Adjusting the authorization instead of creating new ones reduces declines at capture and avoids stacking multiple holds on the cardholder's funds. 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 authorization is in Approved status (not yet captured) and its batch is Open. Once captured, use Capture Adjustment instead.

Common use cases

• Reduce a fuel pre-authorization to the actual pump total
• Increase a hotel authorization for incidentals before check-out
• Increase a car rental authorization for add-ons at pickup
• Reduce an order authorization when an item is removed before fulfillment

Make your first adjustment

Confirm the authorization is still uncaptured (status: Approved, batch Open), then PUT the new total to /checkout/v3/payment/{id} with paymentType: Adjustment.

PUT /checkout/v3/payment/4100000000751120

{
  "merchantId": 1000157980,
  "tenderType": "Card",
  "paymentType": "Adjustment",
  "paymentToken": "PFBeGZaziZXBgCufaqPuVRLY6FlyJhGL",
  "amount": 170.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/4100000000751120

{
  "id": 4100000000751120,
  "status": "Approved",
  "amount": "170.00",
  "type": "Authorization"
}

The authorization is now ready to capture at the new amount. See Authorization and Capture.

Scenarios

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

Scenario 1: Gas station — reduce pre-auth to the actual fuel total

Business context. A gas station places a $200 authorization when the customer inserts their card at the pump. The customer finishes fueling at $170. The station adjusts the authorization down to $170 before capture; the remaining $30 hold is released.

PUT /checkout/v3/payment/4100000000751120

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

Scenario 2: Car rental — add-on at the counter

Business context. A rental agency authorizes $250 at booking for a three-day economy rental. At pickup the customer adds collision coverage ($75). The agency adjusts the authorization up to $325 before the vehicle leaves the lot.

PUT /checkout/v3/payment/4100000000751188

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

Scenario 3: Hotel — incidentals before check-out

Business context. A hotel authorizes $500 at check-in for a two-night stay. The guest adds $50 room service and $30 spa. Before check-out the hotel adjusts the authorization to $580 so a single capture clears the full folio.

PUT /checkout/v3/payment/4100000000751244

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

Track the payment

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

Request reference

Send a PUT to /checkout/v3/payment/{id}, where {id} is the original authorization'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 authorization is still Approved (uncaptured) with an Open batch. An adjustment on a captured or settled payment is rejected. See Payment Response Codes and Handling Declines.

Statuses

An approved adjustment leaves the authorization in Approved with the new amount, ready to capture. An upward adjustment 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 authorization 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.
• Capturing after adjustment settles at the adjusted amount.
• An adjustment on an already-captured authorization returns an error, and your code falls back to capture adjustment.

Best practices

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

Next steps

See also

• Authorization and Capture: reserve funds and capture later
• Sale Adjustment: adjust a completed sale
• Capture Adjustment: adjust after capture, before settlement
• Void a Payment: cancel entirely before settlement
• Payment Lifecycle: statuses, tracking, and settlement