In-Person Payments
Process card-present payments through physical terminals using the Terminal API — covering authentication, terminal discovery, transaction initiation, status polling, and final record retrieval.
A terminal transaction is a card-present payment processed through a physical payment terminal — accepting credit and debit cards via chip, swipe, and contactless tap. A single end-to-end workflow covers authentication, terminal discovery, transaction initiation, status polling, and final record retrieval.
The Terminal API requires a JWT bearer token for authentication, obtained using your Consumer Key and Consumer Secret credentials before accessing any terminal endpoint.
Common use cases include:
- Retail Point of Sale: Process in-person card payments at the counter — chip, swipe, or tap — for immediate purchase fulfillment.
- Restaurants and Hospitality: Accept card-present payments at the table or counter, with support for sale and authorization transaction types.
- Field Service Payments: Collect card payments on-site during service delivery without requiring a fixed checkout station.
- Healthcare: Process co-payments and service fees at the point of care using a registered terminal.
Before You Begin
Credentials
Before calling any terminal endpoint, obtain the following credentials from the PCE Account Management team:
| Credential | Description |
|---|---|
| Consumer Key | Your unique identifier used to authenticate terminal API requests. |
| Consumer Secret | Your private secret used alongside the Consumer Key to obtain a JWT bearer token. |
Authentication is required before calling any terminal endpoint. All requests must include a valid JWT bearer token in the
Authorizationheader.
Environments
| Environment | API Base URL | Portal |
|---|---|---|
| Sandbox | https://sandbox-api2.mxmerchant.com/terminal/v1/ | https://sandbox.mxmerchant.com/ |
| Production | https://api2.mxmerchant.com/terminal/v1/ | https://mxmerchant.com/ |
How it Works
A terminal transaction follows a sequential five-step workflow. Each step must be completed in order before proceeding to the next.
- Authenticate — Obtain a JWT bearer token using your Consumer Key and Consumer Secret.
- Retrieve Terminals — Fetch the list of terminals registered to your merchant account and select an active terminal by ID.
- Create a Transaction — Initiate a transaction on the selected terminal and store the
devicePaymentAuditIdfrom the response. - Poll for Status — Poll the transaction status endpoint every 2 seconds until a final state is reached.
- Retrieve the Payment Record — Fetch the complete payment record from the Checkout API using the
replayId.
Step 0: Authenticate
Before calling any terminal endpoint, obtain a JWT bearer token using your Consumer Key and Consumer Secret credentials.
- Make a
POSTrequest to the authentication endpoint with your credentials.
| Parameter | Required | Description |
|---|---|---|
consumerKey | ✓ | Your unique Consumer Key provided during onboarding. |
consumerSecret | ✓ | Your Consumer Secret provided during onboarding. |
- Store the returned JWT bearer token and include it as a
Bearertoken in theAuthorizationheader of every subsequent terminal API request.
JWT tokens expire after a set period. Implement token refresh logic in your integration to avoid authentication failures during long-running sessions.
Step 1: Retrieve Available Terminals
Retrieve the list of terminals registered to your merchant account and identify an active terminal for transaction initiation.
- Make a
GETrequest to the Terminal List endpoint.
| Parameter | Required | Description |
|---|---|---|
merchantId | ✓ | Your unique merchant identifier assigned during onboarding. |
- From the response, identify a terminal to use for the transaction. Check the following fields:
| Field | Description |
|---|---|
terminalId | Unique identifier for the terminal. Required for transaction creation in Step 2. |
enabled | Must be true for the terminal to be available for transactions. |
Only terminals with
enabled: truein the response payload are available for transactions. Store theterminalIdof your selected terminal — it is required in Step 2.
Step 2: Create a Terminal Transaction
Initiate a transaction on the selected terminal using the terminalId retrieved in Step 1.
- Make a
POSTrequest to/terminal/v1/transaction/merchantid/{merchantId}/terminalid/{terminalId}.
| Parameter | Required | Description |
|---|---|---|
merchantId | ✓ | Your unique merchant identifier. |
terminalId | ✓ | The ID of the terminal selected in Step 1. Must have enabled: true. |
replayId | ✓ | Client-generated UUID for idempotency. Used to retrieve the final payment record in Step 4. Store this value — it cannot be recovered if lost. |
amount | ✓ | Transaction amount in USD. |
transactionType | ✓ | Type of transaction. Accepted values: Sale, Refund, Authorization. |
Supported Transaction Types
| Type | Description |
|---|---|
Sale | Immediately authorizes and captures the transaction amount. |
Refund | Returns funds to the cardholder. Requires a Manager Approval code by default unless the filebuild is adjusted. |
Authorization | Reserves funds without capturing. Requires a Manager Approval code by default unless the filebuild is adjusted. |
- The initial response returns a status of
SENTTOTERMINAL, confirming the transaction request has been dispatched to the terminal. - Store the
devicePaymentAuditIdreturned in the response — this value is thetransactionIdused during polling in Step 3.
SENTTOTERMINALis not a final state. Do not treat it as a completed transaction. Proceed to Step 3 to monitor the transaction outcome.
Step 3: Poll for Transaction Status
Monitor the transaction by polling the status endpoint until a final state is reached.
- Begin polling approximately 2 seconds after transaction creation. Make a
GETrequest to/terminal/v1/transaction/merchantid/{merchantId}/transactionid/{transactionId}.
| Parameter | Required | Description |
|---|---|---|
merchantId | ✓ | Your unique merchant identifier. |
transactionId | ✓ | The devicePaymentAuditId returned in Step 2. |
- Poll every 2 seconds for up to 2 minutes, or until a final state is returned in the
statusfield.
Successful Final States — Proceed to Step 4
| Status | Description |
|---|---|
approved | Transaction completed successfully. |
declined | Transaction was declined by the issuer. |
error | A processing error occurred. |
Failed States — Do Not Proceed
| Status | Description |
|---|---|
canceled / cancelled | Transaction was canceled. Check the message field for details. |
failed | Transaction failed. Check the message field for failure details. |
Any status not listed above should be treated as in-progress — continue polling. Note: Cancel operations are not currently implemented for Dejavoo terminals.
Step 4: Retrieve Final Transaction Details
Once a final state is reached in Step 3, retrieve the complete payment record from the Checkout API. Payment details are not included in terminal API responses.
- Make a
GETrequest to/checkout/v3/payment.
| Parameter | Required | Description |
|---|---|---|
merchantId | ✓ | Your unique merchant identifier. |
replayId | ✓ | The UUID submitted during transaction creation in Step 2. Must match the original value exactly. |
- The response returns the complete payment object. Treat this as the authoritative transaction record.
| Field | Description |
|---|---|
approvalStatus | Final approval status of the transaction. |
paymentType | The payment method used (e.g., credit, debit). |
amount | Final transaction amount. |
cardInformation | Tokenized card details. Raw card data is never returned. |
authorizationDetails | Authorization code and network response details. |
timestamps | Transaction creation and completion timestamps. |
Best Practices
| Practice | Description |
|---|---|
Generate a unique replayId per transaction | Always use a new client-generated UUID for each transaction. The replayId is your link between the terminal transaction and the final payment record — reusing values will cause incorrect record retrieval. |
Store devicePaymentAuditId immediately | Persist the devicePaymentAuditId from the Step 2 response immediately. It is required for polling in Step 3 and cannot be recovered if lost. |
| Implement token refresh logic | JWT tokens expire after a set period. Build token refresh logic into your integration to prevent authentication failures during active terminal sessions. |
| Validate terminal status before transacting | Always check enabled: true before selecting a terminal in Step 1. Initiating a transaction on a disabled terminal will result in a failed request. |
| Cap polling at 2 minutes | Implement a polling timeout of 2 minutes. If no final state is reached within this window, surface an error to the user and investigate via the terminal portal. |
| Use the Checkout API for payment records | The terminal API does not return complete payment details. Always retrieve the authoritative payment record from GET /checkout/v3/payment after a final state is reached. |
| Test in sandbox first | Use the sandbox environment to validate the full workflow — authentication, terminal selection, transaction initiation, polling, and record retrieval — before going live. |
See Also
- Sale (Automatic Capture)
- Authorize Now, Capture Later
- Payment Lifecycle
- Payment Response Codes
- API Error Handling
- Idempotent Requests
- Card Test Data
Updated about 9 hours ago