Authorization and capture splits a card payment into two steps. First you authorize to reserve funds on the customer's card; later you capture to collect them. Use it when the final amount isn't known upfront, when there's a delay between order and fulfillment, or when you may need to cancel before charging. To authorize and capture in a single call, use Sale instead. For the full field list, jump to the Request reference.

Common use cases

Hotels and rentals: authorize an estimate at check-in, capture the final bill at check-out
Pre-orders: authorize when the order is placed, capture when the item ships
Restaurants and bars: authorize to open a tab, capture the final amount with tip

Make your first authorization

An authorization verifies the card and reserves the funds; no money moves yet. Send the minimal request below with paymentType: Authorization and authOnly: true.

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 150.00,
  "tenderType": "Card",
  "paymentType": "Authorization",
  "authOnly": true,
  "cardAccount": {
    "number": "5555555555554444",
    "expiryMonth": "10",
    "expiryYear": "37",
    "cvv": "798"
  },
  "source": "API"
}

You'll get back a 201 Created with status: Approved. Store the returned paymentToken: it's the key you'll use to capture the funds. availableAuthAmount shows how much of the hold is still available to capture.

{
  "created": "2026-05-14T07:22:13.703Z",
  "id": 4100000001181553,
  "paymentToken": "PRwek0WKzSOrnS5ce8WORn0zYs6231AA",
  "merchantId": 1000157980,
  "tenderType": "Card",
  "amount": "150",
  "authOnly": true,
  "authCode": "PPS418",
  "status": "Approved",
  "authMessage": "Approved or completed successfully",
  "originalAmount": "150",
  "availableAuthAmount": "150",
  "reference": "613407782251",
  "type": "Authorization",
  "responseCode": 0,
  "IssuerResponseCode": "00"
}

The endpoint is documented at POST /checkout/v3/payment.

📘
Use replayId for safe retries
Accept Payments uses the replayId field in the request body for safe retries; there's no separate header. Send a unique replayId per authorization and per capture, and if a request with the same value arrives again, we return the original response instead of processing it twice. See Idempotent Requests.

Capture the funds

When you're ready to collect (for example, the order ships), capture the authorized funds with another POST /checkout/v3/payment, this time with paymentType: SaleCompletion and the original paymentToken.

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 150.00,
  "tenderType": "Card",
  "paymentType": "SaleCompletion",
  "paymentToken": "PRwek0WKzSOrnS5ce8WORn0zYs6231AA",
  "source": "API"
}

The capture returns a 201 Created with status: Approved and type: SaleCompletion. originalId links the capture back to the authorization.

{
  "created": "2026-05-14T07:23:02.833Z",
  "id": 4100000001181561,
  "originalId": 4100000001181553,
  "paymentToken": "PCG0V9cHMGMgbkkmmIChwlZWkEnHBmzM",
  "merchantId": 1000157980,
  "tenderType": "Card",
  "amount": "150",
  "authCode": "PPS418",
  "status": "Approved",
  "authMessage": "Approved or completed successfully",
  "originalAmount": "150",
  "reference": "613407782261",
  "type": "SaleCompletion",
  "responseCode": 0,
  "IssuerResponseCode": "00"
}

You can capture the full amount, less than the amount (partial capture), or, where permitted, more (overcapture). The scenarios below show each pattern.

Scenarios

Every authorization and capture follows the same two-step flow; what changes per scenario is the timing and whether the captured amount equals, is less than, or exceeds the authorized amount.

sequenceDiagram
    participant You as Your Application
    participant PCE as PCE
    participant Network as Card Network
    participant Issuer as Cardholder's Bank

    Note over You,Issuer: Step 1: Authorize (reserve funds)
    You->>PCE: POST /checkout/v3/payment (authOnly: true)
    PCE->>Network: Authorization request
    Network->>Issuer: Verify card and reserve funds
    Issuer-->>Network: Approved (hold placed)
    Network-->>PCE: Approved
    PCE-->>You: 201 Created (status: Approved, paymentToken)

    Note over You,Issuer: Step 2: Capture (collect funds)
    You->>PCE: POST /checkout/v3/payment (paymentType: SaleCompletion)
    PCE->>Network: Capture request
    Network-->>PCE: Approved
    PCE-->>You: 201 Created (status: Approved)
    Note over PCE: At batch close, the capture settles (status: Settled)

Before you begin (all scenarios)

Your merchant account is active and configured for the card brands you plan to accept.
You store each authorization's paymentToken to capture against later.

Scenario 1: Hotel, pre-authorize at check-in and capture at check-out

Authorize an estimated total at check-in, then capture the final folio (which may be higher after incidentals) at check-out.

You'll also need: an initial authorization set high enough to absorb expected incidentals.

Step 1, authorize $500 at check-in

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 500.00,
  "tenderType": "Card",
  "paymentType": "Authorization",
  "authOnly": true,
  "customerName": "Maria Alvarez",
  "cardAccount": {
    "number": "4111111111111111",
    "expiryMonth": "12",
    "expiryYear": "28",
    "cvv": "123",
    "avsZip": "10001",
    "avsStreet": "350 5th Ave"
  },
  "source": "API"
}

