A sale charges a customer's card for goods or services and settles the funds to your account. It combines authorization (verifying the card and reserving the funds) and capture (collecting them) into one call, so use it whenever you deliver the product or service right away. For the full field list, jump to the Request reference.

To authorize now and capture later (for example, when you ship before you charge), see Authorization and Capture instead.

Common use cases

Sell digital goods, downloads, online courses, or streaming access
Complete on-demand services such as ride-sharing or one-time consultations
Take retail or e-commerce checkout payments that ship right after the order

Make your first payment

The fastest way to see it work: charge a card with the minimal fields below. The full set of options is in the Request reference.

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 33.33,
  "tenderType": "Card",
  "paymentType": "Sale",
  "cardAccount": {
    "number": "5425233430109903",
    "expiryMonth": "06",
    "expiryYear": "35",
    "cvv": "579",
    "avsZip": "12321"
  },
  "source": "API"
}

You'll get back a 201 Created with status: Approved. Store the returned id (use it to retrieve or void the payment before it settles) and paymentToken (use it for follow-up refunds or adjustments after settlement).

{
  "created": "2026-01-06T07:11:30.9Z",
  "id": 4100000000869748,
  "paymentToken": "PYVrf077uthlfkIiAMXMEE0BJECoXkrf",
  "merchantId": 1000157980,
  "tenderType": "Card",
  "amount": "33.33",
  "authOnly": false,
  "authCode": "PPS607",
  "status": "Approved",
  "authMessage": "Approved and completed successfully",
  "reference": "600607253032",
  "type": "Sale",
  "responseCode": 0,
  "IssuerResponseCode": "00"
}

Read status for the outcome (Approved or Declined) and responseCode for the reason. The endpoint is documented in the API reference 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 sale, and if a request with the same value arrives again, we return the original response instead of charging the card twice. See Idempotent Requests.

Scenarios

Every sale follows the same payment lifecycle. The only thing that changes per scenario is how you supply the card, so pick the one that matches the problem you're solving.

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

    You->>PCE: POST /checkout/v3/payment (paymentType: Sale)
    PCE->>PCE: Validate request
    PCE->>Network: Authorize and capture
    Network->>Issuer: Request approval
    Issuer-->>Network: Approved
    Network-->>PCE: Approved
    PCE-->>You: 201 Created (status: Approved)
    PCE-->>You: Webhook (PaymentSuccess)
    Note over PCE: At batch close, the payment settles (status: Settled)

Before you begin (all scenarios)

Your merchant account is active and configured to accept the card brands you plan to charge.

Each scenario below changes only how the card is provided.

Scenario 1: Charge a card entered at checkout

(raw card details passed inline)

Use this for guest checkout, when the customer enters their card and you don't save it. Pass the card number, expiry, and (where required) CVV and AVS details directly in cardAccount.

You'll also need: the card number, expiry month and year, and CVV.

Request

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 108.06,
  "tenderType": "Card",
  "paymentType": "Sale",
  "cardAccount": {
    "name": "Alex Johnson",
    "number": "378282246310005",
    "expiryMonth": "02",
    "expiryYear": "29"
  },
  "customerName": "Alex Johnson",
  "customerCode": "01455",
  "source": "API"
}

Response

{
  "created": "2025-09-05T13:29:26.663Z",
  "id": 4100000000584209,
  "paymentToken": "PsF4knneprZFnoQJ9sCXTeoiFZh3bpf7",
  "merchantId": 1000016337,
  "tenderType": "Card",
  "amount": "108.06",
  "cardAccount": {
    "cardType": "American Express",
    "entryMode": "Keyed",
    "last4": "0005"
  },
  "authOnly": false,
  "authCode": "AX0649",
  "status": "Approved",
  "authMessage": "Approved or completed successfully",
  "reference": "524813001217",
  "type": "Sale",
  "responseCode": 0,
  "IssuerResponseCode": "000"
}

Scenario 2: Charge a saved card

(vaulted card token)

Use this for returning customers and repeat purchases. Reference a previously vaulted card by its token instead of raw card details. Vault cards with Card Vaulting.

You'll also need: a vaulted card token.

Request

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 59.99,
  "tenderType": "Card",
  "paymentType": "Sale",
  "cardAccount": {
    "token": "TR5KSPRZ5Z3BEJ7UEHBMSZKM12OHJ1D7"
  },
  "source": "API"
}

Response

{
  "created": "2026-01-06T10:27:40.95Z",
  "id": 4100000000870005,
  "paymentToken": "PU7VjKI1H7ORx9j1RS9y9ZvenWdzq5Nn",
  "merchantId": 1000157980,
  "tenderType": "Card",
  "amount": "137.78",
  "cardAccount": {
    "cardType": "Visa",
    "entryMode": "Keyed",
    "last4": "0117"
  },
  "status": "Approved",
  "type": "Sale",
  "responseCode": 0,
  "IssuerResponseCode": "00"
}

Scenario 3: Charge a card and save it for next time

(vault the card during the sale)

Use this when a customer checks out and agrees to save their card for future purchases. Set shouldVaultCard to true, and the response returns a reusable token you can charge later with Scenario 2.

You'll also need: the customer's consent to store their card.

Request

POST /checkout/v3/payment

{
  "merchantId": 1000157980,
  "amount": 11.11,
  "tenderType": "Card",
  "paymentType": "Sale",
  "shouldVaultCard": true,
  "cardAccount": {
    "number": "4000053720000117",
    "expiryMonth": "12",
    "expiryYear": "27"
  },
  "customerName": "Alex Johnson",
  "customerCode": "9872887790",
  "source": "QuickPay"
}

