PayOp uses a number of common, standardised mechanisms to ensure that it is scalable to many devices, payment applications and users, and to provide resilience to server or network failure. The use of standardised mechanisms mean that it can fit into existing frameworks and that it is easy to configure in completely greenfield environments.
The PayOp UI is a web-based user interface and consists of static content and scripts that can be served separately from the PayOp Service. This means that the entire UI can be cached in users’ web browsers or on intermediate proxies. Secondly, because the UI is entirely static content, as many servers can be deployed as needed to provide redundancy, load-balancing or geographical load sharing.
The PayOp Service provides an API that is used by the UI, the Agents and any other first- or third-party components. The Service is backed by a database, which is a single source of truth for the whole system. This database can be replicated to provide resilience to server failure, while the Service can be deployed as many times as necessary, although it is recommended that any load balancing performs session affinity to prevent UI users from being unexpectedly logged out.
Caching web proxies
Both the PayOp UI and the Service facilitate use of web proxies to reduce load on their servers and to reduce network usage. Caching proxies may be placed near the servers serving the PayOp UI or Service to reduce loads, or near to clients to reduce usage of the intermediate network.
When used with plain HTTP, a transparent caching proxy that follows the standard ETags and Cache-Control mechanisms will work well. However, clients are not able to authenticate the UI or Service, which increases the risk of man-in-the-middle attacks, etc.
When the PayOp components are served over HTTPS, which provides end-to-end privacy, non-transparent proxies must be used. Such proxies require configuration on the client: this can usually be done through the web browser for the UI; for the Agent, this can be done through configuration properties as described in the PayOp Integration Guide.
The PayOp Service allows as much as possible of the data it provides to be cached, while still supporting user access control; in particular, large downloads that will be used by many Agents such as software or firmware updates can be cached. To support this, the Service requires the proxy to forward all requests, but uses the ETags mechanism to signal that the proxy can transfer its cached copy instead of downloading a new copy from the Service.
Administrators should be aware that PayOp allows caching proxies to store data that would be made available only to authenticated and authorised users. Access to the proxy’s working files should therefore be restricted.
Load balancing and redundancy
Both the PayOp UI and the PayOp Service facilitate load-balancing using proxies or other mechanisms.
The PayOp UI serves static content (plus a configuration file that lists the Service URL and other data that is not expected to change regularly). It is, therefore, easy to serve from multiple servers using a load-balancing proxy, round-robin DNS or other load-distribution mechanisms.
The PayOp Service uses a server-side session to maintain the authentication status of clients, including the PayOp UI. This relies on a unique session ID being transmitted as a cookie to the client in a response, and then being mirrored back to the server in all subsequent requests. Thus any load-balancing must be performed using a mechanism that directs all requests from a particular client to the same server, for example, session-aware HTTP proxying.
A session-aware HTTP proxy uses the session ID cookie to direct requests from a particular client to a particular server. The exact name and content of the session cookie is dependent on the servlet container; for Tomcat, Jetty and so on, the cookie is named JSESSIONID by default, though this can be overridden in configuration.
When used with HTTPS, a session-aware HTTP proxy has to have access to the plaintext HTTP requests in order to read the session cookie; this means that the proxy has to be behind or part of a reverse proxy that is doing the SSL encryption and authentication on behalf of the service.
HTTPS
The PayOp UI and PayOp Service may be served over HTTPS. The responsibility for encryption and authentication lies with the server’s environment, and encryption and authentication is usually performed by a reverse proxy or the servlet container. This separation of responsibilities allows the use of existing or specialised hardware where it is available.
The PayOp UI may be served over HTTPS in order that clients can authenticate the source of the UI components. There is no confidential data served in the PayOp UI, so it is not necessary to provide any form of client authentication.
The PayOp Service may also be served over HTTPS to provide server authentication and confidentiality. PayOp Service does not support client authentication at present. Note that if combined with load-balancing/redundancy using a session-aware HTTP proxy, then the encryption component must be performed by a reverse proxy, and the session-aware load-balancer must be behind it so that it has access to plaintext HTTP data.
Conclusions
PayOp’s design and thoughtful use of standards ensures that, while it is easy to use securely from the outset, it can also scale with your requirements and fit into existing infrastructure.
To find out more about how PayOp can deliver improved management fo payment devices, operation efficiency and insight, do get in contact – we’d be pleased to chat and arrange a demo.