A sale transaction is the process of charging a customer's payment method (typically a card) for goods or services. It combines authorization and capture into a single transaction. This means that the system immediately verifies the payment details, reserves the funds, and transfers them to your account— all in one seamless API call.

Common use cases include:

Use Sale when the product or service is delivered immediately after payment. Common scenarios include:

Instant Order Fulfilment: Digital goods, downloadable content, online courses, and streaming access.
Immediate Service Completion: On-demand services such as ride-sharing, one-time consultations, or freelance gigs.
Retail/E-Commerce Checkout: Where goods are shipped right after order confirmation.

How it Works

Processing a sale involves sending the customer's payment details to our API.

Make a POST request to /checkout/v3/payment endpoint with required parameters.

Parameter	Required	Description
`amount`	✓	Amount to charge (in USD currency)
`cardAccount`	✓	Valid Payment Card details or a vaulted token Note: You can vault the card for future use using Card Vaulting guide
`merchantId`	✓	The Merchant's unique identifier that is used to process the payment.
`tenderType`	✓	Set to `CARD` for card transactions.
`paymentType`		Type of transaction. It is defaulted to `Sale`
`customerName`		The name of the customer. Recommended for guest checkout where the card is not vaulted.
`posData`		An object containing Point of Sale data. While optional, we highly recommend including this object for all keyed (card-not-present/online) transactions to improve approval rates and potentially lower processing fees. You can view more details of the recommended POS data based on presentment type here.

Once the payment request is submitted, our system performs a series of system-level validations before sending the transaction to the card network. These validations check for:
1. Missing or invalid required fields
2. Incorrect parameter formats or values
3. Merchant configuration or permission issues.
If any validation fails, the request is rejected immediately, and an error response is returned. You must correct the issue and resubmit the request. For a complete list of validation errors and how to resolve them, refer to the System Error Codes guide.
If all system-level validations pass, our system processes the payment and returns a response indicating the outcome. You can learn the outcome of the request via GET /checkout/v3/payment/{id} or wait for the Payment webhook You can determine the result by checking the status and responseCode fields in the response.
1. status: The primary outcome of the transaction, either APPROVED or DECLINED.
2. responseCode: A detailed code explaining the reason for the status. See our comprehensive Response code guide guide for full list
For every approved payment, it is critical to store two identifiers
1. id : The unique Payment ID. Use this for retrieving or voiding the transaction before it settles.
2. paymentToken: The secure Transaction Token. Use this for follow-up actions like refunds or adjustments after the transaction has settled.

Best Practices

Feature	Description
Include AVS Data	Always pass Address Verification Service (AVS) data (avsZip, avsStreet) in the cardAccount object. This helps prevent fraud and can result in lower processing fees.
Submit L2/L3 Data	For business, corporate, or government cards, providing Level 2/L3 data (like tax amount and customer code) can significantly reduce your interchange costs.
Use Webhooks	Stay informed about the payment status asynchronously by subscribing to these webhooks: PaymentSuccess: the payment was approved. PaymentFail: the payment was declined.
Test your integration	Use our provided Test Card Data to safely test all payment scenarios, including declines and errors, in our sandbox environment.

Sale (Auto Capture)

Common use cases include:

How it Works

Best Practices

See Also