Online Debit Transactions
For online debit, performing the Sale and Return transactions causes Fusebox to send data immediately to the host for processing. Depending on the processor and the method that they use to capture online debit transactions (Host vs. Terminal Capture), these transactions may or may not need to be settled.
|Sale (Type 02)||Attempts to authorize the transaction and, if approved, will decrease the cardholder’s available balance. The customer must enter a PIN for the transaction to be processed. Also, the Transaction Qualifier (API Field 0115) must be included in the input request with a value of 030 (debit). This is the primary transaction used for online debit card purchases. Merchants are required to support this transaction.|
|Return (Type 09)||Generates a refund on a customer’s debit card. To indicate the transaction is an Online Debit Return, the Transaction Qualifier (API Field 0115) must be included in the input request with a value of 030 (debit).|
While your application should be able to support this transaction type, not all merchants (through their processing agreements) or processors will support it. Refer to your TPP to ensure that the merchant’s processor supports this transaction type.
Transaction Inquiry (Tran Type 22)
Use this to make inquires about the status of a transaction in the Fusebox database. This is used when an error occurs that prevents your POS application from receiving or processing the Output Response data, typically after a POS timeout.
Fusebox searches its database for the Reference Number (API Field 0007), Account Number (API Field 0003), and Transaction Amount (API Field 0002) provided in the original Input Request. If the record is found, a duplicate of the original Output Response is returned.
Elavon requires that your POS application support the Transaction Inquiry transaction.
Fusebox requires that the Debit Working Key (Field 1007) be passed in all Debit Sale (Tran Type 02) and Debit Return (Tran Type 09) input requests.
Working Key Exchange (Tan Type 77)
Transaction requests between the POS PIN pad and the processor requesting a new working key. Specific to FDMS/TeleMoney sets 73 and 101.
If a new working key is requested, the new key should be stored in the POS application, used in the calculation of the PIN block and presented in API Field 1007 for all subsequent debit transactions.
Your POS application must be able to identify how the transaction is to be processed. If the customer selects the online debit payment type option, the following requirements must be met:
• The debit card must be swiped and Track II data presented.
• No manual entries are permitted.
• The customer enters their PIN and a PIN block must be calculated and passed in an API.
• Open BIN ranges apply.
• No standard card validation (MOD‐10 checking) or card length routines apply.
• A unique terminal is called for each PIN pad/POS entry point (if applicable).
Merchants in the restaurant, lodging, auto rental, and direct market/MOTO industries typically use a two‐part transaction to authorize a card for an estimated cost of services to complete the transaction once the actual charge amount is known.
Most processors only support Sale (debit the cardholder’s account) and Return (credit the cardholder’s account) transactions. Pre‐authorizations, completions (prior‐auths), and voids are not supported.
Online debit transactions affect the cardholder’s account in real-time and cannot be used to “verify” funds are available.
Settlement and Reconciliation
The merchant/end user will not receive their settlement funding unless a settlement record is submitted to the transaction processor. Typically, the funding timeframe is no more than three (3) calendar days from the day the transactions were settled (transmitted to the processor for settlement).
In addition, POS online debit transactions may have to be settled under a separate merchant and/or terminal ID issued by the POS online debit processor than what might be used for other electronic tenders (Visa, MasterCard, American Express, etc.).
If you are settling based on criteria such as MKey or Card Type, transactions may need to be modified slightly for the new card type (Debit) or additional MKeys.
We strongly recommend that your application requires some type of pre‐settlement process.