Cheques

Cheques remain a common payment method in France, and our API supports their processing through a synchronous exchange that relies on local cheque reader data provided by the POS. 

Reach our customer support team if you are interested in cheque processing to enable this service extension.

1. Workflow

The Cheque Payment Flow is a synchronous exchange where the verification and final result are handled by the terminal.

  • Request: The POS sends a Payment Request request containing the cheque details (Cheque Number and RLMC key).

  • Processing: The POI (terminal) process cheque transaction by communicating with backend server to reach partners (Verifiance, etc.) while the POS waits.

  • Final Result: The POI returns Payment Response with the additional information related to Cheques.

  • POS Decision: based on additional information POS should take their final decision: 

    • Accept the cheque: POS register the transaction

    • Decline the cheque: POS triggers a Cheques Reversal

2. Cheques Request

A Cheques Request is processed as a standard payment request, to which we have to add extra "PaymentData" element in the Request Body

Header

The standard SaleToPOIRequest.MessageHeader object, with MessageClass set to Service and MessageCategory set to Payment.

Body

To successfully initiate a PaymentRequest for Cheques, the body must contain the standard data expected for a PaymentRequest. In addition, you have to fulfill dedicated object: PaymentData.PaymentInstrumentData 

Component Object Required Type Description
CheckData.CheckCardNumber No String

RLMC key, which can be read on Cheque
CheckData.TrackData.TrackValue Yes String

 Raw cheque number to convert into a magnetic stripe track data format (e.g., from 0015468800000000909000000000000 to D0015468D800000000909F000000000000B)
PaymentInstrumentType.IdentificationType Yes String

static data to set to "Check"

Example

ChequePayment request example

Start a Cheque payment on terminal, requires providing a Track and RLMC data to perform transaction

{
  "MessageHeader": {
    "MessageCategory": "Payment",
    "MessageClass": "Service",
    "MessageType": "Request",
    "POIID": "POI_01",
    "ProtocolVersion": "3.1",
    "SaleID": "POS_01",
    "ServiceID": "102"
  },
  "PaymentRequest": {
    "PaymentData": {
      "PaymentInstrumentData": [
        {
          "CheckData": [
            {
              "TrackData": [
                {
                  "TrackValue": "D0015468D800000000909F000000000000B"
                }
              ]
            }
          ],
          "PaymentInstrumentType": "Check"
        }
      ]
    },
    "PaymentTransaction": {
      "AmountsReq": {
        "Currency": "EUR",
        "RequestedAmount": 10.00
      }
    },
    "SaleData": {
      "OperatorID": "Cashier_01",
      "SaleReferenceID": "8",
      "SaleTransactionID": {
        "TimeStamp": "2024-08-09T07:38:40Z",
        "TransactionID": "123"
      }
    }
  }
}

Review the full schema on the API specification page for required fields.

How to transform Track 2 Data 

Component Raw Value Transformed Value Purpose
Start Sentinel (Absent) D The character 'D' (or sometimes ';') marks the beginning of the Track 2 data.
Primary Account Data 0015468800000000909 0015468800000000909 This sequence is typically the PAN (Primary Account Number) or Check Card Number.
Field Separator (Delimiter) (Absent) D The character 'D' separates the card number from the expiration date and service code block.
Expiration/Service Code (Partial) 80000000 These digits usually encode the Expiry Date and the Service Code (which defines allowed usage).
Padding/End of Data 0000000000000 F000000000000 The 'F' or '0's are used as padding or as the End Sentinel to fill the remaining length of the track.
End Sentinel (Absent) B The character 'B' (or sometimes '?') marks the end of the data string on the track.

3. Cheques Response

The MessageHeader you receive in the response echoes the values you provided in the request. The only exception is the MessageType, which is Response.

Body

As part of the response, we receive standard information related to a payment and additional data related to cheque payment method used.  Refer to the Standard POS integration flow to manage it. 

For cheques, we receive response from server in field MarketpayPaymentExtensions.issuerOption. Raw data shared and is Base64 encoded.

ChequePayment Response example
{
  "MessageHeader": {
    "MessageCategory": "Payment",
    "MessageClass": "Service",
    "MessageType": "Response",
    "POIID": "PayOnSite",
    "ProtocolVersion": "3.1",
    "SaleID": "POS_01",
    "ServiceID": "20"
  },
  "PaymentResponse": {
    "PaymentResult": {
      "AmountsResp": {
        "AuthorizedAmount": "10.00",
        "Currency": "EUR"
      },
      "PaymentAcquirerData": {
        "AcquirerPOIID": "cheque",
        "MerchantID": "Test Cheque"
      },
      "PaymentInstrumentData": {
        "CheckData": [
          {
            "TrackData": [
              {
                "TrackValue": "D0015455D800000000909F************B"
              }
            ]
          }
        ],
        "PaymentInstrumentType": "Check"
      }
    },
    "POIData": {
      "POITransactionID": {
        "TimeStamp": "2025-10-14T11:39:10.000",
        "TransactionID": "0"
      }
    },
    "Response": {
      "AdditionalResponse": "Refused operation by server Currency not managed",
      "Result": "Failure"
    },
    "SaleData": {
      "SaleTransactionID": {
        "TimeStamp": "2025-10-14T11:39:10.000",
        "TransactionID": "0"
      }
    }
  }
}

Review the full schema on the API specification page for required fields.

issuerOption decoding

Example of a Base64 encoded response

issuerOption example

