Getting Started

Fusebox is Elavon’s secure, flexible hosted payment gateway. It provides a single interface for delivering payments securely across all business locations to your choice of payment processor.

This API format encompasses the data requirements for every industry method of payment and transaction processor supported by the Elavon Gateway software applications. It allows you to certify once while providing access to 17 third party processors.

This guide addresses most card association guidelines and focuses primarily on card present transactions.

This page walks through the processes of how to:

  • Set up a test account.
  • Send your first request important fields to test.
  • Perform final certification and move to production.

Step 1: Business Requirements/Get test credentials

If you’re not already working with a Solutions Engineer, you’ll need to contact Elavon Sales at websales@elavon.com and have someone assigned. Together you will identify your specific integration use cases, card processing requirements, and fulfill PIN pad requests, if applicable. Your Solutions Engineer will set up test credentials so you can begin development.

For a transaction to be accepted by Fusebox, the following fields must be included. These are the values provided to you by your Solution Engineer:

  • Chain Code (API Field 8006) – This is where company information is stored.
  • Location ID (API Field 8002) – This is where geographic location information is stored.
  • Terminal ID (API Field 109) – This is where your merchant processor settings are stored.

You may also receive a site ID, user name, and password. You can access your account through the Fusebox web application.

Step 2: Development

Once you have a test account set up, you are ready to try out your first transaction. There are two ways to connect to Fusebox: TCP/IP or XML HTTPS POST. If your integration or merchant is operating to Fusebox with a VPN, MPLS, Frame connection, then a SLB IP address and port will be published to the specific implementation.

  • For TCP/IP with TLS 1.2, use: https://gatewaydemomoc.elavon.net:7000
  • For XML HTTPS POST use: https://gatewaydemomoc.elavon.net:7500

The HTTPS POST should have a ContentType of “xml/text”, and DO NOT “URL encode” the XML DOC. You may need to ASCII encode your API when converting it to a Byte Array, (to make it UTF-8 compatible) depending on your choice of programming languages.

Following is an example of a basic Auth Only request and the expected response.

Request

0001,01
0002,2.50
0003,4124939999999990
0004,1220
0007,13455
0025,030107
0050,123
0052,0
0060,00000001
0070,1111ABC
0071,1
0072,1.00
0109,00000003
0110,105
0115,010
0647,1
0700,135021234
0701,333 GENESEE STREET
1008,ID
1105,DOCID:123345678901
5002,123456
8002,DEVTSTQA
8006,DEVTST

Response

0001,01
0002,2.50
0003,************9990
0004,1220
0006,117996
0007,13455
0009,0010
0025,030107
0030,1
0032,091319
0033,144043
0034,E
0035,2232
0036,019091314392828
0037,5
0038,00
0040,M
0043,111009
0050,***
0052,0
0060,00000001
0070,1111ABC
0071,1
0072,1.00
0109,00000003
0110,105
0115,010
0126,0
0128,2.50
01302.50
0131,00
0632,10.00
0647,1
0700,135021234
0701,333 GENESEE STREET
1000,VI
1001,VISA
1004,AP
1005,0010600008014593613999
1008,************9990
1009,000
1020,A
1105,DOCID:123345678901
5002,123456
7007,1119256672439765
8002,DEVTSTQA
8006,DEVTST

For more information on connectivity and formatting Fusebox Requests, see: API Message Format.

View our Test Cards page for approved card numbers in our test environment and the Elavon Test Host Pre-programmed Responses document to generate a variety of responses and CVV response codes.

Step 3: Transaction Testing

You will want to test all transaction types supported by your integration.

• See our Transaction Types page for a full list of transaction types with examples.

• See our Transaction Sequencing page for a flow diagram of the steps to complete a transaction.

To test other functionality in your POS integration, you can setup a Site ID in different ways:

• Request a Site ID that can be placed in Demo Mode. This allows for testing of scenarios that are hard to create in the Live Test Host and offers a predictable way to get specific error conditions using test card numbers.

• To test Simplify or integrated payment terminals for Store and Forward (SAF), the Site ID will be placed in Blocking Mode. This is a form of attended testing where the integrator and integration analyst work together during testing and certification. This will result in predictable timeout scenarios.

