Skip to main content

CVM Signature Check Integration

When utilising the CVM Signature integration, you will need to update axept® PRO of the outcome of a CVM Signature Check as and when one is required, you do so by using a POST/transactionUpdate request.

Best Practice

The POST/transactionUpdate request is used in conjunction with the posSignatureCheck query parameter being enabled within a transaction, i.e. when the integrated POS is responsible for handling CVM signature checks; this request is used to update axept® PRO on the signature check result and whether the conclude or reverse the transaction.

If you are omitting the posSignatureCheck query parameter from transaction requests, or including but setting to false then you should not use this feature.

Transaction Requirements​

In order to utilise the CVM Signature integration feature you will need to set the posSignatureCheck parameter in the initial transaction request so that axept® PRO will know it will receive signature decisions from the integrated POS system rather than displaying prompts on the device screen.

Below is the URL required to intiate a transaction with the CVM Signature Integration enabled:

URL

https://(TerminalIP):8080/POSitiveWebLink/(api)/rest/transaction?tid=(tid)&posSignatureCheck=true

Note: The posSignatureCheck parameter needs to be set to true to enable the feature.

Below are the parameter(s) that need to be enabled:

A HTTPS POST request should be sent in the same way as any other standard transaction, covered here, to the above URL. However make sure you have set the following parameters:

POST /transaction - Query String Parameters
Field NameStateData TypeDescription
posSignatureCheckOptionalBoolean

When set to true the responsibility of handling signature receipt printing and decision making will be shifted to the integrated POS; if a signature is required at any point to conclude a transaction axept® PRO will enter a standby state waiting for a POST request to either accept or reject the signature.

See the GET/transaction section for expected values and behaviour when this feature is enabled, you can also use the Receipt String Data to create a PCI compliant Merchant Receipt for signature printing.

Example​

Postman Request
POST https://192.168.10.44:8080/POSitiveWebLink/1.3.0/rest/transaction?tid=1640005298&posSignatureCheck=true
HTTP/1.1
Content-Type: application/json
Authorization: Bearer 6945595921271780
User-Agent: PostmanRuntime/7.51.1
Accept: */*
Postman-Token: a819cb28-dd3f-4907-b545-32fb0804b794
Host: 192.168.0.201:8080
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 295
{
    "transType": "SALE",
    "amountTrans": 1000,
    "reference": "Test"
}

POS Monitoring​

If the CVM Signature Check integration feature is being used then the integrated POS system needs to be monitoring the device for scenarios where a signature will be prompted, in such instances the GET/transaction response code will be 207 - Signature Check on POS.

Example​

"HTTP/1.1 207 Signature Check On POS
Content-Type":"application/json; charset=UTF-8
Date":"Thu",
"26 Feb 2026 15":"02":"32 GMT
Access-Control-Allow-Origin":"*
Access-Control-Allow-Methods":"POST",
"GET",
"OPTIONS",
"DELETE
Access-Control-Max-Age":"86400
Access-Control-Allow-Headers":"*
Allow":"POST",
"GET",
"OPTIONS",
"DELETE
Connection":"keep-alive
Content-Encoding":"gzip
{
/* [Transaction Data Array] */
}

This state means axept® PRO is waiting on a signature decision from the integrated POS, you should program the POS system to print a merchant signature reciept and provide an on screen prompt for the EPOS user.

POST/transactionUpdate​

In the event of a signature requirement and axept® PRO waiting on a decision from the integrated POS, the weblink integration can be used to send an update that will inform axept® PRO on what to do next.

Below are the URL's you need to utilise:

URL

https://(TerminalIP):8080/POSitiveWebLink/(api)/rest/transactionUpdate?tid=(tid)&uti=(uti)

The main request body needs only the following parameter:

An HTTPS POST request should be sent to the above URL with the following parameters:

POST /transaction - Query String Parameters
Field NameStateData TypeDescription
TerminalIPMandatoryString

This is the IP Address (on the local network) of the terminal that should process the transaction. This can be obtained from Weblink or the WIFI settings of the device.

apiMandatoryString

This is the Weblink API Version you wish to use for the upcoming transaction, it is advised to always use the latest version where possible.

tidMandatoryString

This is the Serial Number of the terminal that should process the transaction. This is printed on a label on the rear of the device.

utiMandatoryString

This is the UTI of the transaction currently in progress on the device, the one requiring a signature decision.

POST /transaction - Header Parameters
AuthorizationMandatoryStringThis field should be populated with a value of
Bearer 6945595921271780
POST /transaction - Body Parameters
sigApprovedMandatoryBooleanValue that represents the outcome of a signature check, this value is passed to axept® PRO to then conclude the transaction.
If set to true this will tell axept® PRO that the signature was accepted, a value of false tells axept® PRO that the signature was not accepted.

Example​

Postman Request
POST /POSitiveWebLink/1.3.0/rest/transactionUpdate?tid=1853195101&uti=02A3BB23-E176-409C-823F-6DB225FD711B HTTP/1.1
Content-Type: application/json
Authorization: Bearer 6945595921271780
User-Agent: PostmanRuntime/7.51.1
Accept: */*
Postman-Token: f3d13caa-7007-4cdb-ac2e-14fa9481fe56
Host: 192.168.0.201:8080
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 33
 
{
"sigApproved": true     // accept signature
}
Postman Request
POST /POSitiveWebLink/1.3.0/rest/transactionUpdate?tid=1853195101&uti=02A3BB23-E176-409C-823F-6DB225FD711B HTTP/1.1
Content-Type: application/json
Authorization: Bearer 6945595921271780
User-Agent: PostmanRuntime/7.51.1
Accept: */*
Postman-Token: f3d13caa-7007-4cdb-ac2e-14fa9481fe56
Host: 192.168.0.201:8080
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 33
 
{
"sigApproved": false    // refuse signature
}

POST Response Codes​

This should update the status of the transaction on axept® PRO and proceed to either finalisation (approval) or reversal (refused signature), the expected result is to recieve a 200 response code. Below is a table of all possible responsed:

HTTP Response CodeDescription
200Request successfully posted and signature response has been received by axept® PRO.
400
Signature verification already finalised		When a POST/transactionUpdate is sent against the uti of a transaction that has already had a signature response and/or has already concluded
404
Transaction result not available		Usually happens when a POST/transactionUpdate is sent against the uti of a transaction that has not had a card presented to it yet.

POST Example Responses​

Content-Type: application/json
Date: Tue, 24 Jun 2025 09:41:26 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 86400
Access-Control-Allow-Headers: *
Allow: POST, GET, OPTIONS, DELETE
Connection: keep-alive
Content-Encoding: gzip
Transfer-Encoding: chunked
{
  "amountCashback": 0,
  "amountGratuity": 0,
  "amountTrans": 20000,
  "transType": "SIGCOMPLETION",
  "uti": "4900FEE8-F589-4775-842A-60EF0131A101"
}