SPI Architecture

With the exception of Pay@Table, there is no longer a need for the OPI server. The business logic and communication layer that with the OPI are handled by the OPI server are included in the SPI, which is a component of the Simphony client application. If a POS client has a PED attached, it is possible to be completely independent of the LAN for payment processing.

The SPI can be deployed using one of the following connection methods: Terminal mode or Middleware mode. Talk to your PSP to identify the mode(s) which are available and best suited to your environment.

Terminal Mode

POS Clients With Attached PEDs

In the ideal scenario, Simphony POS clients (typically Win32 or Win64) are each attached to a PED. This setup eliminates the need for a LAN connection.

Figure 12-3 POS Clients With Attached PEDs


This figure shows three POS clients with a PED attached to each POS client.

The process for a credit card transaction follows these steps (as illustrated in the following figure):

Figure 12-4 Terminal Mode Architecture With Attached PED


This figure shows the SPI terminal mode workflow with PED attached to POS client.

  1. POS Operations sends a payment request to the PED, addressing it as localhost:port.

  2. The PED communicates with the PSP Host and returns the token and voucher printing instructions to POS Operations.

  3. The token and other transaction details are saved in the Datastore on the POS client.

This scenario is independent of both the LAN and the OPI server.

POS Clients Without Attached PEDs

POS clients, such as tablets and Android devices, may not have PED devices directly attached. However, PSPs offer network-capable PEDs that can be used.

Figure 12-5 POS Clients Without Attached PEDs


This figure shows Android POS clients without PEDs attached.

The process for a credit card transaction follows these steps (as illustrated in the following figure):

Figure 12-6 Terminal Mode Architecture Without Attached PED


This figure shows the SPI terminal mode workflow without PED attached to POS client.

  1. POS Operations sends a payment request to the PED over the network, addressing it with its IP address:port.

  2. The PED communicates with the PSP Host and returns the token and voucher printing instructions to POS Operations.

  3. The token and other transaction details are saved in the Datastore on the POS client.

This scenario depends on a LAN connection and is vulnerable to network failure to the PED, but does not require an OPI server.

Middleware Mode

POS Clients With or Without Attached PEDs

The PSP provides an application, called middleware, which handles the mapping of a POS client to a PED.

The process for a credit card transaction follows these steps (as illustrated in the following figure):

Figure 12-7 Middleware Mode Architecture With or Without Attached PED


This figure shows the SPI middleware mode workflow.

  1. POS Operations sends a payment request to the IP address where the middleware application is configured.

  2. The middleware application passes the request to the appropriate PED.

  3. The PED communicates with the PSP Host and returns the token and voucher printing instructions to POS Operations.

  4. The token and other transaction details are saved in the Datastore on the POS client.

This scenario depends on a LAN connection and is vulnerable to network failure to the PED, but does not require an OPI server.

Related Topics