Switch39

Software solution that serves as a station for receiving traffic from POS devices, translating POS protocols into “legacy” authorization systems protocols and routing in multi acquiring schemes.

Main functionality

1. Strong cryptography
2. Persistent link maintenance
3. Mux / demux link on a persistent link
4. Physical and logical link switching in case of error
5. Implementation of “network administration” messaging
6. Systan management in cloud-friendly environment

Accessibility to developers

Almost all the complex work of integrating a new bank link becomes a matter of integrating a simple HTTP api - something that every web developer knows, and the development of a transaction switch at one time becomes of similar complexity as the development of a web shop.

Scalability, high availability and deployment

Any strategy that would work in website deployment in the 21st century - from Kubernetes, hosting on AWS (Amazon AWS is PCI DSS level 1 compliant), backend cluster scalability, etc. - is transparently available. The switch comes with health-check routes for all its critical components and is designed with containerization in mind. Traditional high availability tools like HAProxy will be easy to implement regardless of your system administrator’s level of knowledge of financial systems.

Multi Acquiring and high availability

Switch allows the maintenance of an arbitrary number of routes to each acquiring institution. If one link becomes unavailable, the switch will redirect traffic to one of the remaining available links without operator intervention. If all links to a given acquirer become unavailable, Switch supports simple DSL for transaction routing, which depends on the card issuer and the availability of the card link. It is possible, and easy, to configure a series of alternative routes for each card in such a way that transactions do not stop as long as there is at least one bank with an available connection.

POS integration

The integration of POS devices is done with a simple JSON protocol via HTTPS. Traditional methods of integrating POS with the Switch imply direct socket connections and binary protocols - this opens up a number of problems:

1. Connection security
2. Low intelligibility of binary protocols complicates the search for operational problems
3. Inability to use modern scaling tools (eg ingress controllers)
4. reduced protocol flexibility for atypical business cases

From experience, due to the non-traditional approach, we typically experience very short-term resistance from the POS development team, and it rarely takes more than a week until the first approved transaction.

POS Auto-enrollment

Enrollment of POS devices implies the existence of the so-called "black room" which is subject to strict PCI-PIN regulations and manual loading of keys using the so-called "master POS" device. The switch allows three basic auto-enrollment procedures:

1. Custom key derivation through the use of a pre-shared master key with the POS device manufacturer
2. Download keys using the RSA public key generated by the POS
3. DUKPT (best)

Unless you use DUKPT, the use of this module will depend on the correct choice of HSM, but many POSs do not have full DUKPT support (data encryption with DUKPT).

Support for embedded POS

POS normally uses TLS for P2P encryption between POS and host, but this is not enough in scenarios where POS does not control its communication channel, but communication is done through the controller component (vending devices, public transport,. ..). The switch comes with support for full message encryption using native HSM in POS, this allows deployment in embedded environments even with POS devices that are not P2PE compliant. Payment APIs are not the only potentially sensitive APIs consumed by the POS device, the Switch has a proxy component that allows the POS to communicate with its TMS through the Switch, thus gaining all the security protection the Switch provides, even in communication with TMS and other third party systems.

Micro Transport Support

Switch implements the Mastercard Global Transit standard for microtransactions. This standard enables the aggregation of microtransactions in the so-called "payment window" of 2-14 days (subject to the rules of card companies) on the entire POS network. Theclient can then request an aggregated presentation of these transactions via a special payment api. For example: the client buys coffee on the ground floor of the bank, and the next day buys coffee in the Importanne Center, after two days both transactions can be sent for debit as one transaction. In the context of the business model, this seems to us to be a very important functionality and a potential innovation in the world of vending devices (Competitive advantage). We recommend talking to MasterCard representatives about the introduction of this service for vending devices.

P2PE

P2PE support depends on the POS. The switch has a flexible P2PE support interface that easily adapts to the P2Pe POS specification using sensitive-data fields in authorization messages.

Merchant Integration

Switch comes with a two-way HTTPS / JSON API for merchants. API is expandable, and at this point supports:

1. Sync transactions with dealers in pseudo real time
2. Real-time insight into traffic on a particular point of sale
3. Management retail outlets (create, update and show)

Acquirer Integration

Almost without exception, acquirer integration on the POS Switch is done by integrating some flavor of ISO8583 protocol. The differences between the ISO8583 protocols can be very large, and neither is exactly the same. Link integration on the market usually costs between 6,000 and 50,000 EUR, thanks to the use of modern technologies and industry-standard practices we can offer more favorable conditions.

Support for closed-loop Mifare payment schemes

Mifare payment schemes traditionally suffer from problems with the security of cryptographic keys - namely, the master key for the entire card scheme must be stored in each of the receiving POS devices for the payment scheme to work. This shortcoming makes Mifare suitable for, for example, public transport, but unsuitable for the implementation of payment networks where the possibilities of abuse are far greater. Switch implements Mifare DesFire EV2 card initialization and unlock APIs that allow you to store keys in your organization's HSM module. The use of this module will depend on the correct choice of HSM.

Transaction Switching

Switch39 can be configured to perform only the transaction switching. This would mean that switch39 sits between different acquirers, can accept ISO 8583 messages, and can act as a protocol converter.

SSM / HSM Module

Switch supports software and hardware crypto operations (SSM and HSM).

1. Supported hardware platforms: Gemalto Luna EFT and any PKCS11 HSM. EFTPOS HSMs are necessary in case of working with online PIN. Quick development necessary for Utimaco and Thales HSMs.
2. Supported software platforms: JCEKS and (soon) HashiCorp Vault.

Environment

The Switch Environment consists of the following network subnets:

1. Switch39
2. Redis
3. Database
4. HSM

There must be a firewall between the listed subnets with the exact traffic that is necessary for the service to function.

Architecture diagram