Introduction to Terminal API
Overview
The Terminal API is designed to revolutionize how businesses engage with payment solutions, offering a robust cloud REST interface that seamlessly initiates transactions on SmartPOS Terminals remotely. Our aim is to provide businesses with a versatile platform that effortlessly integrates into their existing systems, enhancing their payment capabilities and optimizing customer satisfaction.
Vision and Mission
Our vision and mission are intertwined with a singular goal: delivering an API that simplifies the integration process. We are committed to empowering businesses to quickly and efficiently implement advanced payment solutions with minimal friction. This commitment includes offering comprehensive documentation, exceptional support, and ongoing improvements, ensuring a seamless integration experience. As a result, our clients can focus on their core business operations and elevate customer satisfaction through enhanced payment capabilities.
Target Audience
The primary users of the Terminal API are ECR (Electronic Cash Register) integrators. These integrators can leverage our API to connect various point-of-sale systems seamlessly, enabling innovative and efficient payment handling capabilities.
Use Cases
The Terminal API is invaluable for initiating remote transactions on local SmartPOS Devices. This capability offers substantial flexibility for businesses, allowing for adaptive solutions such as mobile point-of-sale systems, unattended kiosks, and other advanced transaction setups that necessitate remote operation and control.
Overview
The Terminal API is designed to revolutionize how businesses engage with payment solutions, offering a robust cloud REST interface that seamlessly initiates transactions on SmartPOS Terminals remotely. Our aim is to provide businesses with a versatile platform that effortlessly integrates into their existing systems, enhancing their payment capabilities and optimizing customer satisfaction.
Vision and Mission
Our vision and mission are intertwined with a singular goal: delivering an API that simplifies the integration process. We are committed to empowering businesses to quickly and efficiently implement advanced payment solutions with minimal friction. This commitment includes offering comprehensive documentation, exceptional support, and ongoing improvements, ensuring a seamless integration experience. As a result, our clients can focus on their core business operations and elevate customer satisfaction through enhanced payment capabilities.
Target Audience
The primary users of the Terminal API are ECR (Electronic Cash Register) integrators. These integrators can leverage our API to connect various point-of-sale systems seamlessly, enabling innovative and efficient payment handling capabilities.
Use Cases
The Terminal API is invaluable for initiating remote transactions on local SmartPOS Devices. This capability offers substantial flexibility for businesses, allowing for adaptive solutions such as mobile point-of-sale systems, unattended kiosks, and other advanced transaction setups that necessitate remote operation and control.
API Fundamentals
API Architecture
The Terminal API is built as a RESTful service designed to provide seamless interactions for initiating transactions on SmartPOS Terminals. This architecture ensures compatibility with a wide range of systems and programming languages, enabling straightforward integration and high flexibility.
Authentication and Authorization
The Terminal API employs an API key-based authentication mechanism to secure and manage access. Each API key is unique and must be requested for every Merchant intending to use the API. This key acts as a secure identifier that allows merchants to execute transactions through our services, ensuring that only authorized users can access and utilize the API.
To obtain an API key:
- Request access to receive the dedicated API keys (one for integration and one for production environment).
- Follow the instructions to confirm the merchant's identity and obtain the key.
- Securely store and manage the API key, as it is crucial for accessing both the integration and production environments.
Environments
To facilitate development and deployment, the Terminal API provides two distinct environments:
- Integration Environment: This environment is intended for testing and development purposes. It allows developers to verify transaction processes without affecting real-world operations. In order to conduct meaningful tests, a development terminal is mandatory, as it enables the execution and validation of transaction flows accurately. The integration environment is accessible at:
- Production Environment: Once development and testing are complete, applications can be moved to the production environment for live operations. This environment is optimized for reliability and performance, ensuring smooth and secure transaction handling in a real-world setting. Access the production environment at:
Both environments are configured to ensure that transactions conducted in the integration stage do not affect actual business data, while the production stage is fine-tuned for handling transactional loads efficiently and securely.
API Architecture
The Terminal API is built as a RESTful service designed to provide seamless interactions for initiating transactions on SmartPOS Terminals. This architecture ensures compatibility with a wide range of systems and programming languages, enabling straightforward integration and high flexibility.
Authentication and Authorization
The Terminal API employs an API key-based authentication mechanism to secure and manage access. Each API key is unique and must be requested for every Merchant intending to use the API. This key acts as a secure identifier that allows merchants to execute transactions through our services, ensuring that only authorized users can access and utilize the API.
To obtain an API key:
- Request access to receive the dedicated API keys (one for integration and one for production environment).
- Follow the instructions to confirm the merchant's identity and obtain the key.
- Securely store and manage the API key, as it is crucial for accessing both the integration and production environments.
Environments
To facilitate development and deployment, the Terminal API provides two distinct environments:
- Integration Environment: This environment is intended for testing and development purposes. It allows developers to verify transaction processes without affecting real-world operations. In order to conduct meaningful tests, a development terminal is mandatory, as it enables the execution and validation of transaction flows accurately. The integration environment is accessible at:
- Production Environment: Once development and testing are complete, applications can be moved to the production environment for live operations. This environment is optimized for reliability and performance, ensuring smooth and secure transaction handling in a real-world setting. Access the production environment at:
Both environments are configured to ensure that transactions conducted in the integration stage do not affect actual business data, while the production stage is fine-tuned for handling transactional loads efficiently and securely.
Getting Started
Before diving into the implementation, it's crucial to have a comprehensive understanding of the API's functionality and transaction capabilities. To ensure a seamless integration experience with the Terminal API, please thoroughly review Chapter 4 and Chapter 5. These chapters provide critical insights into the REST implementation specifics and detail the supported transaction types.
Key Steps to Get Started
- Understand the API Documentation:
- Make sure to carefully read through Chapter 4, which presents detailed endpoint descriptions and REST implementation guidelines.
- Familiarize yourself with Chapter 5 to understand the different transaction types supported by the Terminal API and their corresponding payload structures.
- Request API Keys:
- API keys are essential for accessing the Terminal API. These keys are currently distributed via email. To request an API key:
- Contact our support team or designated email address provided in the Developer Portal.
- Complete any verification steps required to confirm your merchant identity.
- Upon approval, you will receive your API key via email. It is imperative to store this email securely or delete it after safely transferring the API key to your secure storage system. This precaution ensures that unauthorized parties cannot obtain or steal the API key.
- Set Up Your Development Environment:
- Use a development terminal to ensure accurate and reliable testing during your integration process.
- Validate your setup by performing transactions in the integration environment to simulate real-world scenarios without impacting actual business data.
By following these steps, you'll be ready to proceed with the integration of the Terminal API into your existing systems. This groundwork will enable a smooth transition from testing to live operations, ensuring that your payment solutions are robust and efficient.
Before diving into the implementation, it's crucial to have a comprehensive understanding of the API's functionality and transaction capabilities. To ensure a seamless integration experience with the Terminal API, please thoroughly review Chapter 4 and Chapter 5. These chapters provide critical insights into the REST implementation specifics and detail the supported transaction types.
Key Steps to Get Started
- Understand the API Documentation:
- Make sure to carefully read through Chapter 4, which presents detailed endpoint descriptions and REST implementation guidelines.
- Familiarize yourself with Chapter 5 to understand the different transaction types supported by the Terminal API and their corresponding payload structures.
- Request API Keys:
- API keys are essential for accessing the Terminal API. These keys are currently distributed via email. To request an API key:
- Contact our support team or designated email address provided in the Developer Portal.
- Complete any verification steps required to confirm your merchant identity.
- Upon approval, you will receive your API key via email. It is imperative to store this email securely or delete it after safely transferring the API key to your secure storage system. This precaution ensures that unauthorized parties cannot obtain or steal the API key.
- API keys are essential for accessing the Terminal API. These keys are currently distributed via email. To request an API key:
- Set Up Your Development Environment:
- Use a development terminal to ensure accurate and reliable testing during your integration process.
- Validate your setup by performing transactions in the integration environment to simulate real-world scenarios without impacting actual business data.
By following these steps, you'll be ready to proceed with the integration of the Terminal API into your existing systems. This groundwork will enable a smooth transition from testing to live operations, ensuring that your payment solutions are robust and efficient.
Endpoints Overview
The Terminal API defines several endpoints intended to manage merchant information and terminal transactions. Below is the list of endpoints with their corresponding operations:
- Merchant Management Endpoint:
- GET /api/v1/merchants/{umid}/
- Description: Retrieve merchant information and connected terminals
- Parameters:
- umid (string, path): Unique Merchant Identifier required to specify which merchant's information is to be retrieved.
- Terminal Transaction Endpoint:
- POST /api/v1/merchants/{umid}/terminals/{utid}/tapi/
- Description: Start a transaction on a specified terminal.
- Body: payload defined in Chapter 5
- Parameters:
- umid (string, path): Unique Merchant Identifier for the merchant initiating the transaction.
- utid (string, path): Unique Terminal Identifier specifying which terminal to initiate the transaction on.
The Terminal API defines several endpoints intended to manage merchant information and terminal transactions. Below is the list of endpoints with their corresponding operations:
- Merchant Management Endpoint:
- GET /api/v1/merchants/{umid}/
- Description: Retrieve merchant information and connected terminals
- Parameters:
- umid (string, path): Unique Merchant Identifier required to specify which merchant's information is to be retrieved.
- GET /api/v1/merchants/{umid}/
- Terminal Transaction Endpoint:
- POST /api/v1/merchants/{umid}/terminals/{utid}/tapi/
- Description: Start a transaction on a specified terminal.
- Body: payload defined in Chapter 5
- Parameters:
- umid (string, path): Unique Merchant Identifier for the merchant initiating the transaction.
- utid (string, path): Unique Terminal Identifier specifying which terminal to initiate the transaction on.
- POST /api/v1/merchants/{umid}/terminals/{utid}/tapi/
Message Types
This chapter elaborates on the message types supported by the Terminal API, including their corresponding JSON payload structures. Each message type has its own unique set of fields required to conduct a successful transaction, although certain standard fields are common across all message exchanges. Understanding these fields is crucial for correctly integrating and utilizing the API.
Standard Fields
Before diving into specific message types, it's important to recognize the standard structure and fields that are consistent across all message exchanges with the following hierarchical structure:
- Message type for request
- A. Header: Contains metadata about the request.
- B. Request information i.e. ServiceRequest: Contains information about the requested service.
- Environment: Provides information about the Point of Interaction (POI) or terminal where the transaction is occurring.
- Request data container(s): Container for specific set of request data. Service type object can contain a single and/or multiple request data containers.
- Message type for response
- A. Header: Contains metadata about the response.
- B. Response information i.e. ServiceResponse: Contains information about service response.
- Environment: Provides information about the Point of Interaction (POI) or terminal where the transaction is occurring.
- Response data container(s): Container for specific set of response data. Service type object can contain a single and/or multiple response data containers.
- Response: Result of the processing of the request.
Each specific service type, such as Purchase or Reversal, will include its unique fields within this structure. To be checked in the specific chapter.
Field name
Type
Constraints
Mandatory
Description
MessageFunction
String
Fixed values. Check MessageFunction chapter
yes
Identifies the function being performed.
ProtocolVersion
String
{1..6} char
yes
Protocol version, commonly “5.0”
ExchangeIdentification
String
{1..35} char
yes
Unique identifier for the transaction message exchange.
CreationDateTime
DateTime
YYYY-MMDDthh:mm:ss.sss
yes
Timestamp of message creation.
InitiatingParty
Object
yes
Contains details about the party initiating the request.
MessageFunction values
Code Name
Name
Description
SFSQ
SaleFinancialServiceRequest
Request a financial service like payment, reversal, loyalty, Balance Inquiry, etc.
SFSP
SaleFinancialServiceResponse
Response to a financial service request.
SSMQ
MessageStatusRequest
Request the status of a previous message for which the Sale system has no response.
SSMR
MessageStatusResponse
Response to a Message Status request.
SSRJ
Rejection
Reject a previous received message, for technical or functional reasons.
InitiatingParty Sub-Object
Field name
Type
Constraints
Mandatory
Description
Identification
String
{1..35} char
yes
Identifier of the initiating party.
Type
String
Fixed values. Check Type chapter
Initiating party type such as merchant etc.
Type values
Code Name
Name
Description
MERC
Merchant
Merchant providing goods and service in the card payment transaction.
This chapter elaborates on the message types supported by the Terminal API, including their corresponding JSON payload structures. Each message type has its own unique set of fields required to conduct a successful transaction, although certain standard fields are common across all message exchanges. Understanding these fields is crucial for correctly integrating and utilizing the API.
Standard FieldsBefore diving into specific message types, it's important to recognize the standard structure and fields that are consistent across all message exchanges with the following hierarchical structure:
Each specific service type, such as Purchase or Reversal, will include its unique fields within this structure. To be checked in the specific chapter. |
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
MessageFunction |
String |
Fixed values. Check MessageFunction chapter |
yes |
Identifies the function being performed. |
ProtocolVersion |
String |
{1..6} char |
yes |
Protocol version, commonly “5.0” |
ExchangeIdentification |
String |
{1..35} char |
yes |
Unique identifier for the transaction message exchange. |
CreationDateTime |
DateTime |
YYYY-MMDDthh:mm:ss.sss |
yes |
Timestamp of message creation. |
InitiatingParty |
Object |
yes |
Contains details about the party initiating the request. |
Code Name |
Name |
Description |
---|---|---|
SFSQ |
SaleFinancialServiceRequest |
Request a financial service like payment, reversal, loyalty, Balance Inquiry, etc. |
SFSP |
SaleFinancialServiceResponse |
Response to a financial service request. |
SSMQ |
MessageStatusRequest |
Request the status of a previous message for which the Sale system has no response. |
SSMR |
MessageStatusResponse |
Response to a Message Status request. |
SSRJ |
Rejection |
Reject a previous received message, for technical or functional reasons. |
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Identification |
String |
{1..35} char |
yes |
Identifier of the initiating party. |
Type |
String |
Fixed values. Check Type chapter |
Initiating party type such as merchant etc. |
Code Name |
Name |
Description |
---|---|---|
MERC |
Merchant |
Merchant providing goods and service in the card payment transaction. |
Environment
Environment of the transaction. It contains the sale environment as well.
Provides information about the Point of Interaction (POI) or terminal where the transaction is occurring
Field path |
Type |
Constraint |
Mandatory |
Description |
---|---|---|---|---|
Acquirer |
Object |
|||
Merchant |
Object |
|||
POI |
Object |
|||
Card |
Object |
|||
Cardholder |
Object |
|||
PaymentToken |
Object |
Acquirer Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Identification |
Object |
POI identifier object. |
Merchant Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Identification |
Object |
POI identifier object. |
POI Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Identification |
Object |
|||
Capabilities |
Identification Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Identification |
String |
yes |
Capabilities Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
MessageCapabilities |
MessageCapabilities Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Destination[] |
[String] |
yes |
||
AvailableFormat[] |
[String] |
|||
LineWidth |
Number |
{1..18} char |
Destination values
Code |
Name |
Description |
---|---|---|
CRCP |
CardholderReceipt |
Cardholder receipt. |
MRCP |
MerchantReceipt |
Merchant receipt. |
AvailableFormat values
Code |
Name |
Description |
---|---|---|
TEXT |
SimpleText |
Text without format attributes. |
Card Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
CardBrand |
String |
{1..35} char |
The brand of the card (e.g., VISA, Mastercard). |
|
MaskedPAN |
String |
{1..30} char |
Masked Primary Account Number of the card. |
|
PlainCardData |
Object |
Raw card data such as track information. |
Raw card data such as track information. |
PlainCardData Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
PAN |
String |
{8..28} char |
Contains the PAN of non PCI cards, e.g. fleet cards |
|
ExpiryDate |
DateTime |
MMYY |
Contains card expiry date |
|
Track1 |
String |
{8..28} char |
Contains Track 1 information from the card. |
|
Track2 |
String |
{1..37} char |
Contains Track 2 information from the card. |
|
Track3 |
String |
{1..104} char |
Contains Track 3 information from the card. |
CardHolder Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Language |
String |
{2..3} char |
ISO 639-1 (alpha-2) and ISO 639-2 (alpha-3) language code |
PaymentToken Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
PaymentToken |
String |
{1..19} char |
Terminal specific card token |
ServiceRequest
The ServiceRequest object resides within the SaleToPOIServiceRequest envelope and holds the transaction details based on the type of operation being performed. It includes mandatory sub-objects like Environment, ServiceContent, and depending on the type of transaction transaction-specific objects like PaymentRequest.
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Environment |
Object |
yes |
Object definition |
|
ServiceContent |
String |
Fixed values. Check Context chapter |
Specifies the transaction type. |
|
PaymentRequest |
Object |
Contains payment specific details. |
||
ReversalRequest |
Object |
Contains payment specific details. |
||
CardAcquisitionRequest |
Object |
Provides card acquisition related data |
Code Name |
Name |
Description |
---|---|---|
FSPQ |
FinancialPaymentRequest |
The Sale System requests to the POI System to perform a payment (Purchase, Refund, ...). |
FSRQ |
FinancialReversalRequest |
The Sale System requests to the POI System to perform a reversal partial or complete to cancel a former payment service. |
FSAQ |
FinancialCardAcquisitionRequest |
The Sale System requests to the POI System to handle a card data acquisition on the card reader. |
Capabilities Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
MessageCapabilities |
Array |
List of message capabilities for the POI. |
MessageCapabailities Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
AvailableFormat |
Array |
Formats available for messages. |
||
Destination |
Array |
Possible destinations for the messages. |
||
LineWidth |
Integer |
Maximum line width supported for message outputs. |
AvailableFormat values
Code Name |
Name |
Description |
---|---|---|
TEXT |
SimpleText |
Text without format attributes. |
Destination values
Code Name |
Name |
Description |
---|---|---|
CRCP |
CardholderReceipt |
Cardholder receipt |
MRCP |
MerchantReceipt |
Merchant receipt. |
POI Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Identification |
Object |
POI identifier object. |
TransactionIdentification Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
TransactionDateTime |
DataTime |
YYYY-MMDDThh:mm:ss.sss |
yes |
Timestamp of when the transaction or original transaction occurred. |
TransactionReference |
String |
yes |
Unique reference identifier for the transaction or original transaction. |
OriginalTransaction Sub-Object Fields
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
TransactionIdentification |
Object |
yes |
Identification details for the transaction. |
Identification Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Identification |
String |
{1..35} char |
yes |
Identifier name |
TransactionType / PaymentType values
Code Name |
Name |
Description |
---|---|---|
CRDP |
CardPayment |
Card payment. |
RFND |
Refund |
Refund transaction. |
PaymentRequest Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
PaymentTransaction |
Object |
yes |
Contains details about the payment transaction. |
PaymentTransaction Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
TransactionType |
String |
Fixed value |
Yes |
Describes the transaction type, typically "CRDP" for card payment. |
ServiceAttribute |
String |
Fixed value |
Yes |
Attribute for the service. |
AdditionalService |
Array |
Fixed values |
Lists additional services such as "GRTT" (Gratuity) and "CSHB" (Cashback). |
|
TransactionIdentification |
Object |
Yes |
Identification details for the transaction. |
|
OriginalTransaction |
Object |
N/A |
Yes |
Details of the original transaction associated with this reservation. |
TransactionDetails |
Object |
Yes |
Contains the currency, total amount, and optional detailed amounts. |
ServiceAttribute
Code Name |
Name |
Description |
---|---|---|
IRES |
IntialReservation |
Initial reservation. |
URES |
UpdateReservation |
Update reservation. |
PRES |
PaymentReservation |
Payment reservation. (Reservation capture) |
AdditionalServices
Code Name |
Name |
Description |
---|---|---|
GRTT |
Grauity |
Card payment with gratuity, also known as tip. |
CSHB |
Cashback |
Card payment with cashback. |
TransactionDetails Sub-Objects
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Currency |
String |
[A-Z]{3,3} |
Yes |
ISO 4217 Currency code, such as "EUR". |
TotalAmount |
Number |
Positive Number |
Yes |
Total amount for the transaction including any additional charges. |
DetailedAmount |
Object |
Provides a breakdown of additional amounts such as cashback and gratuity. |
||
CumulativeAmount |
Number |
Positive Number |
Total amount accumulated for the reservation. |
|
AmountQualifier |
String |
Fixed value |
Qualifier indicating the nature of the amount. |
Amount Qualifier
Code Name |
Name |
Description |
---|---|---|
INCR |
Incremental |
Incremental amount for reservation. |
DetailedAmount Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
CashBack |
Number |
Positive Number |
Amount of cash back offered to the customer. |
|
Gratuity |
Number |
Positive Number |
Gratuity or tip amount added to the transaction. |
Notes:
- Mandatory Fields: Fields such as TransactionType, TransactionIdentification, and TransactionDetails are mandatory for all transactions.
- Optional Fields: The AdditionalService and DetailedAmount fields are optional and should only be included when specific services like tip or cashback are processed.
- TotalAmount: The TotalAmount must reflect the sum of all applicable amounts, including the base transaction and any additional amounts like cashback or gratuity.
PaymentRequest Examples
Payment with Cashback
{
"SaleToPOIServiceRequest": {
"Header": {…},
"ServiceRequest": {
"Environment": {…},
"ServiceContent": "FSPQ",
"PaymentRequest": {
"PaymentTransaction": {
"TransactionType": "CRDP",
"AdditionalService": ["GRTT", "CSHB"],
"TransactionIdentification": {
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00",
"TransactionReference": "R26197055"
},
"TransactionDetails": {
"Currency": "EUR",
"TotalAmount": 18.00,
"DetailedAmount": {
"CashBack": 2.00
}
}
}
}
}
}
}
Refund
{
"SaleToPOIServiceRequest": {
"Header": {…},
"ServiceRequest": {
"Environment": {…},
"ServiceContent": "FSPQ",
"PaymentRequest": {
"PaymentTransaction": {
"TransactionType": "RFND",
"TransactionIdentification": {
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00",
"TransactionReference": "R26197055"
},
"TransactionDetails": {
"Currency": "EUR",
"TotalAmount": 104.11
}
}
}
}
}
}
Reservation
{
"SaleToPOIServiceRequest": {
"Header": {…},
"ServiceRequest": {
"Environment": {…},
"ServiceContent": "FSPQ",
"PaymentRequest": {
"PaymentTransaction": {
"TransactionType": "RESA",
"ServiceAttribute": "IRES",
"TransactionIdentification": {
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00",
"TransactionReference": "R26197055"
},
"TransactionDetails": {
"Currency": "EUR",
"TotalAmount": 15.00
}
}
}
}
}
}
Reservation incrementation
{
"SaleToPOIServiceRequest": {
"Header": {…},
"ServiceRequest": {
"Environment": {…},
"ServiceContent": "FSPQ",
"PaymentRequest": {
"PaymentTransaction": {
"TransactionType": "RESA",
"ServiceAttribute": "URES",
"TransactionIdentification": {
"TransactionDateTime": "2020-05-08T18:13:51.0+01:00",
"TransactionReference": "R26197055"
},
"OriginalTransaction": {
"TransactionIdentification": {
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00",
"TransactionReference": "2;00999100022;43350829991;79454;010099910002243350829991;"
}
},
"TransactionDetails": {
"Currency": "EUR",
"TotalAmount": 15.00,
"CumulativeAmount": 35.00,
"AmountQualifier": "INCR",
"ValidityDate": "2020-05-09T18:13:51.0+01:00"
}
}
}
}
}
}
Purchase Reservation
{
"SaleToPOIServiceRequest": {
"Header": {…},
"ServiceRequest": {
"Environment": {…},
"ServiceContent": "FSPQ",
"PaymentRequest": {
"PaymentTransaction": {
"TransactionType": "RESA",
"ServiceAttribute": "PRES",
"TransactionIdentification": {
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00",
"TransactionReference": "R26197055"
},
"OriginalTransaction": {
"TransactionIdentification": {
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00",
"TransactionReference": "2;00999100022;43350829991;79454;010099910002243350829991;"
}
},
"TransactionDetails": {
"Currency": "EUR",
"TotalAmount": 15.00
}
}
}
}
}
}
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
ReversalTransaction |
Object |
Yes |
Contains details about the reversal transaction. |
|
RevealReason |
String |
Predefined values |
Yes |
Reason for reversal. |
ReversalReason
Code Name |
Name |
Description |
---|---|---|
CUSC |
CustomerCancellation |
Customer cancels the transaction. |
MALF |
Malfuntion |
Reversal after a suspection of malfunction of the POI system. |
MERC |
MerchantCancellation |
Merchant or Cashier cancels the transaction. |
UNAB |
UnableToComplete |
POI System unable to complete transaction. |
ReversalTransaction Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
TransactionType |
String |
Fixed value |
Yes |
Describes the transaction type, like "CRDP" for card payment. |
OriginalTransaction |
Object |
Yes |
Contains details of the original transaction being reversed. |
Reversal Example
{
"SaleToPOIServiceRequest": {
"Header": {
},
"ServiceRequest": {
"Environment": {
},
"ServiceContent": "FSRQ",
"ReversalRequest": {
"ReversalTransaction": {
"TransactionType": "CRDP",
"OriginalTransaction": {
"TransactionIdentification": {
"TransactionReference": "2;00000000002;61479390591;169868;010000000000261479390591;",
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00"
}
}
},
"ReversalReason": "MERC"
}
}
}
}
CardAcquisitionRequest Sub-Object
A cardAcquisitionRequest is utilized to obtain a PAN from a payment card alone or to execute a particular transaction to obtain the payment response and a token.
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
TotalAmount |
Number |
Positive Number |
Total amount involved in the card acquisition. |
|
PaymentType |
String |
Fixed value |
Type of payment transaction. |
|
SaleToPOIData |
String |
Yes |
Contains additional data for the sale to POI interaction. (as JSON String) |
SaleToPOIData Sub-Object Fields
SaleToPOIData is a JSON string and the following fields needs to be added.
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
tipAmount |
Number |
Positive Number |
Tip amount included in the transaction. |
|
cashbackAmount |
Number |
Positive Number |
||
currency |
String |
[A-Z]{3,3} |
ISO 4217 Currency code, such as "EUR". |
|
recognitionTimeout |
Number |
Positive Integer |
Time in milliseconds to wait for card recognition. |
|
recognitionOptions |
Array |
Yes |
Options for card recognition, supported values are: "WPI_RECOGNITION_OPTION_RETURN CUSTOMER TOKEN" |
CardAcquisitionRequest Example
{
"SaleToPOIServiceRequest": {
"Header": {…},
"ServiceRequest": {
"Environment": {…},
"ServiceContent": "FSAQ",
"CardAcquisitionRequest": {
"TotalAmount": 15.00,
"PaymentType": "CRDP",
"SaleToPOIData": {
'tipAmount': 2.00,
'currency': "EUR",
'recognitionTimeout': 60000,
'recognitionOptions': [
'WPI_RECOGNITION_OPTION_RETURN_CUSTOMER_TOKEN'
]
}
}
}
}
}
ServiceResponse
The ServiceResponse object resides within the SaleToPOIServiceResponse envelope and holds the transaction response details based on the type of operation being performed. It includes mandatory sub-objects like Environment, ServiceContent, and depending on the type of transaction transaction-specific objects like PaymentResponse.
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Environment |
Object |
yes |
Object definition |
|
ServiceContent |
String |
Fixed values |
yes |
Specifies the transaction type. |
PaymentResponse |
Object |
Contains payment specific response details. |
||
ReversalResponse |
Object |
Contains reversal specific response details. |
||
CardAcquisitionResponse |
Object |
Provides card acquisition response related data. |
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
SaleTransactionIdentification |
Object |
Yes |
Identification details of the sale transaction. |
|
POITransactionIdentification |
Object |
Yes |
Identification details of the point-of-interaction transaction. |
|
RetailerPaymentResult |
Object |
Yes |
Contains the result of the retailer payment transaction. |
|
PaymentReceipt |
Array |
List of receipts generated for the payment transaction. |
SaleTransactionIdentification Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
TransactionDateTime |
DataTime |
YYYY-MMDDThh:mm:ss.sss |
Yes |
Timestamp of when the transaction or original transaction occurred. |
TransactionReference |
String |
Yes |
Unique reference identifier for the transaction or original transaction. |
POITransactionIdentification Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
TransactionDateTime |
DataTime |
YYYY-MMDDThh:mm:ss.sss |
Yes |
Timestamp of when the transaction or original transaction occurred. |
TransactionReference |
String |
Yes |
Unique reference identifier for the transaction or original transaction. |
POITransactionIdentification Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
TransactionType |
String |
Fixed value |
Yes |
Type of transaction performed. |
AdditionalService |
Array |
Fixed value |
No |
List of additional services used, e.g., gratuity or cashback. |
RequestedTransaction |
Object |
Yes |
Details of the requested transaction, including type and details. |
|
TransactionResponse |
Object |
Yes |
Response details from the payment authorization. |
|
CustomerLanguage |
String |
No |
Language preference of the customer. |
RequestTransaction Sub-Object
Field name |
Type |
Cosntraints |
Mandatory |
Description |
---|---|---|---|---|
TransactionType |
String |
Fixed value |
Yes |
Type of transaction requested. |
TransactionIdentification |
Object |
Yes |
Identification details of the requested transaction. |
|
TransactionDetails |
Object |
Yes |
Details of the transaction, including currency and amounts. |
TransactionResponse Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
AuthorisationResult |
Object |
Yes |
Details of the authorization result. |
AuthorisationResult Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
ResponseToAuthorisation |
Object |
Yes |
Contains the authorization response code. |
|
AuthorisationCode |
String |
Yes |
Code provided for the authorization. |
ResponseToAuthorisation Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Descriptions |
---|---|---|---|---|
Response |
String |
Fixed value |
Yes |
Response status |
Response
Code Name |
Name |
Description |
---|---|---|
APPR |
Approved |
Service has been successfully provided. |
DECL |
Declined |
Service is declined. |
TECH |
TechnicalError |
Service failed for technical reason |
Receipt
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
DocumentQualifier |
String |
Fixed value |
Yes |
Specifies the type of document (e.g., "CRCP" for cardholder receipt). |
OutputContent |
String |
Fixed value |
Yes |
Format of the content provided (e.g., "SimpleText"). |
MessageDestination |
String |
Fixed value |
Yes |
Where the message is intended to be sent (e.g., "CRCP", "MRCP"). |
MessageContent |
String |
Yes |
The actual content of the message or receipt, typically formatted as text. |
DocumentQualifier
Code Name |
Name |
Description |
---|---|---|
CRCP |
CustomerReceipt |
When the Sale System requires the POI system to print the Customer receipt. |
HRCP |
CashierReceipt |
When the Sale system print the Cashier copy of the Payment receipt. |
SRCP |
SaleReceipt |
When the Sale System requires the POI system to print the Sale receipt. |
OutputContent
Code Name |
Name |
Description |
---|---|---|
TEXT |
SimpleText |
Text without format attributes. |
MessageDestination
Code Name |
Name |
Description |
---|---|---|
CRCP |
CardholderReceipt |
Cardholder receipt |
MRCP |
MerchantReceipt |
Merchant receipt |
RequestResponse Example
{
"SaleToPOIServiceResponse": {
"Header": {
"MessageFunction": "SFSP",
"ProtocolVersion": "5.0",
"ExchangeIdentification": "642",
"CreationDateTime": "2020-05-04T18:13:51.0+01:00",
"InitiatingParty": {
"Identification": "WL000D5T0000004",
"Type": "MERC"
}
},
"ServiceResponse": {
"Environment": {
"Acquirer": {
"Identification": {
"Identification": "00999100022"
}
},
"Merchant": {
"Identification": {
"Identification": "WL000D5T0000004"
}
},
"POI": {
"Identification": {
"Identification": "26197214"
}
},
"Card": {
"CardBrand": "VISA CREDIT",
"MaskedPin": "XXXXXXXXXXXX0119"
},
"CardHolder": {
"Language": "FR"
}
},
"ServiceContent": "FSPP",
"PaymentResponse": {
"SaleTransactionIdentification": {
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00",
"TransactionReference": "R26197055"
},
"POITransactionIdentification": {
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00",
"TransactionReference": "2;00999100022;19940829991;79429;010099910002219940829991;"
},
"RequestedTransaction": {
"TransactionType": "CRDP",
"AdditionalService": ["GRTT", "CSHB"],
"RequestedTransaction": {
"TransactionType": "CRDP",
"TransactionIdentification": {
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00",
"TransactionReference": "579"
},
"TransactionDetails": {
"TotalAmount": 18.00,
"Currency": "EUR",
"DetailedAmount": {
"CashBack": 2.00,
"Gratuity": 3.00
}
}
},
"TransactionResponse": {
"AuthorisationResult": {
"ResponseToAuthorisation": {
"Response": "APPR"
},
"AuthorisationCode": "00"
}
},
"CustomerLanguage": "FR"
},
"PaymentReceipt": [
{
"DocumentQualifier": "CRCP",
"OutputContent": {
"MessageDestination": "CRCP",
"Format": "SimpleText",
"MessageContent": "--------------------------------\n
QA NIEXP\n
Chau. de Haecht 1442\n
1130 Brussels\n
--------------------------------\n
\n
***Cardholder Receipt***\n
\n
Purchase\n
VISA CREDIT contactless\n
XXXXXXXXXXXX0119\n
Account Type: Credit\n
\n
03.07.2024 14:16:23\n
Trm-Id: 26197214\n
AID: A0000000031010\n
Trx. Seq-Cnt: 79429\n
Trx. Ref-No: 19940829991\n
Auth. Code: 057737\n
Acq-Id: 999100022\n
\n
\n
Total-EFT EUR: 18.00\n
\n
Transaction OK"
}
},
{
"DocumentQualifier": "HRCP",
"OutputContent": {
"MessageDestination": "MRCP",
"Format": "SimpleText",
"MessageContent": "--------------------------------\n
QA NIEXP\n
Chau. de Haecht 1442\n
1130 Brussels\n
--------------------------------\n
\n
Purchase\n
VISA CREDIT contactless\n
XXXXXXXXXXXX0119\n
Account Type: Credit\n
\n
03.07.2024 14:16:23\n
Trm-Id: 26197214\n
Act-Id: 40\n
AID: A0000000031010\n
Trx. Seq-Cnt: 79429\n
Trx. Ref-No: 19940829991\n
Auth. Code: 057737\n
Acq-Id: 999100022\n
E4B00E9F1B979BCEF016662BF9C201D5\n
02/10\n
\n
\n
Total-EFT EUR: 18.00\n
\n
Transaction OK"
}
}
]
},
"Response": {
"Response": "SUCC"
}
}
}
}
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
SaleTransactionIdentification |
Object |
Yes |
Identification details of the sale transaction involved in the reversal. |
|
POITransactionIdentification |
Object |
Yes |
Identification details of the POI transaction involved in the reversal. |
|
ReversalTransactionResult |
Object |
Yes |
Details about the result of the reversal transaction. |
|
ReversedAmount |
String |
Total amount that was reversed. |
||
Receipt |
Array |
List of receipts generated for the reversal transaction |
ReversalTransactionResult Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
OriginalPaymentTransaction |
Object |
Yes |
Details of the original payment transaction that is being reversed. |
OriginalPaymentTransaction Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
TransactionType |
String |
Fixed value |
Yes |
Type of the original transaction, e.g., "RESA" (reservation). |
ServiceAttribute |
String |
Fixed value |
No |
Additional attributes related to the service, e.g., "IRES" (initial reservation). |
TransactionIdentification |
Object |
Yes |
Identification details for the original transaction. |
|
TransactionDetails |
Object |
Yes |
Details about the transaction, including currency and total amount. |
ReversalResponse Example
{
"SaleToPOIServiceResponse": {
"Header": {
"MessageFunction": "SFSP",
"ProtocolVersion": "5.0",
"ExchangeIdentification": "642",
"CreationDateTime": "2020-05-04T18:13:51.0+01:00",
"InitiatingParty": {
"Identification": "SaleTermA",
"Type": "MERC"
}
},
"ServiceResponse": {
"Environment": {
"Acquirer": {
"Identification": {
"Identification": "00999100022"
}
},
"Merchant": {
"Identification": {
"Identification": "WL000D5T0000004"
}
},
"POI": {
"Identification": {
"Identification": "26197214"
}
},
"Card": {
"MaskedPAN": "XXXXXXXXXXXX0119"
},
"CardHolder": {
"Authentication": [
{
"AuthenticationMethod": "BYPS"
}
]
}
},
"ServiceContent": "FSRP",
"ReversalResponse": {
"SaleTransactionIdentification": {
"TransactionDateTime": "2020-05-08T18:13:51.0+01:00",
"TransactionReference": "651"
},
"POITransactionIdentification": {
"TransactionDateTime": "2020-05-08T18:13:51.0+01:00",
"TransactionReference": "2;00999100022;80450829991;79490;010099910002280450829991;"
},
"ReversalTransactionResult": {
"OriginalPaymentTransaction": {
"TransactionType": "RESA",
"ServiceAttribute": "IRES",
"TransactionIdentification": {
"TransactionDateTime": "2020-05-08T18:13:51.0+01:00",
"TransactionReference": "2;00000000002;56514186991;210702;010000000000256514186991;"
},
"TransactionDetails": {
"Currency": "EUR",
"TotalAmount": 15.00
}
}
},
"ReversedAmount": "1000",
"Receipt": [
{
"DocumentQualifier": "CRCP",
"OutputContent": "SimpleText",
"MessageDestination": "CRCP",
"MessageContent": "--------------------------------\n
QA NIEXP\n
Chau. de Haecht 1442\n
1130 Brussels\n
--------------------------------\n
\n
***Cardholder Receipt***\n
\n
Reversal\n
VISA CREDIT\n
Account Type: Credit\n
\n
04.07.2024 10:22:17\n
Trm-Id: 26197214\n
AID: A0000000031010\n
Trx. Seq-Cnt: 79490\n
Rev. Seq-Cnt: 79489\n
Trx. Ref-No: 80450829991\n
Acq-Id: 999100022\n
\n
Total-EFT EUR: 15.00\n
\n
Transaction OK"
},
{
"DocumentQualifier": "HRCP",
"OutputContent": "SimpleText",
"MessageDestination": "MRCP",
"MessageContent": "--------------------------------\n
QA NIEXP\n
Chau. de Haecht 1442\n
1130 Brussels\n
--------------------------------\n
\n
Reversal\n
VISA CREDIT\n
Account Type: Credit\n
\n
04.07.2024 10:22:17\n
Trm-Id: 26197214\n
Act-Id: 40\n
AID: A0000000031010\n
Trx. Seq-Cnt: 79490\n
Rev. Seq-Cnt: 79489\n
Trx. Ref-No: 80450829991\n
Acq-Id: 999100022\n
\n
Total-EFT EUR: 15.00\n
\n
Transaction OK"
}
]
},
"Response": {
"Response": "SUCC"
}
}
}
}
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
SaleTransactionIdentification |
Object |
Yes |
Identification details of the sale transaction. |
|
POITransactionIdentification |
Object |
Yes |
Identification details of the point-of-interaction transaction. |
CardAcquisitionResponse Example
{
"SaleToPOIServiceResponse": {
"Header": {…},
"ServiceResponse": {
"Environment": {
"Acquirer": {
"Identification": {
"Identification": "00999100022"
}
},
"Merchant": {
"Identification": {
"Identification": "WL000D5T0000004"
}
},
"POI": {
"Identification": {
"Identification": "26197214"
}
},
"Card": {
"PlainCardData": {
"Track1": "…",
"Track2": "…",
"Track3": "…"
},
"MaskedPin": "XXXXXXXXXXXX0119"
},
"PaymentToken": {
"PaymentToken": "…"
},
"CardHolder": {
"Language": "FR"
},
"ServiceContent": "FSAP",
"CardAcquisitionResponse": {
"SaleTransactionIdentification": {
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00",
"TransactionReference": "R26197055"
},
"POITransactionIdentification": {
"TransactionDateTime": "2020-05-04T18:13:51.0+01:00",
"TransactionReference": "2;00999100022;19940829991;79429;010099910002219940829991;"
}
},
"Response": {
"Response": "SUCC"
}
}
}
}
Reject
The Reject object resides within the SaleToPOIMessageRejection envelope and is sent by one of the parties when it detects a technical or functional error in a previously received message.
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Reject |
Object |
yes |
Specifies the transaction type. |
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
RejectReason |
String |
Fixed value |
yes |
Reason for aborting a transaction. |
AdditionalInformation |
String |
Max 500 char |
Additional information related to the reject of the exchange. |
|
MessageInError |
Binary |
Max 100k |
Original request that caused the recipient party to reject it. |
RejectionReason
Code Name |
Name |
Description |
---|---|---|
UNPR |
UnableToProcess |
Not possible to process the message, for instance the security module is unavailable, the hardware is unavailable, or there is a problem of resource. |
IMSG |
InvalidMessage |
Invalid envelope of the message. |
PARS |
ParsingError |
Invalid message: At least one of the data element or data structure is not present, the format, or the content of one data element or one data structure is not correct. |
SECU |
Security |
Security error (for example an invalid key or an incorrect MAC value). |
INTP |
InitiatingParty |
Invalid identification data for the sender. |
RCPP |
RecipientParty |
Invalid identification data for the the receiver. |
DPMG |
DuplicateMessage |
Duplicate message, the identification of the exchange is the same than a previous message. |
VERS |
ProtocolVersion |
Version of the protocol couldn't be supported by the recipient. |
MSGT |
MessageType |
Type of message the recipient receives is unknow or unsupported. |
SystemAbort Example
{
"SaleToPOIMessageRejection": {
"Header": {
"MessageFunction": "SSRJ",
"ProtocolVersion": "5.0",
"ExchangeIdentification": "675",
"CreationDateTime": "2020-05-04T18:13:51.0+01:00",
"InitiatingParty": {
"Identification": "WL000D5T0000004",
"Type": "MERC"
}
},
"Reject": {
"RejectReason": "UNPR"
}
}
}
StatusRequest
The StatusRequest object resides within the SaleToPOIMessageStatusRequest envelope and is sent by a sale system when the sale system wants to know the status of previous message that has not been answered.
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Environment |
Object |
yes |
Object definition |
|
MessageStatusRequestData |
Object |
yes |
MessageStatusRequestData Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
ExchangeIdentification |
String |
Max 35 char |
yes |
Transaction identification. |
InitiatingParty |
Object |
yes |
Object Definition |
MessageStatusRequestData example
{
"SaleToPOIMessageStatusRequest": {
"Header": {
"MessageFunction": "SFSQ",
"ProtocolVersion": "5.0",
"ExchangeIdentification": "642",
"CreationDateTime": "2020-05-04T18:13:51.0+01:00",
"InitiatingParty": {
"Identification": "SaleTermA",
"Type": "MERC"
}
},
"StatusRequest": {
"Environment": {
"POI": {
"Identification": {
"Identification": "POITerm1"
}
}
},
"MessageStatusRequestData": {
"ExchangeIdentification": "642",
"InitiatingParty": {
"Identification": "SaleTermA",
"Type": "MERC"
}
}
}
}
}
StatusResponse
The StatusResponse object resides within the SaleToPOIMessageStatusResponse envelope and is sent by a POI System to respond to the sale system at a previous message status request.
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
Environment |
Object |
yes |
Object definition |
|
MessageStatusResponseData |
Object |
yes |
MessageStatusRequestData Sub-Object
Field name |
Type |
Constraints |
Mandatory |
Description |
---|---|---|---|---|
ExchangeIdentification |
String |
Max 35 char |
yes |
Transaction identification. |
InitiatingParty |
Object |
yes |
Object definition |
MessageStatusRequestData example
{
"SaleToPOIMessageStatusRequest": {
"Header": {
"MessageFunction": "SFSQ",
"ProtocolVersion": "5.0",
"ExchangeIdentification": "642",
"CreationDateTime": "2020-05-04T18:13:51.0+01:00",
"InitiatingParty": {
"Identification": "SaleTermA",
"Type": "MERC"
}
},
"StatusRequest": {
"Environment": {
"POI": {
"Identification": {
"Identification": "POITerm1"
}
}
},
"MessageStatusRequestData": {
"ExchangeIdentification": "642",
"InitiatingParty": {
"Identification": "SaleTermA",
"Type": "MERC"
}
}
}
}
}
Security and Compliance
- TLS/SSL is used by default for all communications involving the Terminal API. This ensures that data exchanged between clients and the server is encrypted, helping prevent eavesdropping and tampering.
- HSTS (HTTP Strict Transport Security) is also active. This protocol enforces the use of secure connections, ensuring that all interactions with the API are conducted over HTTPS.
- PCI Compliance
- The Terminal API is designed to comply with PCI DSS (Payment Card Industry Data Security Standard) requirements by default.
- No PCI-related data, such as full card numbers or other unmasked sensitive information, is available through the API. This minimizes risk and ensures compliance with industry standards for handling payment information securely.
- TLS/SSL is used by default for all communications involving the Terminal API. This ensures that data exchanged between clients and the server is encrypted, helping prevent eavesdropping and tampering.
- HSTS (HTTP Strict Transport Security) is also active. This protocol enforces the use of secure connections, ensuring that all interactions with the API are conducted over HTTPS.
- PCI Compliance
- The Terminal API is designed to comply with PCI DSS (Payment Card Industry Data Security Standard) requirements by default.
- No PCI-related data, such as full card numbers or other unmasked sensitive information, is available through the API. This minimizes risk and ensures compliance with industry standards for handling payment information securely.