A capture adjustment changes the amount on a captured payment before it settles. Use it when the final charge changes after capture but before the batch closes, so you correct the transaction in place instead of refunding after settlement. 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 capture is in Approved status and its batch is Open. Once the batch settles, correct the amount with a Refund instead.

Common use cases

• Remove a shipping or convenience fee added by mistake
• Correct a POS entry error (for example, an extra digit)
• Apply a proration or credit before the batch closes

Make your first adjustment

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

PUT /checkout/v3/payment/4100000000761330

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

{
  "id": 4100000000761330,
  "status": "Approved",
  "amount": "165.00",
  "type": "SaleCompletion"
}

Scenarios

Every capture adjustment is the same PUT with paymentType: Adjustment and the new total; the business context only changes the amount. Capture adjustments are almost always downward corrections.

Scenario 1: Shipping fee included by mistake

Business context. A merchant captures $180 for an order that should have shipped free under the customer's loyalty tier — a $15 shipping fee was added by mistake. Before the batch closes, the merchant adjusts the capture down to $165.

PUT /checkout/v3/payment/4100000000761330

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

Scenario 2: POS entry error — wrong amount captured

Business context. A clerk accidentally captured $250 instead of $25 (an extra zero). The error is caught within the hour. The merchant adjusts the capture down to $25 before the batch closes — no refund needed.

PUT /checkout/v3/payment/4100000000761401

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

Scenario 3: Subscription proration

Business context. A SaaS company captures a $99 monthly fee on the 1st. On the 10th, the customer downgrades to a $66 plan. Because this merchant's batch settles at month-end, the company adjusts the capture down to $66 to reflect the prorated charge.

PUT /checkout/v3/payment/4100000000761455

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

Track the payment

Confirm an adjustment by retrieving the payment with GET /checkout/v3/payment/{id}; the amount reflects the new capture total and status is Approved. The full status model is in Payment Lifecycle.

Request reference

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

Statuses

An approved adjustment leaves the capture in Approved with the new amount, and it settles with the batch. 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 capture 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 capture returns an error, and your code falls back to a refund.
• Large corrections (for example, $250 to $25) work without tripping your own fraud alerts.

Best practices

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

Next steps

See also

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