# Configurations

All adapters has basic common configurations that should be provided by the developer.

The adapter name, version, and the corresponding remote acquiring processor name should be provided.

# Basic Configurations

# Network Configuration

This setting is done under the Configuration menu.

# Transport

The adapter transport configuration defines where the remote host is that this adapter will communicate with. Poynt current support the following transport methods:

• HTTPS

• SSL over TCP

Both method requires TLSv1.2.

# HTTPS

The HTTPS method of transporting your adapter communication will have support for custom HTTP headers. You can define custom HTTP headers against each of your adapter messages.

Generally, each transaction over HTTPS is made on a new connection to the remote host. Connections are not re-used across transaction.

# SSL over TCP

For this implementation of the transport, there are two modes that an adapter can configure:

• Length-Delimited Mode
• Not Length-Delimited Mode

In the Length-Delimited mode, once a message is packed and ready for transport, the transport will pre-pend 2 leading bytes with the value of the length of the actual payload. i.e.

     [XX][YY][.........payload........]

Where XX is the most-significant 8-bits of a 16-bit integer length and YY is the least-significant bits of that integer.

In this mode, the framework will expect that the responding message from the remote most to also contain the same leading 2-bytes length of the response message.

When length-delimited mode is not enabled, the framework will assume that a message is fully read whenever the remote host closes the socket connection.

# Endpoints

Each adapter is required to have both a testing and production endpoint. Testing traffic for the adapters will be routed automatically to the testing endpoint. Production endpoints may have placeholder values specified until the adapter is deemed ready for production.

Before deploying to production, a backup endpoint must also be specified should the primary production endpoint is unavailable for processing.

# Merchant Configuration

Default values of merchant on-boarding data can be defined through this screen. In a typical implementation, on-boarding data is updated through Poynt HQ. However, if any of these data are not updated in the Poynt HQ, then the default values defined in the Lego Framework are used. Also, some of the on-boarding data may not be available in the Poynt HQ. In this case, default value is used directly.

# Processor Fields

Processor Fields are key-value pairs of data that are specific to the acquirer processing the transaction. The framework allows you to define these properties for your adapter during development.

When a merchant is on-boarded to use your adapter, the processor properties specific to your adapter will be collected and stored.

At runtime, your adapter can access the processor properties of the business it is processing through a specific variable called $PROCESSOR_PROP.

# Constants

Often, an acquiring system will use common constant values in various point of the integration. It is often less error prone if you define constants variable to be used throughout your adapter definitions. These constants can be referenced globally via the special $ variable prefix i.e. BRICK is $BRICK at runtime.