Multi-merchant configuration in G8

Sharing card reader and point-of-sale (POS) hardware between different merchants, for example in a shared-use attended or unattended kiosk, is a surprisingly difficult problem. Each merchant organisation involved may use a different acquirer, might accept different card types, and may have different payment configuration parameters such as floor limits; each time the merchant using the card reader changes, the card reader must be reconfigured, which can be a lengthy process. This is particularly a problem where the merchant changes on a transaction-by-transaction basis, such as in a kiosk providing services from multiple organisations.

This sort of shared-use POS can be achieved by having the hardware provider present themselves as a merchant to a single acquirer; this presents a number of disadvantages compared with allowing merchants to use their own acquirers:

·       The hardware provider would need to act as a sort of mini-acquirer, ensuring that the money that it received from the acquirer is passed on to each merchant, with all of the associated legal and financial responsibilities

·       The merchants would have to integrate a further source of payments into their accounting systems, bypassing any value-added services that might otherwise be provided by their own Payment Service Provider (PSP) or acquirer.

·       Merchant lose any chance to distinguish themselves by payment types that they accept: for example, a company might accept a particular card brand across every channel, except at the shared-use POS.

G8, STS’ card reader-, Payment Service Provider- and Point of Sale-agnostic payment application, solves these problems by leveraging a number of existing and new features in a novel way to provide a seamless customer and merchant experience.

 

Using G8 at a shared-use POS

The intended set-up is as follows:

1.     Each point-of-sale (hardware) has a single card reader. On each piece of hardware there may be multiple point-of-sale applications, run by different merchant organisations. The points-of-sale might be attended or unattended.

2.     Some integrator, probably whoever supplies the POS hardware, ensures that an appropriately-configured G8:Enterprise instance is running on the POS hardware. We anticipate that the integrator will have some sort of broker software that selects which POS application to activate at any given moment; this broker may additionally wrap the G8:Enterprise and G8:Client APIs, or might expose either or both of those to the POS application.

3.     Specifically, the G8:Enterprise instance is configured so that all payment application instances all share the single card reader attached to the POS hardware, and with payment configuration for each merchant POS application, such as MIDs, floor limits, card schemes accepted.

4.     Each POS application has an identifier. This identifier must be unique within the POS hardware, but it may make life easier to ensure that it is globally unique, by, for example, generating the ID from the POS hardware’s ID, which may itself include the location of the hardware, plus the merchant name.

5.     When a particular POS application is activated, it uses its ID as the “Source ID” that is used to request a payment application instance from the G8:Enterprise system and starts a Tender as normal (see the G8 Integrator’s Guide for more details). G8:Enterprise selects the appropriate payment application instance, ensures the device is configured correctly, and processes card payments for the merchant. This configuration process has been designed to ensure that it takes almost no time at all.

6.     After completion of the transaction, another POS application may start a tender.

G8’s considered design means that the reconfiguration process when a new POS starts does not take any noticeable time.

 

The G8 advantage

Successfully providing shared-use POS hardware using each merchant’s own payment partners is a difficult problem to solve without G8. But beyond solving that problem, G8 naturally provides advantages to the POS hardware provider and merchants:

·       G8’s simple but powerful API allows each POS application to integrate at whatever level is required – from simply instructing G8 to take a payment, to providing on-screen prompts and recording additional payment statistics.

·       G8’s consistent, well-documented configuration files are easy to use, and are consistent across different card-reader hardware.

·       G8 is card reader-agnostic. Changing card reader hardware, manufacturer or even adding new payment types does not require a tricky new integration from each POS application, nor does it require learning a new configuration paradigm. Thus, the hardware provider can select card readers based on features and price without being locked in to a single manufacturer.

·       G8 seamlessly supports P2PE.

·       G8 is PSP-agnostic. If a merchant wishes to use a different PSP, the appropriate driver can be selected (or developed, if it is not yet supported by G8) without requiring any further integration work on the POS application.

 

Developed leveraging G8’s powerful existing features

STS was able to develop these mechanisms because of a number of pre-existing features. These are:

·       Device-agnostic configuration: G8 has its own payment configuration files that get translated into the appropriate form for each device, which means that integrators only need to understand one configuration paradigm, but can still offer a wide device choice. We leverage this ability to generate and download configuration onto a device by doing as and when required on a transaction-by-transaction basis when the merchant is selected. Additionally, the separation of the underlying device configuration from G8’s configuration files mean that STS could make internal changes to G8 to reduce the number of changes that have to be transferred to the device without affecting existing configuration files or other APIs.

·       G8:Enterprise and its XML interface identifies points-of-sale by an identifier known as a “Source ID”, and allows an integrator to select a G8 instance based on the Source ID. In G8:Enterprise, each G8 instance associated with a specific card reader device; it was a small step to allow the G8 instances to share a card reader. This means that the integrator effectively sets up a small G8:Enterprise instance on each POS, with multiple G8 configurations, all sharing the same device. When POS “A” wishes to use the device, it asks for the G8 instance for “A”, and G8 is able to seamlessly configure the device. Ensuring that devices cannot be used by multiple entities at the same time was already part of G8, thus there is no chance of confusing behaviour where multiple POS applications are in use.

·       G8:Enterprise has also always had pluggable mechanisms for configuring each G8 instance that it creates. These mechanisms were extended to allow configuration to be selected based upon patterns in the “Source ID”. In particular, this means that it is possible to use the same set of configuration files across a diverse estate of POS applications and card readers, with the configuration to use (e.g. merchant address, MIDs, displayed messages) selected based on the identifier of each of the POS applications. For example, the merchant IDs for merchants A, B and C which apply to all transactions that each merchant takes can be configured in in three files, and the addresses of locations X, Y and Z can be configured in three other files; at run time, when the POS called, say, “A-X-5” (that is, merchant A, location X, POS#5) connects, G8 can automatically select the merchant ID for merchant A, and the address for location X.

 

Conclusion

G8’s flexible design that allows it to be POS-, card-reader and PSP-agnostic also means that it can be used in innovative new environments. Here, we show how G8 can be used in a shared-use POS, with multiple merchant’s POS applications using the same card reader hardware without giving up the advantages of using their own payments infrastructure and partners. G8’s consistent, device-agnostic APIs mean that the providers of shared-use POS hardware can be flexible in future, for example by allowing the provider to select card reader hardware from a new manufacturer without requiring expensive reintegrations.

Wednesday, June 28, 2017
Drupal 7 Appliance - Powered by TurnKey Linux