• Contact gateway.integration@elavon.com to change the Site ID from one mode to another.

All POS integrations are required to perform a server authentication when integrating to Fusebox. This must be done against a trusted certificate authority and a 2048-bit sha2 certificate. Production and ETE URLs and certificates are unique.

Step 4: Certification

A full integration review and certification is required if any of the following items are true:

  • You are a new customer integrating to the Elavon Gateway application.
  • You are an existing customer and your application has any of the following:
    • An exception from a previous certification.
    • Have added Gift Card, PIN Debit, Check, Private Label, International Processor, or EMV.
    • Certified to a Terminal Capture Processor and it is now supporting a Host Capture processor (or vice-versa).
    • Certification is older than 3 years.
    • Major changes that affect payment processing.
    • Elavon has received reports of a significant issue with your POS application.
    • Your application is going to add support for SAFE-T Suite, Token Vault, Unique ID, or Point-to-Point Encryption (P2PE).

An existing customer is allowed to do a partial integration review in the following situations:

  • Adding a new industry to an existing integration.
  • Certified on an operating system platform and is now going to a new operating system platform.
  • Has been certified to use the Elavon Gateway application and would now like to use features such as API based settlement, automated settlement, partial authorization approval, full authorization reversal, or account verification transaction.

Elavon Gateway certification standards are designed to ensure that your POS application, as tested, provides the flexibility and functionality to handle the payment processing needs required for the industry for which you are being certified. You will work with your Solution Engineer and Certification Analyst to complete the certification requirements and obtain a certification letter which authorizes you to transact with Fusebox in the production environment.

Certification should not be considered a guarantee that a customer transaction at a third-party processor will meet all compliance criteria. Compliance can only be validated by a TPP that reviews live transactions end to end, allowing time for the transactions to be processed through the entire processing cycle.

The Fusebox Certification Process includes:

  • Discovery Call
    • Call between customer team, integration analyst, solutions engineer and client executive.
    • Review of the solution Statement/Statement of work/Exhibit A.
    • Confirmation of Work/Exhibit A and confirmation of project scope and goals.
    • Discuss applcation logic and transaction flow.
  • Preliminary Testing
    • Customer provides logs of basic transaction styles relative to their industry.
    • Retail integration would provide an example of a Sale (02) transaction.
    • Customer must perform satisfactory transactions for their applicable vertical(s) or industry(ies) before project can progress to proper certification test scenarios.
  • Certification Testing
    • Performed by the customer.
      • Customer and development staff test the payment application(s) by using Elavon testing scenarios (scripts), which are segmented by industry, i.e., Retail, MOTO/eCommerce, Restauration
      • Customer captures log files of their input messages to Fusebox/Device. Reponses they get back are archived and sent to the integration analyst for review and feedback.
        • Each set of input/response files is referred to as a “wave”.
    • Customer and Analyst continue going through these waves untill all requirements are met (withstanding any exceptions/observation items)
    • When status of input messages is considered ready to be certified, the integrator will coordinate with another member of the Analyst team to do a Peer Review.
  • Peer Review
    • Elavon Internal Process
      • Peer Review is performed by another team member who double checks the work that has been done before the primary integrator can issue the certification letter which serves as verification of the work that has been done and to ensure that nothing has been overlooked.
      • A full run of all applicable test scenarios is included in this review.
  • Certification Letter issuance
    • The certification letter documents the scope of the integration certification andexceptions. In addition to the certification items the integrator may also include his/her observations to enable any inaccuracies the customer application may have before going to market.
    • Customer signs the PCI/PADSS Verification form. Signing of this form ensures that the customer has either done a self-assessment or utilized a 3rd party to audit their payment application.
    • Both the certification letter and the PCI/PADSS verification form must be countersigned and submitted to the integrator before any application can be certified to Fusebox.
    • No boarding processes an be initiated without these two documents being finished.

Next Steps

  • See our Transaction Sequencing page for a flow diagram of the steps to complete a transaction.

  • The API Message Format page describes the field format for requests and responses.

  • The Settlements pages discuss how to settle batches and generate reports to verify your transactions.