Configuring Verifi Gateway

To configure Verifi Gateway into your Lime Light CRM, you will go to Payment Systems>Gateway Providers and select Verifi in your Gateway Accounts drop down menu. Click on “Add Gateway” and fill out the gateway parameters.

These parameters are briefly described here for your reference:

Username: Same username that you have set up for your account with Verifi.

Password: Same password that you have set up for your account with Verifi.

Currency: Verifi currently supports USD, EUR, GBP, CAD,  AUD, and SEK currencies. You can select one currency per gateway account.

MDF1- MDF20: Merchant Defined Fields are described below. These are optional fields.

Use Pre-Auth Filter: Set to YES only if using the Pre-Auth Filter* service through this gateway account.

Void Pre-Auth: Set to YES if you want to void a successful Pre-Auth immediately; set to NO if you want to hold a successful Pre-Auth and capture it at the rebill charge.

Use Decline Salvage: This is an additional service that you can activate with Verifi.

Post Processor ID: Set to YES only if you will be doing Load Balance with Sticky Processing* through this gateway account.

Gateway Alias: name that you will assign to the gateway. This is for internal purposes only; it helps you identify a specific gateway account among several of them in your CRM.




* Optional Services:

Load Balance with Sticky Processing: This service will be available if you are doing any type of Load Balance within the gateway account. It allows you to process all your recurring orders through the exact same processor that processed the initial transaction for each one of your customers; therefore, you will be using the same processor for the lifetime of your customer subscription.

When you use this service, you must enable one more field within the gateway account. In order to enable this field, you will login to your gateway account, go to Options>API Configuration, select the customized variables returned in your API responses as shown below, from the list on the left side select “Processor ID” to be added as one of the fields returned, and click Save:

processor id.png



Merchant Defined Fields:

Verifi contains several Merchant Defined Fields (MDF1-MDF20) that allow you to customize the transactions that you will be processing through their gateway. These MDFs will append certain information to these transactions based on the order details. Please be aware that these fields are optional.

To ease the process of using the MDFs, at Lime Light CRM we have created various Tokens that you can use to dynamically insert certain values into these Merchant Defined Fields depending on what values you want to send over to Verifi.

These are the tokens* you can use and a brief description of the values that each one will insert in your MDF:


Passes to the gateway the date of the original parent order on rebills in MM/DD/YYYY format.



Inserts the affiliate id from the order. It will obtain this value from the AFFID, AFID or AID field, whichever is populated; if none of them have data, it will not include it on the post.



Inserts the campaign description of the campaign from where the order is generated.



Inserts the campaign id from where the order is generated.



Inserts the category name that the main product sold belongs to.



