4 Multiple Cores

This chapter describes the concept and procedures of setting up EFTLink using Multiple Cores.

EFTLink can be configured to use multiple cores for the purpose of redirecting requests based on:

• Line Display

• Request Type

• CardRange.xml

• Referrals

Figure 4-1 Multiple Cores

Line Display

Sale State Notification requests can either be disabled altogether or be forwarded to either one core or a delegated list of cores.

Preselected Cores

Preselected cores are configurable within the eftlinkconfig.properties file. You can configure EFTLink to forward requests to a particular core based upon EWallet, GiftCard (Card Service Request), or a Custom Form (Device Request).

CardRange.xml

EFTLink always checks the cardrange.xml before determining which core is selected for handling the card Service Request.

The cardrange.xml offers EFTLink the ability to redirect card service requests to preselected cores base on the *card pan or card type.

*As the POS is not subject to sending an EMV PAN due to PCI regulations. Card PAN is only applicable with non-PCI transactions (Gift card or Ewallet).

Referrals

EFTLink supports a referral feature whereby a core can request that another core handles the request on its behalf.

By default, EFTLink sets the main core (core 0) for referrals however this is configurable via EFTLinkConfig.Properties.

The cardrange.xml can also be used to redirect the referral to any active core.

A referral could be based upon a feature not supported or, it could be based upon a particular failed response / error code.

The core requesting the referral is in control and is responsible for the transaction response back to the POS.

*This feature is not supported by Oracle’s Strategic cores. However, it is possible to support the referral feature in an overlay.