Elavon: Send ssl_transaction_currency if not USD

[gcatlin]

Elavon returns an error for any API request that includes a currency
UNLESS the merchant's terminal is setup for multi-currency. Previously
we NEVER sent the currency, so only the default currency worked. Now, we
only send the ssl_transaction_currency field if the currency is not
the default currency (USD).

Elavon Multi-Currency Conversion (MCC) documentation:
https://developer.elavon.com/#/api/eb6e9106-0172-4305-bc5a-b3ebe832f823.rcosoomi/documents?converge-integration-guide/book/processing_options/../../book/processing_options/mcc.html

ECS-272

Closes #3201

Unit:
29 tests, 141 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed

Remote:
24 tests, 105 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed

[gcatlin]

Concerns / Questions

• There should probably be tests added to this PR. I'm sorry I didn't get that far, but I ran out of time.
• The credentials in fixtures.yml are bad. I found new creds in the Elavon dev portal, but there are 2 different sets of creds: one that support multi-currency and one that does not. Which of these (or both?) should be added to fixtures.yml?
  • My concern is that the Elavon API behaves differently depending on whether multi-currency is enabled.
  • UPDATE: I decided to add the multi-currency enabled dev portal credentials and remove the old / broken credentials
• Some gateways include a list of supported currencies. Should valid currencies be added to the Elavon gateway? They provide a list:

  • The alphanumeric code that must be included in the request to indicate the currency in which you wish to process. If omitted, the terminal default currency is assumed (for example: USD, CAD, and JPY).
  • More than 94 currencies are supported. Refer to the ISO Currency Codes section for an extensive list of available currencies.

  • I'm also concerned that the default currency is set per-terminal, so the assumption of USD may be a bad idea.
  • Also, the list of ISO Currency Codes contains more that 94 entries, so hard-coding the supported currencies may be asking for trouble.
• From the Elavon Multi-Currency Conversion documentation:

  • Once a terminal is setup for Multi-Currency, the terminal can process by default the following currencies: US Dollar (USD), Canadian Dollar (CAD), Pound Sterling (GBP), Australian Dollar (AUD), Euro (EUR) and Japanese (YEN). You can add or remove currencies in the Converge user interface.
  • Multi-Currency is supported with MasterCard and Visa transactions only. Other card types cannot be sent with a transaction other than merchant currency: USD or CAD.

  • The complexities underlying those bullet points have not been captured in the pull request, but perhaps should?
• The following also have not been accounted for, but perhaps AM handles this automatically? (From Elavon Multi-Currency Conversion documentation):

  • When specifying amounts, be sure to submit the correct number of decimal places for the transaction currency. All currencies support two exponents (decimals,) other than the following: ...
  • For Japanese Yen, there are no currency exponents after the decimal place. Any numbers included after the decimal place will be ignored.
  • For the Bahraini Dinar, there are 3 possible digits after the decimal place. Your website may wish to take advantage of the precision this audience of customers will expect. However, currently the Converge will accommodate only 2 decimals. If you submit three, it will automatically round your transaction to two decimals. (for example: 1.235 will round to 1.23 and 1.236 will round to 1.24).

• At one point, I added support for a boolean option key, multi_currency_terminal?, and only sent the currency if the option was true, would that be a better way to approach this? Where do we document gateway-specific options?
  • I'm concerned the implementation in this PR will cause problems for Elavon AM users that have a default currency that is not USD. The benefit of using an option is that AM users will need to opt-in to the new behavior.

[jknipp]

Revisting this, I think we should send the ssl_transaction_currency GSF if options[:currency_code] is provided and leave the determination of when it should be provided up to the user. The user knows what their Elavon default currency is and if Multi-Currency is enabled, and therefore when to send the non-default currency.

[jknipp]

@activemerchant/spreedly-connect Ready for re-review.

[molbrown]

👍 This is more Active-Merchant-y