Integration Best Practices

The scope of this list is limited to the Certification Department suggested best practices for submitting or handling transaction data.

  1. Point of Sale (POS) time out settings -- Allow for at least 30 seconds from the time the transaction leaves the last point in your internal network until it reaches Elavon and Elavon's response makes the round trip back to your processing application.  

  2. Echo Timing -- An "echo" is an acknowledgement that an approval response was received. If the transaction type requires an echo, no more than 12 seconds can elapse from the time the authorization leaves Elavon and reaches the POS and the echo is returned from the POS to Elavon. You have no more than 8 seconds from the receipt of the approval to generation of the echo in order to stay within the 12-second limit.  

  3. Transactions "In Flight" -- Only one transaction per Terminal ID (TID) can be "in flight" between your POS and Elavon at any given time. The next transaction cannot leave your POS until the first transaction has made the round trip to Elavon and back. If a single TID is in use, queuing of multiple transactions must take place. The best practice is that if you need to have multiple transactions "in flight" at the same time, multiple TIDs must be in use. Options do exist to accommodate multiple transactions "in flight" with a single TID. Contact your Elavon representative to discuss those available options if desired.  

  4. Track Data -- Use Track 2 for submitting track data to Elavon for both PIN Debit and Credit Card transactions. This helps minimize any possible issues with Signature Debit transactions because the card issuer may decline transactions when Track 1 is used.  

  5. AVS Data -- It is recommended that you program your POS to require Address Verification Service (AVS) data when a card number is key-entered because this can impact interchange qualification costs. At minimum, the cardholder's billing ZIP code or postal code should be required for submission as part of the authorization request.  

  6. CVV2 Data -- It is recommended that you program your POS to require CVV2 data when a card number is key-entered because this can impact disputed transaction resolution options.  

  7. Sales Tax -- It is recommended that if Sales Tax amount is a known value (use $0.00 for tax exempt), program your POS system to send that tax amount with every transaction. This can impact interchange qualification costs.  

  8. Invoice Number -- For Card Not Present (mail order and telephone order -- MOTO) transactions, the inclusion of an Invoice Number (also referred to as Order number) is required. When practical, it is recommended that a merchant or POS defined Invoice/Order Number be included on all transactions (including swiped and keyed, card present) as a logical method, beyond the card number value, to trace the transaction life cycle.  

  9. Settlements -- Insure that all processing batches are settled in a timely manner. Whether using an automated system or a manual process for settlement, the best practice is to insure that completed batches settle each day -- 7 days per week, 365 days per year, if appropriate. This includes the merchant verifying that what was actually settled matches what their records reflect as being processed.  

  10. System Reviews -- It is recommended that you do a POS system review at least twice a year when card association and debit network rules and regulations change to ensure that your system complies with all current rules and regulations.