API Based Settlement
About Fusebox Batches
API‐based settlement supports pre‐settlement reconciliation and settlement by using two transaction types: Batch Inquiry and Batch Close. A batch settles a group of transactions using the following criteria:
Transaction Types for Settlement
Batch Inquiry (Type 14)
- Confirms the transaction count and amount for a specified Terminal ID, Location Name, or Chain Code.
Batch Close (Type 13)
- Sends transaction details to the Third Party Processor TPP or host for funding.
The settlement process:
Pre‐Settlement Reconciliation: Elavon recommends that you use the Batch Inquiry request to confirm the transaction count and amount totals. Fusebox can then use the Batch Close request to transmit the batch to the TPP or host.
Settlement (Batch Close): During a Batch Close, you may direct Fusebox to settle a batch. The system then sends the batch to the third‐party processor. A successful result (“0000” in Field 1003) or Batch Close message does not indicate that transactions were funded properly or completely. The only way to confirm settlement is through your bank deposits.
Post Settlement Reconciliation: Following are some best practices:
Confirm settlement results as soon as possible, preferably before the next day of business. Resolve any settlement errors before the next scheduled batch close event. Merchants may incur penalty fees if they do not perform settlement within the number of days set by the card associations.
Clearly report and confirm the status of the previous settlement daily.
Reconcile the actual amounts deposited in the account with the reports generated during the Batch Close.
It is advisable to adhere to these same steps when using API-based Settlement. This will prevent duplicate settlements and other potential problems involving the transfer of funds.
A number other than “0000” in Field 1003 indicates and incomplete settlement attempt. If the settlement failed, you should clear the indicator only by a successful manual settlement or an override from an appropriate authority.
You should only attempt API‐based settlement once per business or transaction date for a batch. Further attempts to deposit a failed batch should be initiated from the Batch Management User Interface.
Call the transaction processor help desk if the merchant receives any error response messages or communication errors during settlement. This confirms if they accepted a full or partial transmission.
Settlement Best Practices
If the settlement was unsuccessful, the merchant should call the transaction processor before resubmitting it.
Your application should not settle a batch of transactions more than once to avoid creating duplicate charges on cardholder accounts.
Resettlement procedures must be a manual process and be documented using the Batch Management User Interface. Once settlement has failed, API‐based settlement for that batch is no longer an option.
Value Added Reseller (VARs) Responsibilities
VARs that implement API‐based settlement into their application(s) must supply both training and written documentation for each installation that uses this functionality prior to the merchant initiating the settlement process for the first time.
The merchant must be informed on how to identify settlement failures and be properly trained in the areas of problem identification, escalation, and resolution. This is especially key when related to reconciliation, settlement, and re‐settlement issues.