forked from activemerchant/active_merchant
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bookingsync #14
Closed
Closed
Bookingsync #14
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
Fix the changes in commit f4620fe Closes activemerchant#2573 Remote: 14 tests, 54 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit 11 tests, 61 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
WePay has restricted compatibility for the version specified in the request header, to equal to or one ahead of the version set in WePay's Dashboard for that merchant account. This means that letting the adapter default the version header to a certain version (likely one or more version behind current) has greater potential to break integration than allowing WePay's API to assume the version set in the dashboard for that account, which occurs if the header is absent. api_version can still be sent in options and will override the dashboard setting, but be advised that this will only work for one version ahead of what is set in the dashboard. I have updated the version in the dashboard for the test account in Fixtures to the current version, so these tests are run against that version. Closes activemerchant#2567 Remote: 23 tests, 39 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 20 tests, 74 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Buyer data can be separate from the Payer's (tied to the payment method). This change allows options to be passed for a unique buyer, and adding the buyer element no longer conditions only on the presence of a shipping address. Also adds fields that were missing but are required for Brazil, Colombia, and Mexico, and allows passing paymentCountry as an option. Closes activemerchant#2570 Unrelated Capture and Void remote tests still failing Remote: 18 tests, 47 assertions, 2 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 88.8889% passed Unit: 22 tests, 86 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
According to PayU, the Buyer element is required, and if no buyer info is provided, the Payer's info should be sent in its place, and if only partial Buyer info is provided, the missing fields should instead be sent empty. This change ensures these conditions are fulfilled. It also gathers the buyer fields under one buyer hash option instead of multiple top-level buyer_* fields, and exposes a top-level cnpj field for the payer. Closes activemerchant#2578 Remote tests continue to fail unrelated capture and void. Remote: 18 tests, 47 assertions, 2 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 88.8889% passed 23 tests, 89 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Instead of restricting the customer ID to numbers only, allow for any letter, number, or underscore characters. This will allow for a wider range of values while still preventing email addresses and phone numbers. Related activemerchant#704 Closes activemerchant#2579
We've see transaction failures on Beanstream when `ordProvince` and `shipProvince` are provided without a country. According to Beanstream, these values may be optional, but they codependent and if one is included, then both must be present. Closes activemerchant#2582
Adds support for performing refund transactions on Kushki. The refund endpoint is a bit quirky in that the response body only returns a message and status code, not a unique transaction identifier like other endpoints. Additionally, the amount param is ignored since the call to perform a refund only accepts a reference identifier. Closes activemerchant#2575
The response message for a couple failed remote tests have slightly changed. This relaxes the assertion a bit to check for the presence of the words "Invalid account" instead of an exact string. Previous failure message: "Invalid account number" Current failure message: "Invalid account format."
MercadoPago seems to use the same card type formatting as Active Merchant except in the case of American Express and Diners Club. Amex was updated previously but Diners Club was left out. This formats the diners_club type as just diners. Closes activemerchant#2585
No longer requires email for Store actions and instead allows the method to default the value if it's absent. Closes activemerchant#2588 Remote: 24 tests, 40 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 20 tests, 74 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
This fixes interpolating the raw response from Payhub's API in the error message. Closes activemerchant#2572 and activemerchant#2516
This file was added <shrug>somehow</shrug> and should be there.
Per WePay's documentation, both `original_ip` and `original_device` are not valid arguments when calling `/credit_card/transfer`. These two params will now only be sent to `/credit_card/create` when storing a credit card. Also, the `verification_value` has been changed in remote tests to prevent a false positive failure in `test_transcript_scrubbing`. Closes activemerchant#2597
Barclaycard Smartpay requires a `pspReference` from a previous authorization to be sent, not the `pspReference` from a subsequent capture. This updates the authorization field to be a concat of the authorization and capture `pspReference` values which will then be later split, and the first (authorization) `pspReference` will be used in the refund request. I should note that this fix is backwards compatible with the previous setup- non concated authorizations will still send the capture `pspReference`- however those transactions will still ultimately fail when refund settlements are attempted. Closes activemerchant#2599
Credorax has changed their response code messages. This also updates test card values and remote tests. Closes activemerchant#2595 Remote: 18 tests, 51 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 17 tests, 83 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
When performing a void transaction on Borgun, the currency code must match the original currency code used on the authorization. Because of this, the adapter will now store the original currency code in the authorization and include it when void is called. Closes activemerchant#2605
Adds Store support. The "responsible" element is now only added when it is required, for transactions in Brazil with a person_type of "business". Store also passes "country" from options, as it is required. Four negative test cases are failing due to changes to test card numbers we have yet to receive an update for. Closes activemerchant#2604 Remote: 18 tests, 46 assertions, 4 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 77.7778% passed Unit: 15 tests, 51 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Elavon/Converge is updating their endpoint URLS as per https://www.besha2ready.com/converge Closes activemerchant#2608 Remote: 23 tests, 102 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 28 tests, 138 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Checks both gateway parameters and options for payment_country and sets it as an attribute of the gateway on initialize. 2 remote tests continue to fail unrelated capture and void. Closes activemerchant#2611 Remote: 18 tests, 47 assertions, 2 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 88.8889% passed Unit: 24 tests, 94 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
Authorize.net can send back one or multiple errors in their responses. We need to correctly assess whether response["messages"]["message"] is an Array or Hash, and if it is an Array, then we need to set the top level error_code and message fields to the first error returned. Closes activemerchant#2537
Passes email fields even if a billing or shipping address is not present. Also supports a shipping_email option. 2 remote test failures are occuring for echeck transactions, for which we are not currently concerned. Closes activemerchant#2615 Remote: 35 tests, 158 assertions, 2 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 94.2857% passed Unit: 21 tests, 100 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
allow activesupport 6 in gemspec for Rails 6 compatibility
Add payment intent for stripe
change PAU to RES authorization for Ogone
* fix stripe api headers * fix specs for Ogone dependent gateway
Fix braintree gem version for CI matrix
Handle off_session request parameter
…-for-stripe-payment-intents add support for payment_method_options for StripePaymentIntentsGateway
support Rails 7
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.