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 workstation 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

Workstations With Attached PEDs

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

Figure 11-1 Workstations With Attached PEDs


This figure shows three workstations with a PED attached to each workstation.

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

Figure 11-2 Terminal Mode Architecture With Attached PED


This figure shows the SPI terminal mode workflow with PED attached to a workstation.

  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 workstation.

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

Workstations Without Attached PEDs

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

Figure 11-3 Workstations Without Attached PEDs


This figure shows Android workstations without PEDs attached.

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

Figure 11-4 Terminal Mode Architecture Without Attached PED


This figure shows the SPI terminal mode workflow without PED attached to a workstation.

  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 workstation.

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

Workstations With or Without Attached PEDs

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

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

Figure 11-5 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 workstation.

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

Parent topic: The Simphony Payment Interface (SPI)