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.
The adapter transport configuration defines where the remote host is that this adapter will communicate with. Poynt current support the following transport methods:
SSL over TCP
Both method requires TLSv1.2.
In the development environment ONLY, Poynt supports the use of self-signed SSL certificates to facilitate easier setup. However, your production environment must use a valid CA issued certificate.
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:
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.
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.
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.
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.