Fusebox automatically batches all transactions at a Site ID level (Chain, Location, and Terminal).
Batches can be configured by either Auto Close or Force Close.
Auto Close: Fusebox closes existing batches by Site ID, at a specified time each day.
Site Setup as Auto Close: The first transaction performed after the Auto Close time will be the last transaction of that Auto Closed batch. As the batch is now closed, the POS/PMS will not be able to void the transaction.
Force Close: Either the POS will send an API-based batch close message to Fusebox, or the user will log in to the user interface to close a batch.
Fusebox automatically creates a batch with all financial transactions sent from the POS and will accrue them into batches by Site ID. If a batch remains open for 7 days, it will automatically close in Fusebox.
To settle from the Elavon Gateway User Interface, log in to the User Interface and ensure the amounts about to be settled have been reconciled in the previous steps.
Ensure the user has proper access rights and permissions to log in to process a settlement.
Fusebox maintains POS batch types and virtual terminal batch types for each Site ID.
Point-of-sale batches are transactions received through the Elavon Gateway Message API to Fusebox.
Virtual Terminal Batches
Virtual terminal batches are reserved for transactions through the Fusebox Transaction and Batch Management user interface. POS batch transactions that are updated through BMUI are not included in a virtual batch.
Settings for batch type, close time, and release by Web are the same by default, unless otherwise specified by the merchant at installation. A virtual terminal batch can be configured as auto close or force close, but if there is not an available API to close a virtual terminal batch, it must be closed by a user logging into the user interface if set to force close.
POS Release by Web Flag Yes/No
The merchant can log into BMUI and determine if an additional step is required after the Batch Close process (either Auto Close or Force Close).
If set to Yes: Log in to the Fusebox application interface and release the batch from a pending status to a settled status.
If set to No: Closed batches are immediately queued for the next Fusebox settlement processing job.
A batch goes through several different stages before the deposit is complete. Each batch stage is described below.
No Batch: No transactions have been performed since the last batch was closed.
Open: Batch is open and still accepting new transactions.
Settled: State in which batch pre-processing is still in progress by the Elavon Gateway or the merchant is configured for a two-part batch close and release from web (user interface).
Suspend: The Elavon Gateway has discovered an issue with the batch and will resolve it shortly or will contact the POS integrator or merchant to determine what needs to happen to resolve the issue.
Confirmed: The batch has been confirmed. This does not mean that the funds have been deposited into the merchant bank account. It does mean the TPP has the information and will start that process.
All settlements are subject to duplicate checking during the settlement process. Duplicate Transaction Scanning is a system configuration option and is currently set for 30 days using the Site ID mapped from the Chain Code, Location, PAN, Reference Number, and Terminal ID.
Transactions that fall into these criteria will not be presented to the processor for funding, and result in a Fusebox batch placed in a suspense status and processed as an exemption item.
Settlements are aggregated into multi-merchant batches for transfer to the TPP. The aggregated batch is transmitted the next business day at the TPP. Check batch status the next business day.
Fusebox does not automatically generate user settlement reports. Reports are done manually through the Batch Management User Interface (BMUI) or the Reporting User Interface.
Fusebox settlement includes POS Batch Type and POS Release by Web.
Transactions that have been sent to Fusebox from a POS integration are aggregated in a POS batch, and transactions edited through the BMUI are included in the POS batch.
New transactions entered through the BMUI are in a virtual batch and are aggregated in a separate total and batch settlement process.