| Table of Contents |
|---|
Introduction
Rotating transaction gateways allow a merchant to spread credit card transactions across multiple gateways. While available to all UltraCart merchants, it is primarily intended for merchants with substantial transaction volume. Merchants should thoroughly test their configuration before going live with this feature.
...
| Info | ||
|---|---|---|
| ||
The migration tool will set a merchant property called "defaultRefundRtgCode" which will be used to initiate a refund on an order if the order does not have an RTG code assigned to it. So refunds should work against the old migrated gateway. |
Configuring a New Rotating Gateway
Rotating
Rotating Gateway Editor
In this section, you will enter some basic information about this transaction gateway.
Code | Each rotating transaction gateway requires a unique code. It is recommended that you use a code that will allow you to quickly identify either the gateway or merchant account | |||||
|---|---|---|---|---|---|---|
Traffic % | Enter the desired traffic percentage you want this gateway to receive. If there are other restrictions (as discussed below) on this gateway, then UltraCart will resolve those restrictions, then compare the relative percentages across all gateways that qualify to handle the transaction Important Note Regarding Traffic Percentage Configuration
| |||||
Status | Each rotating transaction gateway can be placed in one of three states:
| |||||
Deactivate after X consecutive failures | (Optional) If specified, UltraCart will automatically place this gateway into inactive status if the specified number of consecutive failures are encountered. | |||||
Charges Appears On Statement As | (Optional) If this gateway has a different Charges Appear On Statement message than your store's default, then this value will be used for transactions conducted through this rotating transaction gateway | |||||
Customer Service Email | (Optional) If this gateway has a different Customer Service email address than your store's default, then this value will be used for transactions conducted through this rotating transaction gateway | |||||
Customer Service Phone | (Optional) If this gateway has a different Customer Service phone number than your store's default, then this value will be used for transactions conducted through this rotating transaction gateway | |||||
If Charge Declines Try Other RTG | (Optional) If selected, then during a checkout, if the initial transaction is declined, attempt the next credit card authorization against the configured rotating gateway. | |||||
| Rebill Auto Order against RTG | (Optional) If set, any auto orders originally process with this gateway will have its rebills processed with the selected gateway. | |||||
| Require CVV2 | (Optional) This force the gateway to require the CVV2. Setting this will mean that auto orders would not be processed with this gateway. | |||||
| Preferred for Auto Orders | (Optional) When checked, this gateway will be preferred over others is the transaction is related to an auto order. This can be used to shift traffic towards gateways that have card updating services. |
...
New Feature - -
If you configure the batch cut-off time for this gateway, partial refunds that occur before the batch has closed out will be queued for processing 12 hours after the batch has closed.
NOTE: 24 hour format, based on EST
Monthly Restrictions
Daily Restrictions
...
International Percentage Restriction
If your merchant account has strict limits on the amount of international volume that you can process, this restriction allows you to place a percentage cap on the amount of international volume you process.
Storefront Screen Branding Theme Restriction
...
Q: We presently have the checkout setting to capture the order after 3 failed attempts, however we just had an order go into A/R that ended up with 6 transaction, why did it contain 3 extra declines?
A: The three overall attempts going into the "rotating gateway" are what will appear in the orders transaction history, when reviewing the order. If you have cascade on decline configured, you can end up with six actual attempts. The higher level code that manages the three attempt counter before capture of order to A/R, does not include the subsequent cascade attempts. However, the cascaded transaction attempt does get stored in the order transaction history. The secondary attempt happens inside of the rotating gateway itself.
Which transactions get recorded into the review order transaction history:
...
Q: We have two active gateways, we have configured then each with 100% traffic, what will happen in this situation?
A: The total traffic percentage among all configured gateways should in most cases equal 100%. However, UltraCart will normalize the sum of the traffic percentages for the RTGs being considered based upon all the other restrictions that can be applied. So in the scenario where two active gateways are configured with 100%, and both are valid gateways and no other restrictions are configured on the RTG, Ultracart normalizes to 50/50 traffic percentage between the two gateways.