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:

CredentialDescription
Consumer KeyYour unique identifier used to authenticate terminal API requests.
Consumer SecretYour 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 Authorization header.

Environments

EnvironmentAPI Base URLPortal
Sandboxhttps://sandbox-api2.mxmerchant.com/terminal/v1/https://sandbox.mxmerchant.com/
Productionhttps://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.

  1. Authenticate — Obtain a JWT bearer token using your Consumer Key and Consumer Secret.
  2. Retrieve Terminals — Fetch the list of terminals registered to your merchant account and select an active terminal by ID.
  3. Create a Transaction — Initiate a transaction on the selected terminal and store the devicePaymentAuditId from the response.
  4. Poll for Status — Poll the transaction status endpoint every 2 seconds until a final state is reached.
  5. 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.

  1. Make a POST request to the authentication endpoint with your credentials.
ParameterRequiredDescription
consumerKeyYour unique Consumer Key provided during onboarding.
consumerSecretYour Consumer Secret provided during onboarding.
  1. Store the returned JWT bearer token and include it as a Bearer token in the Authorization header 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.

  1. Make a GET request to the Terminal List endpoint.
ParameterRequiredDescription
merchantIdYour unique merchant identifier assigned during onboarding.
  1. From the response, identify a terminal to use for the transaction. Check the following fields:
FieldDescription
terminalIdUnique identifier for the terminal. Required for transaction creation in Step 2.
enabledMust be true for the terminal to be available for transactions.

Only terminals with enabled: true in the response payload are available for transactions. Store the terminalId of 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.

  1. Make a POST request to /terminal/v1/transaction/merchantid/{merchantId}/terminalid/{terminalId}.
ParameterRequiredDescription
merchantIdYour unique merchant identifier.
terminalIdThe ID of the terminal selected in Step 1. Must have enabled: true.
replayIdClient-generated UUID for idempotency. Used to retrieve the final payment record in Step 4. Store this value — it cannot be recovered if lost.
amountTransaction amount in USD.
transactionTypeType of transaction. Accepted values: Sale, Refund, Authorization.

Supported Transaction Types

TypeDescription
SaleImmediately authorizes and captures the transaction amount.
RefundReturns funds to the cardholder. Requires a Manager Approval code by default unless the filebuild is adjusted.
AuthorizationReserves funds without capturing. Requires a Manager Approval code by default unless the filebuild is adjusted.
  1. The initial response returns a status of SENTTOTERMINAL, confirming the transaction request has been dispatched to the terminal.
  2. Store the devicePaymentAuditId returned in the response — this value is the transactionId used during polling in Step 3.

SENTTOTERMINAL is 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.

  1. Begin polling approximately 2 seconds after transaction creation. Make a GET request to /terminal/v1/transaction/merchantid/{merchantId}/transactionid/{transactionId}.
ParameterRequiredDescription
merchantIdYour unique merchant identifier.
transactionIdThe devicePaymentAuditId returned in Step 2.
  1. Poll every 2 seconds for up to 2 minutes, or until a final state is returned in the status field.

Successful Final States — Proceed to Step 4

StatusDescription
approvedTransaction completed successfully.
declinedTransaction was declined by the issuer.
errorA processing error occurred.

Failed States — Do Not Proceed

StatusDescription
canceled / cancelledTransaction was canceled. Check the message field for details.
failedTransaction 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.

  1. Make a GET request to /checkout/v3/payment.
ParameterRequiredDescription
merchantIdYour unique merchant identifier.
replayIdThe UUID submitted during transaction creation in Step 2. Must match the original value exactly.
  1. The response returns the complete payment object. Treat this as the authoritative transaction record.
FieldDescription
approvalStatusFinal approval status of the transaction.
paymentTypeThe payment method used (e.g., credit, debit).
amountFinal transaction amount.
cardInformationTokenized card details. Raw card data is never returned.
authorizationDetailsAuthorization code and network response details.
timestampsTransaction creation and completion timestamps.

Best Practices

PracticeDescription
Generate a unique replayId per transactionAlways 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 immediatelyPersist 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 logicJWT 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 transactingAlways 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 minutesImplement 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 recordsThe 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 firstUse the sandbox environment to validate the full workflow — authentication, terminal selection, transaction initiation, polling, and record retrieval — before going live.

See Also



.readme-logo { display: none !important; }