Appendix G - Routing Fusebox Messaging through the POS

Simplify supports routing Simplify-Fusebox messaging via the POS, using the same connection (Ethernet, RS232 etc.) as used for POS-Simplify messaging. The POS forwards the Simplify request to Fusebox and forwards the Fusebox response to Simplify. The POS must manage the certificate for the socket connection to Fusebox.

note

Note for Link2500: Since the Link2500 cannot communicate directly with Fusebox using WiFi, POS routing (e.g. using an Android tablet connected by USB) provides an indirect way for the device to send Simplify requests to Fusebox.

For requests from Simplify to the POS and responses from the POS to Simplify, a header attached to the message indicates forwarding, FBREQ: for the request and FBRSP: for the response. This header immediately precedes the first message field (no CR/LF). For example:

  • FBREQ:0001,02

Exception: If the POS cannot connect to Fusebox, the response from the POS contains the header FBERR: For example:

  • FBERR:0001,02

Points to Consider

  • Elavon recommends turning off status message 1 (in parm.fil).

  • The POS can use the request from Simplify as the starting point to wait for a response (before timing out).

Offline Processing

If POS Routing is enabled, communication errors on the request from the POS to Fusebox can be handled as follows:

  • If the POS does not receive a response from Fusebox, it allows Simplify to time out (no response sent to Simplify).

  • If the POS cannot connect to Fusebox, it echoes the request from Simplify except for the header, which is FBERR:

In either case, further processing is as described under POS SAF Processing (if enabled) and Inquiry Message. (Exception: any required Fusebox messaging uses POS routing.) I.e. if POS SAF is enabled and the transaction is SAF-eligible, Simplify sends a Stand-in Response to the POS (API 1010 = “*SLR STAND-IN.”) containing the data needed for the POS to perform Stand-in and SAF processing; else Simplify sends a decline.

The message flow for an offline Sale transaction using POS Routing is as follows:

Simplify processes a Sale request from the POS and sends it to Fusebox via the POS with a FBREQ: header.

  • If the POS cannot open a socket to Fusebox , it echoes the request back to Simplify with a FBERR: header.
  • If the POS times out waiting for a response from Fusebox, it lets Simplify time out.

In either case:

  • If Stand-in is enabled and the transaction is SAF-eligible, Simplify returns “*SLR STAND-IN.” in API 1010, together with the data required for the POS to perform Stand-in.
    • If Stand-in is performed, Inquiry request meesages for the transaction sent from the POS to Simplify will be routed to Fusebox through the POS with FBREQ: and FBRSP: headers, and similarly for the Inquiry response.
      • If the Inquiry response from Simplify indicates transaction not found, the POS re-sends the Sale (as a Forced transaction) which will be routed as above.
      • If found, POS is done.
  • Else, Simplify declines the transaction with a comm error.
    • In this case, or if the POS declines the transaction, Inquiries for the transaction will be routed as described above.
      • If the Inquiry response from Simplify indicates transaction found, the POS sends a Void request, which will be routed as described above, i.e. with FBREQ: and FBRSP: headers, and similarly for the Void response.
      • If transaction not found, POS is done.
  • For timeouts on Voids and Inquiries, an Inquiry will need to be sent (or re-sent).