This is populated with the coupon discount on the order, i.e. `1.00.



Provides the customer id of the order being billed.  Please be aware that this is only valid on rebills; on new initial orders, the customer id will be 0 because a new customer will not have a customer id until after he has a successful order in your system.



Inserts the id of the gateway used to process the order.



This will return the transaction id for the initial order.



Inserts the product id of the main product sold.



Inserts the product name of the main product sold.



Inserts the product SKU number of the main product sold.



This will insert the current rebill depth of the order. For example, if the order is the first rebill for a customer, this would be 1, if it was the second rebill, it would be 2, and so on. For initial new orders, this will be 0. 



This is populated with the current reprocessing attempt for the order, which will be populated with `0` if the order is not being reprocessed.



Inserts what retry count the order is at. For example, if a rebill has declined two times, then this would be 3, meaning it is the third attempt to get an approval.



Inserts the shipping id of the order.



Inserts the shipping method of the order.



Inserts the sub affiliate id. It will post all the sub id's based on the affiliate id of that order. For example, for AFFID, it will post the value of C1, C2 and C3 as a concatenated string separated by commas: C1value,C2value,C3value  For AFID and AID it will just be the value of SID or OPT respectively.



Passes a session Id to the gateway.  In order to set the value received from Threat Matrix after they give you a session ID on the webforms,  use a javascript to set the value of a hidden Lime Light field that is in the HTML form on your credit card payment page.

document.getElementById("thm_session_id").value = threatMatrixID;

To use with our API, submit the value that Threat Matrix responds back in an example like this where the threat matrix session id is 12345:


  • The {THM_SESSION_ID}  token can only be used in the MDF17 field.



*These tokens can be placed in any of the 20 Merchant Defined Fields.  For an explanation of what each MDF is actually used for, please look at your gateway API documentation, as this will vary per gateway.

Once your gateway profile has been created, then you will go through your campaigns and assign the gateway to the corresponding campaign(s).


 Additional Services that you can enable with Verifi:

Verifi’s Decline Salvage Service


All Merchants who accept credit card transactions experience declines during their attempt to charge the consumer for the goods/services they are delivering. Merchants with a recurring billing or installment payment business model are particularly sensitive to declines, as their business model is dependent upon receiving the recurring payments for goods or services provided to the consumer beyond the initial or trial billing period.


As most Merchants attempt to recover funds from a declined transaction, significant additional costs are incurred by the Merchant through manual reviews of account information by the merchant's staff who in some cases take various measures to contact the consumer to secure payment for services rendered.


Verifi recognized the challenges and costs that merchants encounter when attempting to collect payment on recurring charges. In response to this challenge, Verifi developed the Decline Salvage service which enables merchants to identify those consumers who are due payment for services provided, but the merchant has been unable to successfully charge the consumer on the originally scheduled billing date. Verifi's Decline Salvage service analyzes a client's declined credit card transactions and uses proprietary logic and processes to resubmit the previously declined transactions in an attempt to receive an approval.


The Decline Salvage is not necessarily meant to replace a merchant’s existing decline recycling procedures, rather Decline Salvage is intended to augment that logic and offer the merchant with another tool to capture and retain recurring customers.

Lime Light CRM & Verifi have made the entire process easy and automated between both of our platforms. Verifi’s Decline Salvage will only be used once Lime Light CRM has exhausted all resources to reattempt and successfully charge your customers. Not all transactions will be eligible for Verifi’s Decline Salvage program. Only transactions that follow the criteria below will be submitted to Verifi.

  1. At time of purchase the consumer agreed to the Merchant’s terms and conditions outlining the recurring or installment payment plan.
  2. Transactions where the initial authorization decline that is being submitted for salvage occurred 30 days or less from the salvage batch submission date.
  3. The consumer has not contacted the Merchant to cancel or discontinue the billing agreement. The consumer is still active and eligible for payment.
  4. Any prior authorization attempts to bill the consumer resulted in Soft Decline response codes.
  5. Transaction requests are not missing any cardholder information. Transactions that previously received declines due to missing/invalid fields should be corrected to include the required data before being resubmitted. Example, "The City field is required".
  6. Recurring billing transactions after the initial trial (LOC 1+) are eligible. A failed initial trial sign-up (LOC 0) or failed one-time charge (LOC -1) is not eligible for decline salvage.

For example, if customer A has signed up for a service or product which bills them once a month and in the third month of the service, the charge for their standing monthly bill is declined for insufficient funds, that transaction would be an excellent candidate for a decline salvage attempt. Assuming the customer has not contacted the merchant to cancel their service, the merchant is permitted to re-attempt that charge and continue to provide the customer with the service or product they have signed up for thereby saving the monthly revenue and also retaining the customer for future charges until the time that the customer cancels their subscription.


Not all declined transactions are eligible for decline salvage. Some transactions, based on their decline response (such as “lost/stolen”) should not be reattempted. Likewise, transactions from more than 30 days ago which were declined with a “soft” decline reason (do not honor, insufficient funds etc) may be successfully charged but carry a significantly higher risk of a subsequent chargeback or refund. These “soft” declines may be submitted for Decline Salvage processing at the Merchant’s discretion.


Configuring Verifi’s Decline Salvage

  • You will setup the decline salvage by editing your existing Verifi Gateway platform configuration
  •   You will simply say YES to the "Use Decline Salvage?" question, and configure your username and password:


  • Upon retrying and giving up on any declined orders, we will pass over the records to Verifi nightly
  • When Verifi runs a batch and puts out a new response file onto the FTP server, Lime Light CRM will look for new files at noon each day and will subsequently denote any failed or successful salvages on the original parent order Id.



Example of Successful Orders:

Upon success it logs both on the parent and child orders of the newly created and captured order Id:



From the parent order, and newly successful salvaged order, an order history record is logged and is linked to the child order. The following is a view from the original order; as you can see it ran through 4 times before it gave up and transfered the file to verifi servers.  It logs the transfer action and you will end up seeing a success or decline approximately two weeks later:



Example of Decline orders:

When Verifi is unable to salvage the decline it returns a response to Lime Light CRM with the reason why and we link that declined child order to the parent with the details.

This example shows a soft/hard decline where Verifi also gives up and cannot salvage the decline:



This example shows when there is an error and Verifi cannot salvage as well:



Additional Verifi Gateway Notes

If a subscription rebill attempt fails for one of the reasons listed below, the subscription will not proceed through decline salvage. Instead, the subscription order will be placed on an immediate hold.  

250 Pick up card
251 Lost card
252 Stolen card
253 Fraudulent card

Have more questions? Submit a request


Article is closed for comments.