Step 2, capture $575 at check-out

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 575.00,
  "tenderType": "Card",
  "paymentType": "SaleCompletion",
  "paymentToken": "PRwek0WKzSOrnS5ce8WORn0zYs6231AA",
  "source": "API"
}

📘
Capturing more than the authorized amount is an overcapture and is subject to card network and issuer limits. For hospitality, set the initial authorization high enough to cover expected incidentals so the final capture stays within the allowed range. See the capture-behavior note under Scenarios.

Scenario 2: E-commerce pre-order, authorize at order and capture when shipped

Authorize the card when the pre-order is placed, then capture the same amount once the warehouse confirms the shipment.

You'll also need: a way to trigger the capture when fulfillment is confirmed.

Step 1, authorize $200 at order placement

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 200.00,
  "tenderType": "Card",
  "paymentType": "Authorization",
  "authOnly": true,
  "customerName": "Jordan Lee",
  "cardAccount": {
    "number": "5454545454545454",
    "expiryMonth": "09",
    "expiryYear": "27",
    "cvv": "321",
    "avsZip": "94107"
  },
  "source": "API"
}

Step 2, capture $200 when the shipment leaves the warehouse

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 200.00,
  "tenderType": "Card",
  "paymentType": "SaleCompletion",
  "paymentToken": "P6cvowNEayS5IzoLDC8yovPeMlwW9GsJ",
  "source": "API"
}

Scenario 3: Restaurant, open a tab and capture with tip

Authorize the check amount when the card is run, then capture the final total including the tip.

You'll also need: the tip amount, added to the capture total.

Step 1, authorize $50 when the check is presented

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 50.00,
  "tenderType": "Card",
  "paymentType": "Authorization",
  "authOnly": true,
  "customerName": "Priya Patel",
  "cardAccount": {
    "number": "378282246310005",
    "expiryMonth": "06",
    "expiryYear": "29",
    "cvv": "1234"
  },
  "source": "API"
}

Step 2, capture $62.50 after the tip is added

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 62.50,
  "tip": 12.50,
  "tenderType": "Card",
  "paymentType": "SaleCompletion",
  "paymentToken": "P1nLHufinokkQZ6rex2CL8T43HXVni0u",
  "source": "API"
}

Scenario 4: Split shipment, one authorization and multiple captures

Authorize the order total once, then capture each shipment separately as it goes out, so the customer is billed only for what has shipped.

You'll also need: to track the captured-to-date total so you don't exceed the authorization.

Step 1, authorize $200 at order placement

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 200.00,
  "tenderType": "Card",
  "paymentType": "Authorization",
  "authOnly": true,
  "cardAccount": {
    "number": "4111111111111111",
    "expiryMonth": "04",
    "expiryYear": "28",
    "cvv": "456"
  },
  "source": "API"
}

Step 2, capture $120 when warehouse A ships

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 120.00,
  "tenderType": "Card",
  "paymentType": "SaleCompletion",
  "paymentToken": "PPf0TeJfKdJ6gXwnELkXp4ZtYgUlysCu",
  "source": "API"
}

Step 3, capture $80 when warehouse B ships

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 80.00,
  "tenderType": "Card",
  "paymentType": "SaleCompletion",
  "paymentToken": "PPf0TeJfKdJ6gXwnELkXp4ZtYgUlysCu",
  "source": "API"
}

Scenario 5: Partial fulfillment, capture what shipped and release the rest

When part of an order can't be fulfilled, capture only the shipped amount. Release the unused hold by voiding the authorization so the customer's available balance is accurate right away.

You'll also need: the Void a Payment call to release the remaining hold.

Step 1, authorize $100 at order placement

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 100.00,
  "tenderType": "Card",
  "paymentType": "Authorization",
  "authOnly": true,
  "cardAccount": {
    "number": "6011111111111117",
    "expiryMonth": "08",
    "expiryYear": "27",
    "cvv": "789"
  },
  "source": "API"
}

Step 2, capture $80 for the items that shipped

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 80.00,
  "tenderType": "Card",
  "paymentType": "SaleCompletion",
  "paymentToken": "PdjN6mF2KQwLpxRGzVnYbB8mTcHE3sQA",
  "source": "API"
}

To release the remaining $20 hold immediately instead of waiting for the authorization to expire, void it with DELETE /checkout/v3/payment/{id}. See Void a Payment.

Track the payment

Read status and responseCode on each response for the immediate outcome. To follow the payment afterwards, retrieve it with GET /checkout/v3/payment/{id} or subscribe to webhooks:

PaymentSuccess: the authorization or capture was approved.
PaymentFail: the authorization or capture was declined.

The authorization and the capture both return status: Approved; the captured payment moves to Settled at batch close. The full status model and settlement flow are in Payment Lifecycle and Webhook Event Types.