Base64 encoded: IyMjIyA0LiBOZXB0aW5nIFN1Y2Nlc3MgUGF5bWVudCBSZXNwb25zZToKCmBgYApTSUdOQVRVUkVfUkVRVUlSRUQgPSAwCkNVUlJFTkNZX0ZSQUNUSU9OID0gMgpFWFRFTkRFRF9SRVNVTFRfVEVYVCA9ICIiCk1BU0tFRF9BQ0NPVU5UX0lERU5USUZJRVIgPSAiRDAwMTU0NTVEODAwMDAwMDAwOTA5RioqKioqKioqKioqKkIiCkxPQ0FMX1RJTUVTVEFNUCA9IDIwMjUtMTAtMTRUMTE6Mzk6MTAuMDAwCk1FU1NBR0VfSUQgPSAiMCIKTUVTU0FHRV9UWVBFID0gIkRlYml0IgpNRVNTQUdFX05BTUUgPSAiUG9zUmVzcG9uc2UiCkVYVEVOREVEX1JFU1VMVCA9ICIiCk1FUkNIQU5UX1RSU19JRCA9ICIxIgpBUFBMSUNBVElPTl9OQU1FID0gImNoZXF1ZSIKT0ZGTElORV9UUlNfQ09VTlQgPSAiMCIKR0xPQkFMX1NUQVRVUyA9ICIxIgpTVEFOID0gMQpDVVJSRU5DWV9DT0RFID0gOTc4ClRFU1RfSU5ESUNBVE9SID0gMApPRkZMSU5FX1RSU19CTE9DS0VEID0gMApDVVJSRU5DWV9BTFBIQSA9IEVVUgpNRVJDSEFOVF9MQUJFTCA9IFRlc3QgQ2hlcXVlCkVOVFJZX01PREUgPSAiMTYiClNDSEVNRSA9IENIRVFVRQpQT1NfRklOQUxfQU1PVU5UID0gMTAwMApDSFFfQ1BUMSA9ICIwMSIKQ0hRX0NQVDIgPSAiMDMiCkNIUV9DUFQzID0gIjA1IgpDSFFfQkFOSz0gImJhbmtOYW1lIgpDSFFfQ09MT1IgPSAiQkxBTkMi

Decoded:

#### 4. Nepting Success Payment Response:

```
SIGNATURE_REQUIRED = 0
CURRENCY_FRACTION = 2
EXTENDED_RESULT_TEXT = ""
MASKED_ACCOUNT_IDENTIFIER = "D0015455D800000000909F************B"
LOCAL_TIMESTAMP = 2025-10-14T11:39:10.000
MESSAGE_ID = "0"
MESSAGE_TYPE = "Debit"
MESSAGE_NAME = "PosResponse"
EXTENDED_RESULT = ""
MERCHANT_TRS_ID = "1"
APPLICATION_NAME = "cheque"
OFFLINE_TRS_COUNT = "0"
GLOBAL_STATUS = "1"
STAN = 1
CURRENCY_CODE = 978
TEST_INDICATOR = 0
OFFLINE_TRS_BLOCKED = 0
CURRENCY_ALPHA = EUR
MERCHANT_LABEL = Test Cheque
ENTRY_MODE = "16"
SCHEME = CHEQUE
POS_FINAL_AMOUNT = 1000
CHQ_CPT1 = "01"
CHQ_CPT2 = "03"
CHQ_CPT3 = "05"
CHQ_BANK= "bankName"
CHQ_COLOR = "BLANC"

In the response, you will find key information to accept or decline the cheque at POS.

Component Purpose
CHQ_CPT1 Cheque Counter 1
CHQ_CPT2 Cheque Counter 2
CHQ_CPT3 Cheque Counter 3
CHQ_BANK Bank Name of the cheque returned by server
CHQ_COLOC Color code
CHQ_CPT2 This sequence is typically the PAN (Primary Account Number) or Check Card Number.

How to interpret received response 

Desktop-png.png

Source: Verifiance

4. Reversal

A Cheques Reversal is processed as a standard payment reversal, to which we have to add extra "PaymentData" element in the Request Body

Header

The standard SaleToPOIRequest.MessageHeader object, with MessageClass set to Service and MessageCategory set to Reversal.

Body

To successfully initiate a PaymentRequest for Cheques, the body must contain the standard data expected for a PaymentRequest. In addition, you have to fulfill dedicated object: PaymentData.PaymentInstrumentData 

Cheque Reversal Request example JSON
{
  "MessageHeader": {
    "MessageCategory": "Reversal",
    "MessageClass": "Service",
    "MessageType": "Request",
    "POIID": "POI_01",
    "ProtocolVersion": "3.1",
    "SaleID": "POS_01",
    "ServiceID": "823"
  },
  "ReversalRequest": {
    "Currency": "EUR",
    "MarketpayPaymentExtensions": {
      "CheckData": {
        "CheckCardNumber": [
          "09"
        ],
        "TrackData": [
          {
            "TrackValue": "D0015468D800000000909F000000000000B"
          }
        ]
      },
      "PaymentInstrumentType": "Check"
    },
    "OriginalPOITransaction": {
      "POITransactionID": {
        "TimeStamp": "2025-11-28T14:12:59.6+01:00",
        "TransactionID": "9991"
      }
    },
    "ReversalReason": "MerchantCancel",
    "ReversedAmount": "11.99",
    "SaleData": {
      "OperatorID": "Cashier_01",
      "SaleTransactionID": {
        "TimeStamp": "2025-11-28T14:12:59.6+01:00",
        "TransactionID": "9991"
      }
    }
  }
}

Review the full schema on the API specification page for required fields.