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.

Create a Sale

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.

Our system will 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.

Open items to be discussed

How will a merchant get a bearer to run API's?
Merchant creation will happen using MXC portal?
How will a merchant get the merchant id to create a payment?

Sale (Auto Capture)

Common use cases include:

Create a Sale

Best Practices

See Also

Open items to be discussed