Response

{
  "created": "2026-05-14T07:22:12.36Z",
  "id": 4100000001181552,
  "paymentToken": "PF6WGNv3eAFdddOlDz6RScQ93vk9jvgl",
  "shouldVaultCard": true,
  "merchantId": 1000157980,
  "tenderType": "Card",
  "amount": "11.11",
  "cardAccount": {
    "cardType": "Visa",
    "entryMode": "Keyed",
    "last4": "0117",
    "cardId": "krUFoe65m8745tyX6lWBSezfPmcf"
  },
  "authOnly": false,
  "authCode": "PPS987",
  "status": "Approved",
  "authMessage": "Approved and completed successfully",
  "reference": "613407782241",
  "customerCode": "9872887790",
  "customerName": "Alex Johnson",
  "type": "Sale",
  "responseCode": 0,
  "IssuerResponseCode": "00"
}

Track the payment

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

PaymentSuccess: the payment was approved.
PaymentFail: the payment was declined.

The statuses, the flow to settlement, and the webhook events all live in Payment Lifecycle and Webhook Event Types.

Request reference

The complete set of fields for the create-payment request. Scenarios above use subsets of these.

Core parameters

Parameter	Required	Description
`merchantId`	✓	Your PCE merchant identifier that receives the payment.
`amount`	✓	Amount to charge, in the account currency (USD by default).
`paymentType`	✓	Set to `Sale` to authorize and capture in one call.
`tenderType`	✓	Set to `Card` for card payments.
`cardAccount`	Conditional	The card to charge. Required when `tenderType` is `Card`. Pass raw card details or a vaulted `token`. See Card account fields.
`replayId`	Recommended	Your unique retry key. Retrying with the same value returns the original response instead of charging again. See Idempotent Requests.
`customerName`	Optional	Cardholder's full name. Recommended for guest checkout where the card isn't vaulted.
`customerCode`	Optional	Your reference for the customer, included in settlement (Level 1 data).
`shouldVaultCard`	Optional	Set to `true` to save the card and return a reusable `token`.
`posData`	Recommended	Point-of-sale data describing how the transaction was captured. Recommended for all keyed and online payments to improve approval rates and can lower fees. See Transaction Context.
`source`	Optional	Origin of the payment. Possible values: `API`, `QuickPay`, `Recurring`, `Link2Pay`, `Terminal`.

Card account fields

Provide either number (raw card) or token (vaulted card), not both.

Parameter	Required	Description
`cardAccount.number`	Conditional	Card number. Either `number` or `token` must be present.
`cardAccount.token`	Conditional	Vaulted card token, used instead of raw card details.
`cardAccount.expiryMonth`	Conditional	Card expiration month (MM). Required with `number`.
`cardAccount.expiryYear`	Conditional	Card expiration year (YY). Required with `number`.
`cardAccount.cvv`	Conditional	3 or 4 digit card verification value. Required if Loss Prevention is enabled.
`cardAccount.name`	Optional	Cardholder's name.
`cardAccount.avsStreet`	Recommended	Billing street address for AVS. Required if Loss Prevention is enabled.
`cardAccount.avsZip`	Recommended	Billing ZIP for AVS. Required if Loss Prevention is enabled.

Level II/III data and other interchange fields are covered on Interchange Optimization.

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 no payment is created. Submission checks:

Required fields are present and correctly formatted.
The card details or token resolve to a chargeable card.
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

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

If a sale is declined

The response returns status: Declined with a responseCode and authMessage explaining why (for example, responseCode: 51, Insufficient funds/over credit limit).
Tell the customer, and where appropriate ask them to try another card. Match the code to guidance on Payment Response Codes and Handling Declines.
To cancel an approved sale before it settles, 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 sales, also confirm:

Your AVS and CVV requirements are verified against your merchant configuration.
Decline handling is implemented: read responseCode, surface the outcome, and apply retry rules.
You generate a unique replayId per sale for safe retries.

Best practices

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

Practice	Description
Include AVS data	Pass `avsStreet` and `avsZip` in `cardAccount`. This helps prevent fraud and can lower processing fees.
Submit Level II/III data	For business, corporate, or government cards, providing Level II/III data can significantly reduce interchange costs.
Include POS data	Send `posData` on keyed and online sales to improve approval rates and qualify for better rates.
Use webhooks	Subscribe to `PaymentSuccess` and `PaymentFail` to track outcomes without polling.
Vault for repeat buyers	Set `shouldVaultCard` to save the card, then charge the returned `token` on future purchases.

Next steps

Authorization and Capture

Authorize now and capture the funds later.

Refund

Return funds from a completed sale.

Sale

Make your first payment

Use `replayId` for safe retries

Scenarios

Scenario 1: Charge a card entered at checkout

Scenario 2: Charge a saved card

Scenario 3: Charge a card and save it for next time

Track the payment

Request reference

Core parameters

Card account fields

Validation

Statuses

Go live

Best practices

Next steps

See also

Make your first payment

Use replayId for safe retries

Scenarios

Scenario 1: Charge a card entered at checkout

Scenario 2: Charge a saved card

Scenario 3: Charge a card and save it for next time

Track the payment

Request reference

Core parameters

Card account fields

Validation

Statuses

Go live

Best practices

Next steps

See also

Use `replayId` for safe retries