Request reference

Authorization parameters

Parameter	Required	Description
`merchantId`	✓	Your PCE merchant identifier that receives the payment.
`amount`	✓	Amount to authorize, in the account currency (USD by default).
`paymentType`	✓	Set to `Authorization`.
`tenderType`	✓	Set to `Card` for card payments.
`authOnly`	✓ (auth)	Set to `true` to authorize without capturing.
`cardAccount`	Conditional	The card to authorize. Required when `tenderType` is `Card`. Pass raw card details or a vaulted `token`. See Sale, card account fields.
`replayId`	Recommended	Your unique retry key. Retrying with the same value returns the original response. See Idempotent Requests.
`customerName`	Optional	Cardholder's full name. Recommended for guest checkout where the card isn't vaulted.
`posData`	Recommended	Point-of-sale data describing how the transaction was captured. See Transaction Context.

Capture parameters

Parameter	Required	Description
`merchantId`	✓	Your PCE merchant identifier.
`amount`	✓	Amount to capture. Can be full, partial, or (where allowed) higher.
`paymentType`	✓	Set to `SaleCompletion`.
`tenderType`	✓	Set to `Card`.
`paymentToken`	✓	The `paymentToken` returned by the authorization you're capturing.
`tip`	Optional	Gratuity to add to the captured total (included in `amount`).

Validation

The prerequisites above are the validations, and PCE enforces them when you submit. A submission is checked synchronously; if a check fails, the request returns an error and nothing is created. Submission checks:

Required fields are present and correctly formatted.
The card details or token resolve to a chargeable card (authorization), or the paymentToken resolves to an authorized payment (capture).
Your merchant account is permitted to process the requested card brand and amount.

Conditions judged by the card network, such as insufficient funds or an issuer decline, surface on the response as status: Declined with a responseCode. See Handling Declines.

Statuses

Both the authorization and the capture return Approved or Declined immediately. An approved capture stays adjustable until batch close, when it moves to Settled; voiding before settlement moves it to Voided. Accept Payments uses the shared Payment Lifecycle for every status and how a payment progresses to settlement.

If an authorization or capture is declined

The response returns status: Declined with a responseCode and authMessage explaining why.
Match the code to guidance on Payment Response Codes and Handling Declines.
To release an approved authorization you no longer need, use Void a Payment.

Go live

The shared pre-production checklist (production credentials, webhook subscription, idempotency, and sandbox testing) is in Getting Started. Specific to authorization and capture, also confirm:

Authorization then full capture works end-to-end in sandbox with a 201 Approved response.
Partial capture behaves as expected, and you release any unused hold with a void.
Multiple captures against one authorization sum to no more than the authorized amount.
Decline handling covers both the authorization and the capture step.

Best practices

General practices (set a unique replayId, subscribe to webhooks, test in sandbox) are in Getting Started. Specific to authorization and capture:

Practice	Description
Capture promptly	Capture within the authorization hold window. Capturing late can require a fresh authorization and risks a decline if the balance changed.
Include AVS data	Pass `avsZip` and `avsStreet` in `cardAccount` on the authorization to reduce fraud and can lower interchange fees.
Submit Level II/III for B2B	For business, corporate, or government cards, Level II/III data can significantly reduce interchange costs. See Interchange Optimization.
Void unused authorizations	After a partial capture, void the authorization to release the remaining hold instead of waiting for it to expire.
Store the `paymentToken`	The authorization's `paymentToken` is the key for every capture against it. Persist it with your order reference.
Increase before overcapture	If the final amount may exceed the authorization, raise it first with Authorization Adjustment rather than relying on overcapture.

Next steps

Authorization Adjustment

Increase or decrease a hold before you capture.

Void a Payment

Release an authorization you no longer need.

Authorization and Capture

Make your first authorization

Use `replayId` for safe retries

Capture the funds

Scenarios

Scenario 1: Hotel, pre-authorize at check-in and capture at check-out

Scenario 2: E-commerce pre-order, authorize at order and capture when shipped

Scenario 3: Restaurant, open a tab and capture with tip

Scenario 4: Split shipment, one authorization and multiple captures

Scenario 5: Partial fulfillment, capture what shipped and release the rest

Track the payment

Request reference

Authorization parameters

Capture parameters

Validation

Statuses

Go live

Best practices

Next steps

See also

Make your first authorization

Use replayId for safe retries

Capture the funds

Scenarios

Scenario 1: Hotel, pre-authorize at check-in and capture at check-out

Scenario 2: E-commerce pre-order, authorize at order and capture when shipped

Scenario 3: Restaurant, open a tab and capture with tip

Scenario 4: Split shipment, one authorization and multiple captures

Scenario 5: Partial fulfillment, capture what shipped and release the rest

Track the payment

Request reference

Authorization parameters

Capture parameters

Validation

Statuses

Go live

Best practices

Next steps

See also

Use `replayId` for safe retries