Pin rails 5.2 #3
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Unit: 19 tests, 77 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 17 tests, 44 assertions, 2 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 88.2353% passed
…merchant#2952) By default Payflow will consider the first capture the final one, by passing `CAPTURECOMPLETE=N` it lets us capture again later on. [Docs](https://developer.paypal.com/docs/classic/payflow/integration-guide/#paypal-credit-card-transaction-request-parameters) Remote: (Failures related to ACH and recurring billing) 32 tests, 137 assertions, 8 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 75% passed Unit: 46 tests, 208 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Adds city and state to the address information passed in `CardHolderAddress`. Also allows for verify method to send address information. Loaded suite test/unit/gateways/ct_payment_test .............. 14 tests, 48 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Loaded suite test/remote/gateways/remote_ct_payment_test .................... 20 tests, 58 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
With visa updates, Adyen now requires the type of recurring processing model for all recurring transactions. This adds the neccessary field. Loaded suite test/remote/gateways/remote_adyen_test .................................. 34 tests, 86 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Loaded suite test/unit/gateways/adyen_test ...................... 22 tests, 102 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Remote tests failing don't appear to be related to the URL change. Unit: 16 tests, 54 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 21 tests, 57 assertions, 3 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 85.7143% passed Closes activemerchant#2949
EBANX accepts credit card payments from Chile and Argentina (https://business.ebanx.com/en/payment-methods). Closes activemerchant#2950
When I fixed YAML, I accidentally committed this script with parens in the wrong place. Fix that.
This patch contains four quick fixes, all for ambiguous code or unused variables. Specifically, the following issues are rectified: - test/unit/connection_test.rb:51: warning: assigned but unused variable - response - test/unit/gateways/firstdata_e4_v27_test.rb:56: warning: ambiguous first argument; put parentheses or a space even after `/' operator - test/unit/gateways/paymentez_test.rb:121: warning: ambiguous first argument; put parentheses or a space even after `/' operator - lib/active_merchant/billing/gateways/ct_payment.rb:210: warning: assigned but unused variable - final_response
Clearhaus now allows $0 auths, allowing us to tweak verify to use a $0 transaction. Unit: 22 tests, 110 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 23 tests, 70 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Unit: 17 tests, 78 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 16 tests, 38 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Adds support for processing GooglePay payment methods. It appears that Braintree treats GooglePay in the same manner as AndroidPay. Even their documentation (linked below) claims that GooglePay cards are represented as AndroidPay cards. As such, the only way to get the GooglePay remote test to pass is to pass the payment information in as `android_pay`. Ref: https://developers.braintreepayments.com/guides/google-pay/server-side/ruby Remote: 63 tests, 361 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 50 tests, 124 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Unit: 23 tests, 109 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 35 tests, 88 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Note that this can't really be tested in the sandbox (it's changing how Adyen processes the card, so the sandbox doesn't do anything with it), so remote tests are omitted. Remote: 35 tests, 88 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 24 tests, 112 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Unit Tests: 12 tests, 119 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote Tests: 14 tests, 32 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Unit: 24 tests, 113 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 36 tests, 90 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Was getting this error in a project when running its acceptance tests against a mocking service that used a `http` schema. ``` undefined method `ssl_version' for #<TCPSocket:(closed)> $GEMS/bundler/gems/active_merchant-f3d11caabc66/lib/active_merchant/net_http_ssl_connection.rb:7:in `ssl_connection' $GEMS/bundler/gems/active_merchant-f3d11caabc66/lib/active_merchant/connection.rb:82:in `block (2 levels) in request' ```
Note that PayU Latam's sandbox does not support capture, so while I added remote tests, they're more...let's call it hypothetical. Failing remote tests are unrelated to this change Unit: 28 tests, 104 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 30 tests, 68 assertions, 4 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 86.6667% passed
In particular, this fixes: Layout/EmptyLineAfterMagicComment Layout/EmptyLinesAroundArguments Layout/EmptyLinesAroundBlockBody Layout/EmptyLinesAroundExceptionHandlingKeywords Layout/EmptyLinesAroundModuleBody
Closes activemerchant#2979 Remote: 14 tests, 33 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 13 tests, 122 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Unit: 25 tests, 115 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 30 tests, 63 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
According to ProPay's docs, the dash should not be included for 9 digit zip codes. ECS-125 Unit: 17 tests, 71 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Closes activemerchant#3129
Previously authorizations for the store action were empty. Now we return the relevant customer_vault_id as the authorization to use in subsequent transactions. Closes activemerchant#3130 Remote: 34 tests, 110 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 27 tests, 195 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Closes activemerchant#3133 Remote (Failures probably due to changes to sandbox, relevant remote test does pass): 34 tests, 83 assertions, 9 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 71.875% passed Unit: 21 tests, 103 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Support sending full name for ACH transactions in require name field. ECS-137 Unit: 10 tests, 35 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 16 tests, 59 assertions, 3 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 81.25% passed closes activemerchant#3132
Closes activemerchant#3135 Remote: 19 tests, 63 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 18 tests, 86 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Closes activemerchant#3137 Remote (1 unrelated failure for echeck related to amount): 23 tests, 54 assertions, 1 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 95.6522% passed Unit: 21 tests, 89 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
The Visa/Mastercard Stored Credentials Framework is becoming standard
functionality across all gateways. There are a few gateways in Active
Merchant which support sending in very specific fields in the options
hash which will be set while building a auth/purchase request. However
Active Merchant should be a consistent interface to gateways and to that
end, this commit is introducing a new normalized hash which contains
a standard set of fields by which the proper logic should be able to
construct a correct stored credentials request to any gateway.
The hash takes the following structure:
{
stored_credential: {
inital_transaction: Boolean, # either true or false
recurring: Boolean, # either true or false
initiator: String, # either "merchant" or "cardholder"
network_transaction_id: String # returned card network transaction id
}
}
With those 4 bits of information, you should be able to successfully add
the necessary fields to any gateway request. Note that there should be
logic to add the necessary values in the request (see this commit as an
example) and not all gateways will need or accept all those fields.
In many ways this is similar to normalizing address fields in that
Active Merchant always expects and address hash to use a field `zip`
instead of something like `postalCode`. However the downside to this
setup is that there is no field level validation which we get with
something like an Active Merchant CreditCard.
Lastly, this commit also allows for the specific fields to also be sent
to maintain backwards compatibility with anyone who might already be
using the specific fields.
Previously the new/beta normalized stored credential hash was using a boolean value to indicate if a transaction was part of a recurring transaction or not. However, this did not allow for the case of gateways (like Worldpay) to take into account transactions that are part of an installment. This adjusts the previously "recurring" field to use the name "transaction_type" which accepts a string of either: - "installment" - "recurring" - "unscheduled" This should allow more flexibility to for other gateways that also have the notion of a payment that is part of an installment. Note that this normalized hash is still in "beta" use. The hash structure itself may change and until there is solid use around it across multiple gateways, it will likely be a defined-yet-not-enforced hash rather than an object which provides guarantees around field values. Closes activemerchant#3139
Allows for initiating Dynamic 3DS by passing browserInfo without executeThreeD. Merchant account must be set up for Dynamic 3DS. ECS-131 Unit: 27 tests, 130 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 41 tests, 111 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Closes activemerchant#3138
This requires keeping track of actions in order to properly choose the url for voiding refunds since it is different from refunding purchases. Closes activemerchant#3142 Remote (1 unrelated failure): 22 tests, 78 assertions, 1 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 95.4545% passed Unit: 17 tests, 89 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
As per the Pay safe API documentation and our discussion with their representative we know that the merchantRefNum has to be unique each time we communicate with the API. Also we specifically asked that if the merchantRefNum has to be the order id, to which the answer was no. It can be any random string, as long as it is unique each time.
Add support for ACH/ECP/echeck payments. ECS-60 Unit: 25 tests, 97 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 33 tests, 103 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed closes activemerchant#3143
ECS-60 Unit: 25 tests, 97 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 33 tests, 103 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Unit: 17 tests, 89 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed ECS- Unit: Remote:
Combine username and account number into one field for Bambora gateway Fix warning in Bambora remote tests
Renames to Bambora Asia-Pacific, removes Bambora Ready, adds void action ECS-159 Unit: 7 tests, 47 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 11 tests, 20 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Closes activemerchant#3145
Adds support for the ClientInfo field used to send the customer's IP address. ECS-124 Unit: 34 tests, 249 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 15 tests, 70 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed closes activemerchant#3131
Unit: 37 tests, 112 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 16 tests, 46 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed closes activemerchant#3098
Pinpayments handles stored cards by assigning them to a user. It seems that if a card is associated with a user the card must be used with the customer ID rather than the card's, and since a card can only be associated with one user, it's not clear that the card ID generated when a card is stored will ever actually be reusable (see the [Customer API docs](https://pinpayments.com/developers/api-reference/customers#put-customer) since cards are irretrievable once they are replaced. The possible use case for stored card IDs is that customers may have multiple cards if one is set as primary. Other stored cards may not be able to be used until/unless they are set as primary.
Unit: 38 tests, 30 assertions, 20 failures, 17 errors, 0 pendings, 0 omissions, 0 notifications 2.63158% passed Remote: Advanced 40 tests, 56 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Transaction 29 tests, 110 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed closes activemerchant#3111
Update link to be http closes activemerchant#3084
montdidier
reviewed
Jul 26, 2019
| @@ -193,7 +204,7 @@ def build_purchase_using_stored_card_request(money, identification, options) | |||
|
|
|||
| xml.tag! 'crn', identification | |||
| xml.tag! 'currency', options[:currency] || currency(money) | |||
| xml.tag! 'amount', amount(money) | |||
| xml.tag! 'amount', localized_amount(money, options[:currency] || currency(money)) | |||
There was a problem hiding this comment.
probably ok but if there were a problem with this changes it would likely be here.
yahuio
pushed a commit
that referenced
this pull request
Jan 18, 2023
# This is the 1st commit message: Updates fields for Payeezy gateway Adds the merchant_ref field to general credit transactions and the soft_descriptor hash to refunds. Unit 40 tests, 188 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Remote: 41 tests, 170 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed # This is the commit message #2: corrected argument error # This is the commit message #3: corrected argument error...again
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.