Local API

HTTP Integration

Introduction

The Market Pay Local API uses a mixed communication model based on the endpoint's requirements:

• Synchronous (SYNC) Mode: Used for simple, direct actions where the POS waits for an immediate result. This follows a standard single request/response cycle (e.g., POST /status returns RC 200 OK with the response body).
• Asynchronous (ASYNC) Mode: Used for complex transactions that require user interaction or processing time. This involves the HTTP Polling cycle detailed below.

1. Endpoints

• POST: Used in ASYNC/SYNC modes
• GET: Only used to fetch stored responses

2.1 Pay On Site Endpoint description list

2.2 Voucher Endpoint description list

2.3 Cheque Endpoint description list

3. Transaction Status Codes

3.1 Flow Reference

This table defines the meaning and required actions for every HTTP response code encountered during
a synchronous transaction or the asynchronous polling loop.

3.2 ASYNC Polling Intermediate Codes

These codes are exclusively returned to a GET polling request and require the POS application to continue the monitoring loop until a final status (RC 200/423) is reached.

In ASYNC, POS will receive Display Request sent by the POI via the polling cycle. Its primary function is to instruct the POS on what information to display or what operational status has been reached during a transaction.

3.3 Polling loop

The Polling Loop is the mechanism used for Asynchronous (ASYNC) transactions, where the Point of Sale (POS) actively monitors the Payment Terminal (POI) for a final result after initiating a request. This loop replaces a persistent connection and is critical for managing transaction state and communication stability.

• Initiation: The POS sends a POST request (e.g., /payment) and receives RC 202 Accepted, signaling the transaction is queued and the loop must begin.
• Continuation: The POS sends repeated GET requests (polling). The loop continues as long as the POI returns an intermediate status (RC 206 Partial Content, RC 201 Created, or RC 204 No Content).
• Termination (Success/Failure): The loop immediately stops (break) when the POI returns a final status code (RC 200 OK for the result or RC 423 Locked/RC 403 Forbidden for a fatal error).
• Exception: An unrecoverable internal error (like a parsing rejection) is delivered via an RC 200 OK response containing an EventNotification, which also requires the POS to immediately stop polling.

###

4. Pay On Site Flows

4.1. Login flow

3.2. Payment Flow

3.3. Abort

In this case payment response’s Field “Result”: “Error”, “Reason”: “Aborted”

3.4. Logout

3.5. Acquisition

INFO: Display request may be returned with code 206 Partial Content or 201 Continue

Continue - in case when there is currently no cached responses available on endpoint except this Display

Card Acquisition is a first part of “Dual” transaction, to Authorise transaction, further PaymentRequest should be sent (/payment Endpoint). Request shall contain CardAcquisitionReferenceId field pointing POITransactionId field from received previously CardAcqusitionResponse

3.6. Status

3.7. Diagnosis

3.8 Reversal

3.9 Update

3.10 Balance Inquiry

3.11 Gift Card

• No diagram available

Italy endpoint

1. Voucher Payment

• No diagram available

2. Voucher Reversal

• No diagram available

3. Alternative Payment

• No diagram available

4. Alternative Reversal

• No diagram available

Cheque endpoint

1. Cheque payment

• No diagram available

2. Cheque reversal

• No diagram available

##