Litle: Update tests #3618
Comments
leila-alderman
added a commit
that referenced
this issue
Aug 12, 2020
ACH transactions in which the `checkNum` was `nil` were previously sending an empty `checkNum` node, which caused failures against the Litle gateway. This adds a check so that the `checkNum` node is created only when there is a value for this field. ECS-1350 Unit: 46 tests, 201 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 43 tests, 188 assertions, 13 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 69.7674% passed Many remote tests are currently failing [due to previously noted changes to the gateway's responses](#3618). All unit tests: 4544 tests, 72251 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
leamarty
pushed a commit
to MONEI/active_merchant
that referenced
this issue
Nov 2, 2020
* Fix broken refund response when force_full_refund_if_unsettled is true (#3609) For Worldpay this time. Turns out this gateway had the exact same problem I fixed in 284dcdd7af1f7764c4ddda1f1ab48369aae0673e for Braintree. Previously, if the `force_full_refund_if_unsettled` option was set to true, and the refund failed for any reason other than the one that triggered the `#void` call, the `#refund` method would return nothing at all, which is bad, because the caller would never know why their request failed. * iATS Payments: Add support for Customer Code payment method iats_payments gateway has had support for store, but not using stored payment methods. Adds ability to purchase with a CustomerCode. Unit: 18 tests, 178 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 13 tests, 56 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed ECS-1177 * HPS: Add Google Pay support Unit: 52 tests, 259 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 50 tests, 132 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed EVS-461 * Send a specific card brand commerceIndicator for 3DS Cybersource reached out to us and mentionned that we should be using some specific values for commerceIndicator, not the raw eci. * Send application_id as partnerSolutionID Since Cybersource uses partnerSolutionID to understand from which partner the requets originates, it makes sense to use application_id. * Adyen: Correctly parse error messages for 3DS2 auths When 3DS2 fails, Adyen will return an error under refusalReason. Previously, we were checking for this value with the `authorise` and the `authorise3d` endpoints, but not for `authorise3ds2`. Updates message_from to properly check for the refusal reason when present for 3DS2 txns. Unit: 66 tests, 315 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 89 tests, 343 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Bump to 1.107.2 * Set partnerSolutionID in the business rules body, not the top level enveloppe body * Ignore IPv6 unsupported addresses (#3622) closes https://github.com/activemerchant/active_merchant/issues/3569 * Bump to v1.107.3 * Elavon: Implement true verify action Previously, the `verify` action for the Elavon gateway was implemented as a $1 authorization followed by a void action. This change implements a true verify action using the `ccverify` action. This update means that customers will no longer see potentially confusing holds on their accounts. CE-553 Unit: 32 tests, 153 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 27 tests, 119 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4471 tests, 71666 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications 100% passed * Vantiv Express: Implement true verify Previously, the Vantiv Express gateway (formerly called Element) used a $1 authorize followed by a void to approximate a verify action. This change implements a true verify action for Vantiv Express that does not require placing a hold on customer accounts. See [the documentation for this verify action](https://developer.vantiv.com/docs/DOC-1067). In addition, this commit includes a few scattered RuboCop corrections. CE-556 Unit: 17 tests, 47 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 19 tests, 51 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4489 tests, 71758 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications 100% passed * Litle: pass expiration data for basis payment method * Fix Style/DoubleNegation linting error Fixes a Style/DoubleNegation linting error was introduced in the Realex gateway by changing the statement to `!statement.nil?` from `!!statement`. 4493 tests, 71886 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 692 files inspected, no offenses detected * Stripe Payment Intents: Handle errors in refund process The Stripe PI refund method first makes an API call to check for the associated charge id of the payment intent to be refunded. If this payment intent does not have an associated charge, or if there is some sort of error (whether service availability, etc), subsequent steps in the refund process will raise errors due to the way we try to parse out the charge id. This PR updates refund to check for any errors resulting from the initial get request. If there are any, we stop the process and simply return a failed response with that error. Next we try to parse out the charge id from the response. If it's nil, we again simply send back a failed response with appropriate message and halt processing. Otherwise, we use that charge_id to call the stripe refund method as before. This PR also incorporates updates from PR #3352, to make refund backwards compatible if you pass in a charge id rather than an intent id. Remote: 38 tests, 181 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 12 tests, 72 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Stripe Payment Intents: Update changelog for #3627 * HPS: Prevent NoMethodError when account_type or account_holder_type nil For check payment methods, the HPS adapter attempts to upcase the account_type and account_holder_type fields when adding them to the request. If either of these is missing, a NoMethodError is raised. This PR makes an update to safely call upcase in these instances to prevent such errors. Remote (same failures on master): 50 tests, 125 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 90% passed Unit: 54 tests, 267 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * D Local: Handle invalid country code errors Implemented handling similar to other gateways. Closes #3626 Unit: 18 tests, 71 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 27 tests, 71 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * CyberSource: Add error details response fields When an invalid/missing field is supplied, active merchant provides details describing exactly what field is invalid/missing, if available, for the CyberSource gateway CE-193, CE-589 Unit: 81 tests, 367 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 78 tests, 395 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 93.5897% passed Closes #3629 * Stripe Payment Intents: Utilize execute_threed flag to determine success Currently Stripe Payment Intents will return a successful response if a user tries to initiate a purchase or auth and the api responds with a status of `required_action` (i.e. if additional steps are required to authenticate with 3ds and proceed with the transaction). In other adapters that implement 3DS, we use an `execute_threed` flag to either signify that we should hit a 3DS specific endpoint, or classify a response as success/failure depending on whether or not 3DS was requested. For Stripe, there's no separate 3DS endpoint; rather, if a transaction requires 3DS the response will just signify that in the status field and by having redirect urls. This PR updates to use the presence of an `execute_threed` option to either classify the response as a failure should that field not be present and authentication was required, or default to the normal success determination Questions: This will have potential impacts on backwards compatibility. Would it be better to have a flag specifically saying you do not want to request 3DS instead of the normal execute_threed flag. That would go against all other implementations though... Remote: 37 tests, 177 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 10 tests, 61 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Elavon: Add Level 3 fields Adds support for Level 2 and Level 3 fields for the Elavon gateway. CE-543 Unit: 33 tests, 192 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 28 tests, 123 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4499 tests, 71947 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * CyberSource: Stored Credential fixes The initial implementation of Stored Credentials had some discrepancies with CyberSource's API documentation. This change adds the subsequentAuthStoredCredential field to appropriate transactions, and corrects some behavior around the other fields. Tests were changed significantly to verify the new behavior. Docs used to guide the logic are here: https://developer.cybersource.com/library/documentation/sbc/credit_cards/html/Topics/Merchant-Initiated_Transactions_MITs_and_Credentials-on-File_COF_Transactions.htm Currently, "Industry Practice" designations are not supported. Closes #3624 Remote (5 known unrelated failures): 79 tests, 399 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 93.6709% passed Unit (2 unrelated failures): 81 tests, 367 assertions, 2 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 97.5309% passed * CyberSource: Fix invalid and missing field tests These tests were failing due to checking request instead of response. Closes #3634 Unit: 82 tests, 385 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * CyberSource: Pass stored credentials with purchase And fixes a couple rubocop violations Closes #3636 Unit: 83 tests, 393 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote (5 known unrelated failures): 80 tests, 403 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 93.75% passed * Mercado Pago: Add payment_method_option_id field CE-562, CE-593 Unit: 37 tests, 171 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 31 tests, 81 assertions, 7 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 77.4194% passed All Unit Tests: 4503 tests, 71981 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Stripe: Provide error when attempting an authorize with ACH Currently, the Stripe adapter can be used to attempt an authorize with a check object. However, this causes an application error, because if you pass a check directly in an authorize, we don't try to tokenize it in any way before processing, so it errors out with a NoMethodError (we're trying to process it as though it's a credit card, and in this case, there's no `month` method on the check, causing an error). Additionally, ACH simply does not seem to be supported by Stripe for revenue transfers where funds aren't captured - after storing a check as you'd have to do for a purchase, you'll end up with an error related to capture being false if you attempt the auth. This PR updates the logic in authorize to check if the payment method is a check before processing the auth, and if so, we return an error the way we do for purchases when the check has not been previously stored. Also adds a test showing that auths fail anyway if attempted using a stored check, but don't result in any unexpected application errors. Further reading: https://stripe.com/docs/ach Unit: 138 tests, 738 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 71 tests, 325 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * EBANX: Send original order id as merchant_payment_code metadata Unit: 17 tests, 59 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 24 tests, 67 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4503 tests, 71977 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications 100% passed Closes #3637 * Element: Add card_present_code field CE-376, CE-584 Remote: 20 tests, 53 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 18 tests, 49 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Set a default collectionIndicator For mastercard cards, we need to always be passing a collectionIndicator for the request to succeed. I decided to use `2` as the default collectionIndicator, as it was already the one used for tokenized card and it seems to match our usecase from all the pther choices: - 0: UCAF collection is not supported at your web site. - 1: UCAF collection is supported at your web site, and the UCAF was populated. - 2: UCAF collection is supported at your web site and the UCAF was populated. This value indicates a successful Mastercard Identity Check transaction. - 5: UCAF collection is supported at your web site, and the UCAF was populated based on the risk assessment that the issuer performed. This value is supported only for Masterpass transactions. - 6: UCAF collection is supported at your web site, and the UCAF was populated based on the risk assessment that you performed. This value is supported only for Masterpass transactions. * Orbital: Add support for Level 3 fields Adds support for Level 3 fields to the Orbital gateway, including support for sending an array of line item details. CE-560 Unit: 93 tests, 553 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 35 tests, 190 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4505 tests, 72007 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Firstdata: Strip newline characters from address Implement change to formatting of VerificationStr1 to strip out \r and \n characters from address components. This is to conform with tighter verification on VerificationStr1 value introduced by FirstData in May 2020. Unit tests: 33 tests, 160 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4508 tests, 72015 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote tests: currently lacking valid gateway test credentials, so the remote tests are currently all failing Closes #3643 * Forte: Add sec_code attribute for echeck Allows passing in the sec_code attribute and defaults to WEB if one is not provided See https://www.forte.net/devdocs/api_resources/forte_api_v2.htm#echeck The attribute has been made required in the sandbox in advance of requiring it in production later this year. Fixes: #3612 Unit: 20 tests, 67 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 22 tests, 63 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Closes #3640 * Explicitly require "extract_options" from Braintree Blue Since this commit in Rails https://github.com/rails/rails/commit/d9539281bd6c314786b9f05ff6cba1d89509b174, `extract_options` is no longer required automatically, since this class uses it, lets require it. This fixes the tests on Rails master. * Explicitly require `active_support/core_ext/kernel/singleton_class` when needed MetricsGlobalTest is using a `class_eval` which requires the `singleton_class`. * Bump to v1.107.4 * Forte: Change default sec_code value to PPD The sec_code field for echeck transactions was recently added to the Forte gateway in 1c4b10818a780d0c80e4554e0843741193c6584a. After customer issues and digging into Forte value definitions, it has become clear that 'PPD' should be the default value when none is specified. Forte currently assigns PPD to a transaction where no sec_code is specified, so we should follow that pattern here. Forte will soon be requiring a sec_code is sent on any echeck transaction, which is why a default is being set. Remote: 22 tests, 63 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 20 tests, 67 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed CE-532 * Elavon: Add merchant_initiated_unscheduled field Added the gateway specific field `merchant_initiated_unscheduled` to the Elavon gateway to indicate whether a transaction is using a stored credential for a transaction that is not regularly occurring. In addition, fixed up nine RuboCop offenses throughout. CE-620 Unit: 34 tests, 196 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 28 tests, 123 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4509 tests, 72019 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Decidir: Add aggregate data fields Adds the aggregate data and associated nested fields to the Decidir gateway. The aggregate data fields are intended for use by payment aggregators and therefore cannot be tested in remote tests due to our test integration with the gateway. CE-561 Unit: 34 tests, 165 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 21 tests, 74 assertions, 2 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 90.4762% passed All unit tests: 4509 tests, 72037 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed The remote test failures seem to be caused by variances in the responses provided by Decidir. - `test_failed_authorize` - `test_failed_verify` are both returning error messages of "insufficient_amount" instead of the expected "invalid_number" message. * Changelog entry for 0e0f199a2ffd68010e0a543abea2a9cf9060c294 * Vantiv(Element): add option to send terminal id in transactions CE-506 Correct a typo Element(Vantiv): Add ability to add terminal id to transactions Give the option to send through a specific terminal id. Unit: 19 tests, 51 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 21 tests, 55 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Update supported Ruby and Rails versions Updated the supported Ruby and Rails versions included in Travis CI to remove versions that have officially been moved to end of life while still maintaining support for Rails versions 5.0 and 5.1 for now. - Removed Ruby versions 2.3 and 2.4 - Added Ruby versions 2.6 and 2.7 - Removed Rails version 4.2 - Added Rails version 6.0 In addition, several RuboCop changes were made as a result of updating the target Ruby version from 2.3 to 2.5: - a few unneeded `begin` statements were removed - the `=~` operator was replaced with `.match?` where appropriate - a chained method of `.unpack.first` was replaced with `.unpack1` Updating the Ruby version also required a minor update to the So Easy Pay gateway to fix an REXML error. All unit tests: 4510 tests, 72041 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Authorize.net remote tests: 70 tests, 242 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Realex remote tests: 27 tests, 138 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * CI: Drop unused sudo: false Travis directive Travis CI stopped using the `sudo: false` directive in 2018. See [this Travis blog post for reference](https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration). All unit tests: 4511 tests, 72043 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Closes #3616 * Payu Latam: Prevent blank country in billing_address In PayU Latam requests, passing in certain billing_address fields as empty strings (specifically `country`) will result in an error. This PR updates the logic to not pass a billing_address country field that's blank. Remote: 34 tests, 83 assertions, 1 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 97.0588% passed unrelated failure, also on master: `test_well_formed_refund_fails_as_expected` Unit: 32 tests, 122 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * DLocal: Fix address field names DLocal was previously only passing state and country in the billing address due to checking for incorrect address fields. DLocal also separates number and street fields, so adds address parser for address1. DLocal address fields are optional, except in India: https://docs.dlocal.com/api-documentation/payins-api-reference/payments#the-address-object Unit: 21 tests, 87 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 28 tests, 73 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed ECS-1267 * [Cybersource] Send cavv as xid when xid is missing We've been experiencing an error with 3DS 2.0 where Cybersource still requires an xid even though this field isn't present for 3DS 2.0 transactions. This is the exact error `<c:missingField>c:xid</c:missingField>` After discussing with Cybersource and Cardinal it was decided that we will send the cavv as the xid for 3DS 2.0 until they sort out their api. * Bump to v1.108.0 * DLocal: Handle nil address1 Recent address parsing addition in 6419a3474fb87a0d02d75d8312de61e823e8beec did not account for nil address1. Adds handling to not attempt parsing when there is no address1. Unit: 22 tests, 90 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 28 tests, 73 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed ECS-1267 * Braintree: Add travel and lodging fields Added the [industry-specific fields for travel and lodging](https://developers.braintreepayments.com/guides/amex-direct-industry-specific/ruby#travel/cruise-industry-parameters) to the Braintree gateway. In addition, the (rather large) `create_transaction_parameters` method was refactored to pull out many new methods as the main method was getting sufficiently unweildy to cause RuboCop to complain about it. While doing this refactoring, I discovered that [the recurring parameter is now deprecated](https://developers.braintreepayments.com/reference/request/transaction/sale/ruby#recurring), so I removed its use while still allowing the existing parameter to be passed into Active Merchant in order to keep this from being a breaking change. CE-470 Unit: 80 tests, 183 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 82 tests, 439 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4519 tests, 72072 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Stripe: strict_encode64 api key Stripe API keys can be up to 255 characters now, and these longer keys ended up with line breaks when encoded in the headers, causing the error: `ArgumentError: header field value cannot include CR/LF`. Use strict_encode64 to prevent these characters from being added. Stripe: Remote: 71 tests, 324 assertions, 1 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 98.5915% passed (test_successful_store_with_existing_account failure - looks to be related to test data - `Account ... already has the maximum 200 external accounts attached.` - and also fails on master) Unit: 138 tests, 738 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Stripe PI Remote: 39 tests, 183 assertions, 1 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 97.4359% passed (test_transcript_scrubbing failure - cvv string showing up elsewhere in transcript, but not actual cvv though) Unit: 12 tests, 72 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Stripe PI: Implement verify action Added the `verify` action to the Stripe Payment Intents gateway using the [SetupIntents endpoint](https://stripe.com/docs/api/setup_intents/create). CE-554 Unit: 13 tests, 77 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 41 tests, 188 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4520 tests, 72077 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * RuboCop: Fix Style/TrailingUnderscoreVariable Removed the RuboCop to-do item to fix [Style/TrailingUnderscoreVariable](https://docs.rubocop.org/rubocop/cops_style.html#styletrailingunderscorevariable). All unit tests: 4517 tests, 72070 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * RuboCop: Fix Style/WordArray Fixed the RuboCop to-do for [Style/WordArray](https://docs.rubocop.org/rubocop/cops_style.html#stylewordarray). All unit tests: 4517 tests, 72070 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * RuboCop: Fix Style/SymbolArray Fixed the RuboCop to-do for [Style/SymbolArray](https://docs.rubocop.org/rubocop/cops_style.html#stylesymbolarray). All unit tests: 4517 tests, 72070 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Forte: Use underscore for unused arguments in test Working with the Forte gateway in a fork, I received this error from Codacy: ``` test/unit/gateways/forte_test.rb Unused block argument - `headers`. If it's necessary, use `_` or `_headers` as an argument name to indicate that it won't be used. end.check_request do |type, url, parameters, headers| ``` This will mark the type and parameters arguments as unused so that the quality review will pass. Unit tests: 20 tests, 67 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote tests: 22 tests, 63 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4520 tests, 72077 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Closes #3605 * Add Alia cardtype No Alia test card numbers seem to be available, so no tests were written. Paymentez and Kushki both had some changed resposes; I updated these. Paymentez does specifically call out that they now support partial capture for some transactions: https://paymentez.github.io/api-doc/#payment-methods-cards-capture Unit tests: 4521 tests, 72082 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Kushki remote: 13 tests, 42 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Paymentez remote: 26 tests, 66 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Alia: Skip Luhn validation * Element: Fix unit tests A couple of unit tests for the Element gateway were previously implemented as remote tests, which I discovered last night when the Element gateway was down and the unit test file failed. To ensure that the unit test file is not dependent on the gateway being up, these two tests using remote calls to the gateway have been replaced with actual unit tests that stub out the communication with the gateway. Unit: 19 tests, 72 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 21 tests, 55 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4520 tests, 72098 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * RuboCop: Fix Style/SpecialGlobalVars Fixed the RuboCop to-do for [Style/SpecialGlobalVars](https://docs.rubocop.org/rubocop/cops_style.html#stylespecialglobalvars). All unit tests: 4517 tests, 72070 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * RuboCop: Fix Style/StringLiteralsInInterpolation Fixed the RuboCop to-do for [Style/StringLiteralsInInterpolation](https://docs.rubocop.org/rubocop/cops_style.html#stylestringliteralsininterpolation). All unit tests: 4517 tests, 72070 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Payu Latam: fix store method * Diners Club: Support 16 digit card numbers New test card number courtesy of Ingenico docs. Unit tests: 4521 tests, 72083 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Update refund logic & Verification with AVS prior to Auth + Settle (#3674) * Update refund logic & Verification with AVS prior to Auth + Settle * Updated Format for The Travis CI build failed * Updated for SyntaxError * Updated for travis-ci checking * Updated again for Travis-ci checking * Updated for code reviews Co-authored-by: Rocky Lee <[email protected]> * Stripe, Stripe PI: Update supported country list Support added for 5 additional countries: Czech Republic, Romania, Bulgaria, Cyprus, and Malta Stripe PI Remote: 41 tests, 188 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 13 tests, 77 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed remote: Stripe Remote: 71 tests, 325 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 138 tests, 738 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Cybersource: Update supported countries list Adds UAE to supported countries list Remote: 80 tests, 403 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 93.75% passed (5 known unrelated failures) Unit: 86 tests, 402 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Adyen: Allow for executeThreeD to be passed as false Passing false to `executeThreeD` is an option for this gateway that some users may want CE-550 Unit: 66 tests, 315 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 89 tests, 343 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Enforcing browserInfo ONLY when 3ds and adding test Checking for a value only evaluates to true if that value is truthy * WorldPay: Fix handling of `state` field for 3DS transactions ECS-1287 WorldPay Support states: "for 3DS transactions, state should only be populated when Billing or Shipping address is domiciled within the United States." Unfortunately, this change cannot be tested in WorldPay's sandbox, because 3DS transactions will succeed whether `state` is sent or not for non-US countries. Closes #3687 Unit: 73 tests, 485 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 57 tests, 239 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 91.2281% passed (the same tests fail on master) All unit tests: 4523 tests, 72104 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Cybersource: Pass reconciliation_id All unit tests: 4524 tests, 72130 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote tests: 82 tests, 412 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 93.9024% passed Remote test failures: test_successful_3ds_validate_authorize_request test_successful_3ds_validate_purchase_request test_successful_pinless_debit_card_puchase test_successful_tax_calculation test_successful_validate_pinless_debit_card * RuboCop: Fix Layout/HeredocIndentation Fixed the RuboCop to-do for [Layout/HeredocIndentation](https://docs.rubocop.org/rubocop/cops_layout.html#layoutheredocindentation). All unit tests: 4522 tests, 72123 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * RuboCop: Fix Gemspec/OrderedDependencies Fixes the RuboCop to-do for [Gemspec/OrderedDependencies](https://docs.rubocop.org/rubocop/cops_gemspec.html#gemspecordereddependencies). This cop ensures that the dependencies listed in the Gemspec are listed in alphabetical order. All unit tests: 4522 tests, 72123 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Worldpay: exclude empty inst_id (#3686) * Worldpay: exclude empty inst_id * Worldpay: use stub_comms and assert_not_match * Mercado-Pago:add notification_url GSF correct logic and refactor Mercado-Pago: Add notification_url GSF Add notification_url GSF, also update Mercado-Pago test card values Unit: ..................................... Finished in 0.033803 seconds. -------------------------------------------------------------------------------- 37 tests, 171 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote Finished in 67.755391 seconds. ----------------------------------------------------------------------------------------------------------- 31 tests, 85 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 83.871% passed ----------------------------------------------------------------------------------------------------------- 0.46 tests/s, 1.25 assertions/s All Unit tests: Finished in 11.617083 seconds. ----------------------------------------------------------------------------------------------------------- 4517 tests, 72070 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed ----------------------------------------------------------------------------------------------------------- 388.82 tests/s, 6203.79 assertions/s Tests unrelated to this work are still failing, so that should be addressed in another ticket Move notification_url to its own method, add GSF to purchase method, test rewrite Unit: Finished in 0.026636 seconds. ------------------------------------------------------------------------------------- 38 tests, 175 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed ------------------------------------------------------------------------------------- 1426.64 tests/s, 6570.06 assertions/s Remote: Finished in 65.722625 seconds. ------------------------------------------------------------------------------------- 32 tests, 87 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 84.375% passed ------------------------------------------------------------------------------------- 0.49 tests/s, 1.32 assertions/s fix typos * Remove reference to `Billing::Integrations` This is a remnant of when all offsites gateway were extracted to `OffsitPayments`. The namespace `Billing::Integrations` doesn't exist anymore. * Credorax: Only send 3ds_homephonecountry when phone number is present Credorax 3DS requires the field 3ds_homephonecountry for 3DS requests where the phone number is present. However, if the phone number is not present, you'll get an error if you still send this field. We originally allowed users to pass optional fields by adding an `optional` key to the three_ds_2 options hash (#3515). This PR updates the method to check for this specific key and only set it if phone is present. I don't love this, but unsure if there's a better way to do this given that we support the field as an arbitrary one passed in this optional hash - other ideas welcome! Remote: 40 tests, 147 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 68 tests, 321 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Bump to v1.109.0 * Cybersource: Add fields to override stored creds Added four new fields to allow for directly overriding the standard stored credential fields for the Cybersource gateway. These four new fields are all held within the `stored_credential_overrides` hash: ``` @options[:stored_credential_overrides] = { subsequent_auth: 'true', subsequent_auth_first: 'false', subsequent_auth_stored_credential: 'true', subsequent_auth_transaction_id: '54321' } ``` CE-698 Unit: 87 tests, 410 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 81 tests, 407 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 93.8272% passed All unit tests: 4523 tests, 72134 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unrelated, previously failing remote tests: - test_successful_validate_pinless_debit_card - test_successful_tax_calculation - test_successful_pinless_debit_card_puchase - test_successful_3ds_validate_purchase_request - test_successful_3ds_validate_authorize_request * FirstData e4 v27+: Strip linebreaks from address These characters cause an error for 3DS auth. Closes #3693 Unit: 32 tests, 150 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 26 tests, 111 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Adyen: Change shopper_email to email and shopper_ip to ip Include backwards compatibility for these fields * FirstdataE4V27Gateway: Fix strip_line_breaks method The recently added strip_line_breaks method added the requirement that all values in the shipping hash be strings. It is often the case though that nil values are supplied, especially for fields like address2. This fix changes the function to allow for nil values. Modified the following test to introduce a nil value to make sure this does not regress: test_requests_scrub_newline_and_return_characters_from _verification_string_components 4533 tests, 72185 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed 692 files inspected, no offenses detected * CyberSource: conditionally find stored credentials * Cybersource: Allow false for subsequent auth override * Credorax: Default 3ds_browsercolordepth to 32 when passed as 30 Credorax does not accept the value 30 (deep color) as an input for browser depth. Instead we should default to 32 when this value is returned. Unit: 69 tests, 327 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 40 tests, 147 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Update logic to send cavv as xid for 3DS2 to follow CS recommendations (#3699) * Updated for doing a verification with AVS prior to purchase * Updated for travis-ci's offenses * README: Use SVG badges They are quite readable * [Cybersource] Set authorization on the response even when in Fraud Review * Bump to v1.110.0 * Realex: Change 3DSecure v1 message_version to a valid format (#3702) message_version for v1 must be either 1 or blank * Ingenico/Global Collect: Add Installments Add the option of sending the number of installments for a payment and related tests. Remote tests are failing, pushing so someone else can test it out. Unit: 24 tests, 105 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 22 tests, 33 assertions, 13 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 40.9091% passed Local: 4537 tests, 72200 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed update changelog * Fat Zebra: standardized 3DS fields and card on file extra data for Visa scheme rules Closes #3409 Remote: 28 tests, 100 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 20 tests, 105 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Fix rubocop offense (trailing spaces) (#3711) * Add pry-byebug development dependency (#3710) * Cybersource: do not send 3DS fields if 'cavv` is missing and `commerceIndicator` is inferred (#3712) * Cybersource: do not send 3DS fields if some are missing Do not send 3DS fields if `cavv` is missing and `commerceIndicator` is inferred by `active_merchant`. * Cybersource: make request XML assertions less brittle Assertion are irrelevant in case the interpolated data is `nil` -> add `<` to the assertion so there are relevant if the interpolated data is `nil` * Bump to v1.111.0 * Fix changelog for v1.111.0 release * Cybersource: add `maestro` and `diners_club` eci brand mapping (#3708) * Cybersource: Ensure Partner Solution Id placement conforms to schema The Cybersource XML request must follow the defined xsd schema format or else it will result in an XML parse error. Currently, if someone tries to use stored credential fields in addition to the partner solution id, they will encounter an error. The schema requires `subsequentAuth` to come before the solution id and for the other stored credential fields to come after solution id. This PR updates the request building methods to ensure that these fields are included in the right order, also adding remote tests for this behavior. Remote: 89 tests, 457 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 94.382% passed (pre-existing failures) Unit: 96 tests, 463 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Adyen: Pass `subMerchantId` as `additionalData` Payment facilitators must pass this value for auth/purchase transactions CE-839 Unit: 69 tests, 325 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 91 tests, 351 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit test for subMerchantId Remove puts statement * Adyen: Pass `subMerchantId` as `additionalData` Payment facilitators must pass this value for auth/purchase transactions CE-839 Unit: 69 tests, 325 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 91 tests, 351 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit test for subMerchantId Update changelog * Litle: Omit checkNum when nil ACH transactions in which the `checkNum` was `nil` were previously sending an empty `checkNum` node, which caused failures against the Litle gateway. This adds a check so that the `checkNum` node is created only when there is a value for this field. ECS-1350 Unit: 46 tests, 201 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 43 tests, 188 assertions, 13 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 69.7674% passed Many remote tests are currently failing [due to previously noted changes to the gateway's responses](https://github.com/activemerchant/active_merchant/issues/3618). All unit tests: 4544 tests, 72251 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * PayU Latam - Improve error response * PayU Latam - Improve error response Add additional error detail when paymentNetworkResponseErrorMessage might be more useful. CE-482 Unit: 33 tests, 131 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 35 tests, 77 assertions, 6 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 82.8571% passed * Vantiv Express: Add CardPresentCode, PaymentType, SubmissionType CE-769 Unit: 22 tests, 99 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 24 tests, 67 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * PayU Latam - Improve error response Add additional error detail when paymentNetworkResponseErrorMessage might be more useful. CE-482 Unit: 33 tests, 131 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 35 tests, 77 assertions, 6 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 82.8571% passed Closes PR #3717 * Remove extra line to fix rubocop offense * Cybersource: Ensure issueradditionaldata comes before partnerSolutionId XML parse error observed if this field comes after partnerSolutionId. Switch order and add tests. Also check merchant_descriptor in case that could cause issues. Unit: 96 tests, 467 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 95 tests, 489 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 94.7368% passed (all known, unrelated failures) * Update CHANGELOG with Vantiv PR numbers * Bump activemerchant to v1.112.0 * Orbital: Add cardIndicators as a gateway specific field CE-710 Unit: 94 tests, 557 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 36 tests, 185 assertions, 4 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 88.8889% passed Unrelated, previously failing remote tests: - test_successful_american_express_authorization_with_3ds - test_successful_american_express_purchase_with_3ds - test_successful_master_authorization_with_3ds - test_successful_master_purchase_with_3ds Rubocop lint fixes. Add add_card_indicators to the authorize action. Unit:: 95 tests, 561 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Update credit_card number for visa 22 tests were failing on master with previous card_number, change to visa card number fixed most of those failures with the exception of 3ds tests that are still failing (total of 4 failed tests) Unit: 95 tests, 561 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 36 tests, 185 assertions, 4 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 88.8889% passed * Openpay: Add Colombia to supported countries ECS-1278 * Orbital: Fix typo in PC3DtlLineTot field PC3Dtllinetot changed to PC3DtlLineTot CE-762 Unit: 93 tests, 553 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 35 tests, 181 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 85.7143% passed Failed tests appear to be new and unrelated to changes made in Active Merchant Removing redundant conditional * Mercado-Pago: Update Device Id Header field Currently we are sending ‘X-Device-Session-Id’ in the header. The correct header we should be sending is 'X-meli-session-id'. Unit tests: 38 tests, 175 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed 32 tests, 87 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 84.375% passed The five failing tests are also failing on Master: test_partial_capture failing with "Invalid parameters for payment_method API" test_successful_authorize_and_capture_with_cabal failing with "Deferred capture not supported" test_successful_purchase_with_processing_mode_gateway failing with "Unauthorized use of processing mode gateway" test_successful_purchase_with_taxes_and_net_amount failing with "The name of the following parameters is wrong : taxes" test_successful_void_with_cabal failing with "Deferred capture not supported" Did not update the changelog since it is a fix. * RuboCop: Fix Style/TrailingCommaInHashLiteral Fixes the RuboCop to-do for [Style/TrailingCommaInHashLiteral](https://docs.rubocop.org/rubocop/0.85/cops_style.html#styletrailingcommainhashliteral). All unit tests: 4534 tests, 72191 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * RuboCop: Fix Naming/PredicateName Fixes the RuboCop to-do for [Naming/PredicateName](https://docs.rubocop.org/rubocop/0.85/cops_naming.html#namingpredicatename). All unit tests: 4543 tests, 72248 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * RuboCop: Fix Style/Attr Fixes the RuboCop to-do for [Style/Attr](https://docs.rubocop.org/rubocop/0.85/cops_style.html#styleattr). All unit tests: 4544 tests, 72251 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Payflow: Use application_id to set buttonsource For rev share flagging purposes, Payflow requires the corresponding code to be included as ExtData field BUTTONSOURCE, similar to Paypal. Example structure as follows, confirmed by paypal/payflow support (https://stackoverflow.com/a/19414626): ``` <Sale> <PayData> (Invoice) (Tender) </PayData> (ExtData)* </Sale> ``` This PR updates sale and auth requests to set this field appropriately when application_id is provided Unit: 49 tests, 243 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 38 tests, 156 assertions, 12 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 68.4211% passed (unrelated failures preexist on master) * HPS: Enable refunds using capture txn Currently, if you try to issue a refund using a capture as your reference transaction, you will get an error. This is because the authorization value here only refers to the capture, with no connection to the auth. In other adapters, we solve for this by building up an authorization value that includes references to the current transaction as well as reference transactions (and potentially other data). This allows us to parse this field to return the correct reference transaction for supplemental actions. This PR updates HPS to build an authorization value including the authorize transaction id for captures. It also adds in logic to pluck off the appropriate value when issuing a refund on a capture txn. Unit: 54 tests, 267 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 52 tests, 143 assertions, 3 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 94.2308% passed (preexisting failures also on master) * Quickbooks: Omit empty strings in address This fixes a bug caused by submitting an empty string for the state field (which is submitted as 'region' to Quickbooks). While `nil` values for this field are fine because the field is then simply omitted from the request sent to Quickbooks, sending an empty string results in the error message `card.address.region is invalid`. ECS-1355 Unit: 22 tests, 118 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 18 tests, 44 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed All unit tests: 4544 tests, 72251 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * BlueSnap: Add transactionMetaData support Fully support `transaction-meta-data` field. See documentation on [meta-data](https://developers.bluesnap.com/v8976-XML/docs/meta-data) field. CE-697 Unit: 35 tests, 199 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 45 tests, 158 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Orbital: Allow level 3 fields to be passed on capture Add level 3 fields to capture transactions. Revert a previous 'fix' where PC3DtlLineTot was incorrectly assumed to be the correct tag (should be `PC3Dtllinetot`). CE-930 Unit: 95 tests, 561 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 37 tests, 192 assertions, 2 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 94.5946% passed * Credorax: Send j5 and j13 params for CFT txns Credorax now requires the following parameters when issuing CFT payouts: * j5 - Fund recipient's first name * j13 - Fund recipient's surname Updates the referral_cft action to set these two fields, and checks for their presence in the tests. Remote: 41 tests, 152 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 69 tests, 329 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Update CardIndicators field to fix bug Confirm that card_indicators is being passed to the gateway. I confirm that card_indicators is being passed with options. See options hash below. 3DS tests on orbital are still failing, as they have been on master. {:order_id=>"bc8b1fd1ca40f4d8ba6e072cfa11f38f", :address=>{:name=>"Jim Smith", :address1=>"456 My Street", :address2=>"Apt 1", :company=>"Widgets Inc", :city=>"Ottawa", :state=>"ON", :zip=>"K1C2N6", :country=>"CA", :phone=>"(555)555-5555", :fax=>"(555)555-6666"}, :merchant_id=>"merchant1234", :soft_descriptors=>{:merchant_name=>"Merch", :product_description=>"Description", :merchant_email=>"email@example"}, :card_indicators=>"y"} Orbital: correct ordering for CardIndicators Unit: 95 tests, 561 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 36 tests, 189 assertions, 2 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 94.4444% passed Unrelated, previously failing remote tests: - test_successful_american_express_authorization_with_3ds - test_successful_american_express_purchase_with_3ds Updated CHANGELOG * CyberSource: Always send default address Previously, when an empty string was submitted for the `[:billing_address][:country]`, CyberSource would response with an error message since this field is required. When a payment method that contained only a phone number with no other address information was used, this resulted in the payment failing. To resolve this issue, the `setup_address_hash` method was updated to match the intent of the already existing comment: to always supply the default address to CyberSource regardless of whether a `nil` value or an empty string was initially submitted as the value for `country` or any other required address field. ECS-1363 Unit: 97 tests, 470 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 95 tests, 490 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 94.7368% passed All unit tests: 4551 tests, 72299 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * [Netbanx] Reject partial refund on pending status (#3735) * Partial Refund reject on Pending status * update condition for greater and less * update for The Travis CI build failed Co-authored-by: Rocky Lee <[email protected]> * Bump to v1.113.0 * BlueSnap: address1,address2,phone,shipping_* Add support for following fields: - card-holder-info/address - card-holder-info/address2 - card-holder-info/phone - shipping-contact-info/first-name - shipping-contact-info/last-name - shipping-contact-info/address1 - shipping-contact-info/address2 - shipping-contact-info/city - shipping-contact-info/state - shipping-contact-info/zip - shipping-contact-info/country CE-913 Unit: 37 tests, 217 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 47 tests, 162 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * BlueSnap: Protect against nil metadata A recent commit added support for receiving meta-data on BlueSnap but did not protect against a `nil` key being submitted for that field. This change protects against `{ transaction_meta_data: nil }` for BlueSnap. 4556 tests, 72358 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 692 files inspected, no offenses detected * Fix changelog from previous commit * [CyberSource] Ensure the default address doesn't override `ActionController::Parameters` When `ActionController::Parameters` is passed to Cybersource, the default address fields are used instead of the passed parameters. See following comment for more information. References: https://github.com/activemerchant/active_merchant/pull/3747#issuecomment-686720226 * Bump to v1.114.0 * Adyen: Safely add execute_threeds: false In df60a2c5512bf43917a8d5d825d6b7c021dbdd1d when execute_threeds is false it is assigned to the additionalData as a whole instead of additively, so previously added additionalData fields were destroyed. This change adds the field safely. Remote: 92 tests, 353 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 70 tests, 330 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Closes #2756 * RuboCop: Fix Layout/SpaceAroundEqualsInParameterDefault Fixes the RuboCop to-do for [Layout/SpaceAroundEqualsInParameterDefault](https://docs.rubocop.org/rubocop/0.85/cops_layout.html#layoutspacearoundequalsinparameterdefault). All unit tests: 4543 tests, 72248 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * iATS Payments: Pass email address outside of the billing address scope Give ability to pass customer details outside of the scope of the billing address CE-795 Unit: 18 tests, 178 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 14 tests, 61 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Add unit test * Orbital: Don't pass xid for txns using network tokens When attempting certain apple pay transactions, the following error occurs: ``` Error. The Orbital Gateway has received a badly formatted message. Field [Verified-By-Visa XID] exceeded max length of [40] ``` This is technically because in practice, the creditcard.transaction_id on these network tokens is (sometimes? always?) longer than 40 characters, and we aren't trimming it down in any way. However, after looking at the docs, it does not appear that XID is actually a required field for transactions made with network tokens - instead, the main field of note is `DigitalTokenCryptogram`. From docs: ``` An additional cryptogram field (digitalTokenCrytogram) has been added which is compatible with all card brand specific cryptograms. This field must also be submitted as Base 64 encoded. The gateway will parse the data and populate the appropriate fields in the request host message. ``` Orbital suppport mentioned the following about this field when asked about this error: ``` In Orbital, the DigitalTokenCryptogram replaces the other fields necessary for the cryptogram. So it's an either-or situation. I believe XID is specifically the American Express cryptogram field. ``` Additionally, in the initial implementation we believed this field was not required, but decided to send it just in case it might be needed (https://github.com/activemerchant/active_merchant/pull/2553#issuecomment-323758987). Given the results currently observed, this PR removes XID unless the transaction is a 3DS visa transaction. Remote: 37 tests, 188 assertions, 4 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 89.1892% passed (failures also happening on master) Unit: 95 tests, 560 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Forte: Add service_fee_amount field Add support for service fee which can be passed in the request body as `service_fee_amount`. To note, merchants must be configured to accept service/convenience fees or they will get a 'U27: CONV FEE NOT ALLOWED' [transaction response code](https://www.forte.net/devdocs/reference/response_codes.htm). The sandbox environment I am working with is not configured for service fees so I was unable to write a remote test for this. CE-491 Unit: 21 tests, 72 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 22 tests, 63 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed - Create specific response for successful_purchase_with_service_fee - Update CHANGELOG * Worldpay: Add Support for Idempotency Key Add the ability to send through an Idempotency-Key as a header on Worldpay transactions as an option. Unit tests: 75 tests, 491 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote tests: Finished in 78.308251 seconds. 57 tests, 239 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 91.2281% passed The tests (which are also failing on master): test_3ds_version_1_parameters_pass_thru test_3ds_version_2_parameters_pass_thru test_successful_credit_using_token test_successful_mastercard_credit_on_cft_gateway test_successful_visa_credit_on_cft_gateway * Orbital: Fix line_tot conditional check `if :line_tot` is not resolving to true in some cases because the value is actually a string. Expanding the check to evaluate against a string and symlink should resolve this issue. CE-762 Unit: 95 tests, 560 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 37 tests, 192 assertions, 2 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 94.5946% passed * RuboCop: Fix Lint/UnusedMethodArgument Fixes the RuboCop to-do for [Lint/UnusedMethodArgument](https://docs.rubocop.org/rubocop/0.85/cops_lint.html#lintunusedmethodargument). All unit tests: 4543 tests, 72248 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * RuboCop: Fix Naming/MemoizedInstanceVariableName Fixes the RuboCop to-do for [Naming/MemoizedInstanceVariableName](https://docs.rubocop.org/rubocop/0.85/cops_naming.html#namingmemoizedinstancevariablename). All unit tests: 4543 tests, 72248 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * RuboCop: Fix Style/BlockComments Fixes the RuboCop to-do for [Style/BlockComments](https://docs.rubocop.org/rubocop/0.85/cops_style.html#styleblockcomments). All unit tests: 4544 tests, 72251 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed * Checkout V2: Move to single-transaction Purchases When the Checkout V2 adapter was initially implemented, it seems that the Checkout API couldn't perform a refund on an auto-captured authorizations (ie, single-transaction purchase), so Purchase used a multi-response authorization and capture call. We have recently noticed intermittent Purchases that the adapter considers successful but in fact the Capture response was a 404. According to Checkout, this may be due to their id for the authorization not having yet been instantiated before the Capture reached them. So the multiresponse is too fast for its own good, and also the adapter's success criteria isn't sufficient to catch a failed Capture as part of a Purchase. However, it seems that the constraint on refunds has since been removed. So, we can switch to a single-transaction Purchase, by not setting the capture field as false. There should be no effective difference in terms of the resulting Response. Remote: 33 tests, 80 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 29 tests, 129 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications …
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Several remote tests on the Litle gateway are currently failing due to changes in response formatting and/or error response issuance. Documentation: https://developer.vantiv.com/docs/DOC-1347
There are also some duplicate tests that we can remove (e.g.
test_unsuccessful_voidandtest_void_unsuccessful).By extension, the responses in the unit tests should also be regenerated, and the unit tests updated accordingly.
The text was updated successfully, but these errors were encountered: