The library integration works well when I was testing it the :test mode, but once I updated my API credentials to the :live mode (https://ca-live.adyen.com), I keep getting this error:

Faraday::ConnectionFailed: Please confirm that Client.env is set to the right value (:live or :test)

I set up the Adyen::Client.env as :live. Is this an issue with the library or my account setup?

ruby version: x.y.z
Library version: x.y.z

Is your feature request related to a problem? Please describe.
The library does not support the sessions endpoint.

Describe the solution you'd like
Add support for /sessions.

Describe alternatives you've considered
Use a generic http client.

Additional context

Describe the bug
When server returns a 403 error with an error code and error message, we only get returned a generic User permissions error that is inaccurate and misleading.

How to reproduce

• It depends on the backend response, but as long as you have a 403 error from the backend with an error code and message, it will always return "User permissions error".

Expected behavior

• It should show the correct error message instead of a blanket User permissions error.

Screenshots
Actual Faraday response from a live API call:

Desktop (please complete the following information):

• ruby Version: 2.7.2
• Library Version: 6.1.0

Additional context
Trying to make an online payment and getting this error, while trying to debug and fix the user permissions I found that it does not have anything to do with permissions.

The offending line can be found in https://github.com/Adyen/adyen-ruby-api-library/blob/develop/lib/adyen/client.rb#L172

Either the backend is not respecting the exclusive usage of 403 status being a user permissions error or the SDK is not updated to reflect the broader subset of 403 errors that the backend provides.

When constructing the /originKey service url, the endpoint structure is be:

https://[live-prefix]-checkout-live.adyenpayments.com/CheckoutUtility/v1/originKeys
whereas it should be
https://[live-prefix]-checkout-live.adyenpayments.com/checkout/v1/originKeys

Described here: https://docs.adyen.com/development-resources/live-endpoints#checkout-endpoints

This is where the service CheckoutUtility is used when constructing the url: https://github.com/Adyen/adyen-ruby-api-library/blob/develop/lib/adyen/client.rb#L64

Describe the bug
Got this error - response = { "status"=>422, "errorCode"=>"100", "message"=>"Required object 'amount' is not provided.",
"errorType"=>"validation" }
by hitting the AdyenClient.new.payments.refund(input1, input2)

How to reproduce
Steps to reproduce the behavior.
a) initializing first:
adyen_client = Adyen::Client.new.tap do |_adyen|
_adyen.api_key = "some value"
_adyen.env = :live
_adyen.live_url_prefix = "some value"
_adyen.checkout.version = 68
end
b) By hitting this adyen_client.payments.refund(input1, input2) where

input1 = {
  'amount': {
    'value': 456,
    'currency': "USD"
  },
  'reference': "some value1",
  'merchantAccount': "some value2"
}

input2 =   {"paymentPspReference": "some value3"}

I got the above mentioned error. Please check . Is something missing here from my end in passing parameters?

Expected behavior
No idea about the response as hitting the API gives error.

Screenshots

Desktop (please complete the following information):

• ruby Version: [x.y.z] - 2.7.4
• Library Version: [x.y.z] - gem 'adyen-ruby-api-library', '~> 6.2'

Additional context
None

Hello,

The current version of the gem does not appear to be supporting Authorise3DS2: https://docs.adyen.com/api-explorer/#/Payment/v40/authorise3ds2

Is it planned to add it to the gem ?

Hello,

The Adyen Client includes includes request parameters when raising errors. Request parameters often include credit card numbers and other personally identifying information. This poses a significant security risk as error messages are typically written to logs and also often sent to external monitoring services where you wouldn't want to have any sensitive information appearing. I'd like to suggest that this sort of information should not be included in error messages, or at the very least there should be the ability to configure not having it included.

Thanks,
Matt

client = Adyen::Client.new
client.api_key = '...'
client.env = :live
client.live_url_prefix = 'abc123'

client.checkout.payments_api.payment_methods({ merchantAccount: 'Test' })

Will call:

https://abc123-checkout-live.adyenpayments.com/v70/paymentMethods

Instead of:

https://abc123-checkout-live.adyenpayments.com/checkout/v70/paymentMethods

It works in test, just breaks in live.

Describe the bug
When deleting a stored payment method using this library, it looks like the API call succeeds, but the library returns a JSON parsing error because the response is empty.

The issue is, it looks like it should be empty - the response in the test portal shows a 204 - so the library should at least expect a payload like this.

How to reproduce

1. Instantiate a gateway object
   gateway = Adyen::Client.new(env: 'test', api_key: '******')
2. Use it to try and delete a known StoredPaymentMethod
   gateway.checkout.stored_payment_methods.delete("G94BB28TP6KXWD82", {shopperReference: "8527589", merchantAccount: "********"})
3. You should get a JSON parsing error
   JSON::ParserError: 767: unexpected token at '' from /Users/pmccarthy/.rbenv/versions/2.6.3/lib/ruby/2.6.0/json/common.rb:156:in 'parse'
4. Go to https://ca-test.adyen.com/ to look at API logs, and confirm the request was received and returned a 204 status

Expected behavior
I would have expected an Adyen::AdyenResult object with status = 204 and response = nil or []

Screenshots

Desktop (please complete the following information):

• ruby Version: [2.6.3]
• Library Version: [6.30]

Additional context
Not clear on what the decorum is for posting account info here, but the log id from ca-test.adyen.com for the interaction above is APIL42255223223D5HQ8HW455B6HBD

ruby version: 2.7.6
Library version: 6.2.0

Describe the solution you'd like
Is it possible to support the donations endpoint on the checkout api?
https://docs.adyen.com/api-explorer/Checkout/68/post/donations

When calling adyen_client.checkout.foo the returned url has an extra /.

Hi, I have a minor suggestion that would help us to use the client library in integration tests and our own environments.

What do you think of adding mock_address so that a name other than localhost can be used for the mock environment? Maybe even mock_service_url_base?

e.g.
https://github.com/Adyen/adyen-ruby-api-library/blob/develop/lib/adyen/client.rb#L10

Happy to do this as a PR if this idea sounds reasonable.

Thanks,
Gary

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Describe the bug

Failure/Error:
       Adyen::Client.new(api_key: credentials[:ADYEN_API_KEY],
                         env: credentials[:ADYEN_ENV],
                         live_url_prefix: adyen_live_url)
     
     NoMethodError:
       undefined method `default_adapter_options' for Faraday:Module

How to reproduce
If you try to initialize Adyen::Client class you will get this error

Expected behavior
Being able to initialize the Adyen::Client class

Additional context
It started with version 7.3.0 and it seems to be related to #169
When no adapter_options is specified, it triggers the before mentioned error

Hello :)

Describe the bug
Today we encountered a situation where two gems are patching the same core class with the same method. badum-ching
They Adyen gem and the aquarium gem are both patching the method to_camel_case into String.
While both seem to have the same intention, the behavior varies slightly regarding the first character.
One gem wants it as upper-case, the other one as lower-case.

We end up with the current exception: aquarium/aspects/advice.rb:281:in const_get': wrong constant name noAdviceChainNode (NameError)`

Notice the lower-case 'n' in the name of a const.

Expected behavior
The expected behavior would be to not have the method to_camel_case in the core String class at all. It would be best not to patch core classes at all within a gem. You never know who else might come up with the same idea for a method name.

Desktop (please complete the following information):

• ruby Version: 2.6.3
• adyen gem Version: 4.1.0
• aquarium gem Version: 0.7.1

Additional context
A quick search didn't reveal any usage of to_camel_case. Is it actually used? Can we simply remove it?
I'll also open an issue at the aquarium gem.

Best regards,
Eric

Seems that adding gem 'adyen-ruby-api-client' installs version 1.0.2 with faraday as a dependency, but the files are actually missing.

Adding gem 'adyen-ruby-api-client', github: 'Adyen/adyen-ruby-api-library', branch: 'master' works correctly.

Hi,

we're migrating from another library to this one. We'd like errors to be raised by Faraday so we can handle them properly. Faraday even provides a ready-to-use middleware, Faraday::Response::RaiseError.

However, this library does not support modifying the middleware stack. Is there anything I can do to work around that limitation? Or does this require a change in the library?

Thanks!

Describe the bug
Downloading the gem from rubygems, the services version for checkout and payments is locked to 50, while in codebase is respectively 65 and 64.

How to reproduce
Download the gem, print services version in console:

Adyen::Checkout::DEFAULT_VERSION => 50
Adyen::Payments::DEFAULT_VERSION => 50

Expected behavior
Expecting to get the right versions:

Adyen::Checkout::DEFAULT_VERSION => 65
Adyen::Payments::DEFAULT_VERSION => 64

Additional context
It should be desirable to set default versions as an argument, since you have more than one version for each service.

ruby version: 2.6.6
Library version: 5.1.0

Is your feature request related to a problem? Please describe.
I want to use the Checkout service to modify payments, such as captures, cancels and refunds actions:
https://docs.adyen.com/api-explorer/#/CheckoutService/v67/post/payments/{paymentPspReference}/captures

Describe the solution you'd like
Calling the missing methods directly on the client, something like:

@client.checkout.payments.captures(payload) # paymentPspReference can be discovered by payload?

Describe alternatives you've considered
We already use the Payment service for capture, cancel and refund actions, but they are not async and we cannot leverage on the webhooks.

Describe the bug
As per the documentation(https://docs.adyen.com/api-explorer/#/Account/v6/post/createAccountHolder), version for the API is 6. But the gem use version 4.

Even if I bump the version to 6, I get authentication error. API key has all the roles enabled. Please check

How to reproduce
#<Faraday::Connection:0x00007fa9ec831998 @parallel_manager=nil, @headers={"Content-Type"=>"application/json", "User-Agent"=>"adyen-ruby-api-library/4.3.0", "x-api-key"=>"AQEvhmfxJ4zLaBFKw0m/n3Q5qf3VaYxEAZZ5V2NC6nmpjaPf/ptZ++Q2ruZ5dh9VszYQwV1bDb7kfNy1WIxIIkxgBw==-xRHZ+iKxeb09WVf0HJcaXvu/UFGTwMSRLhpnDXF6QdE=-;n8xR<^SB9U,:Uaa"}, @params={}, @options=#<Faraday::RequestOptions (empty)>, @ssl=#<Faraday::SSLOptions (empty)>, @default_parallel_manager=nil, @builder=#<Faraday::RackBuilder:0x00007fa9ec831718 @handlers=[Faraday::Adapter::NetHttp]>, @url_prefix=#<URI::HTTPS https://cal-test.adyen.com/cal/services/Account/v6/createAccountHolder>, @Proxy=nil>

Adyen::AuthenticationError: Adyen::AuthenticationError code:401, msg:Invalid API authentication; https://docs.adyen.com/user-management/how-to-get-the-api-key, request:{"accountHolderCode":"RBR1","accountHolderDetails":{"email":"[email protected]","individualDetails":{"name":{"firstName":"Tim","gender":"MALE","lastName":"Green"}}},"legalEntity":"Individual"}

NoMethodError is a wonderful thing to have, and subverting that by responding to literally every possible method depending on the hash keys is a potential source of issues.

Please either use [] and .fetch depending if you want it to raise, or if you must, use ruby stdlib ostruct instead of hashes, or if you really really must, use refinements, so that your Hash#method_missing doesn't affect every codebase using your gem.

Thank you

I really wasn't expecting this to happen.

> {a: 1}.a
NoMethodError
> require 'adyen-ruby-api-library'
> {a: 1}.a
1

Describe the bug
After upgrading to 7.0.2, any payment refund called with API 7.0.2 result in an error : "unexpected token at 'Version 70 is not supported, latest version: 68'. Reverting to 7.0.1 fixes the problem.

How to reproduce
Install 7.0.2 and try to make a refund though the payment modifiication API.

I tried to force API version to 68, but another error message was returned: "Method payments not found in PaymentService"

Expected behavior
The minor version upgrade should not change behavior. Also note that the valid_notification_hmac? method rename to valid_webhook_hmac?on the HmacValidator class, without deprecation or fallback method should not have been part of a minor release. This IS a breaking change.

Desktop (please complete the following information):

• ruby Version: 3.2.2
• Library Version: 7.0.2

please advise where is merchantReference in Dashboard ?

Thanks

Describe the bug
When using the HmacValidator on a webhook that contains special characters such as / or : the validation does NOT pass. Despite being valid and passing when using the Node.js SDK HmacValidator.

Specifically I started seeing issues cause by this with REPORT_AVAILABLE webhooks for reports manually generated. These webhooks include the full URL to the report under the reason attribute and is mistakenly being escaped by the Ruby SDK HmacValidator.

How to reproduce

1. Take the following webhook example:

{
  "NotificationRequestItem": {
    "additionalData": {
      "hmacSignature": "AuriseiMKi3w19nnZHVdktjqdubXyuhjUy86OHwF9tM="
    },
    "amount": {
      "currency": "EUR",
      "value": 0
    },
    "eventCode": "REPORT_AVAILABLE",
    "eventDate": "2022-11-01T21:10:57+01:00",
    "merchantAccountCode": "ACC_CODE",
    "merchantReference": "",
    "pspReference": "threedsecure_authentication_report_2022-11-01T00:00:00_2022-11-02T23:59:59.csv",
    "reason": "https://ca-live.adyen.com/reports/download/MerchantAccount/ACC_CODE/threedsecure_authentication_report_2022-11-01T00:00:00_2022-11-02T23:59:59.csv",
    "success": "true"
  }
}

2. Calculate the HMAC signature using the manual process described in Adyen docs and replace the hmacSignature in the webhook above with the calculated value

3. Attempt to validate it using HmacValidator and see the result is false

4. Attempt to validate it using the Node.js HmacValidator here and see the result is true

This is happening because the Node.js version does not escape the value because it goes through here while the Ruby SDK always escapes the value here

Expected behavior

HmacValidator should correctly handle reason payloads that contain special characters

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• ruby Version: [x.y.z]
• Library Version: [x.y.z]

Additional context
Add any other context about the problem here.

Hi,,

we have an issue related to Apple Pay. We are using several payment methods but only Apple Pay is giving us the following error: errorCode"=>"5_002", "message"=>"Invalid Apple Pay Token", "errorType"=>"validation.

We are using the same request structure for Google Pay and it's working as expected. Please take a look at the requests and responses for both Apple Pay and Google Pay below and let me know if you see any obvious error.

• ruby Version: 2.6.2
• Library Version: 50

Apple Pay:

Request:

{:amount=>{:currency=>"NOK", :value=>8100}, :reference=>"cart name: C-0133 - [email protected]", :paymentMethod=><ActionController::Parameters {"applePayCardNetwork"=>"MasterCard", "applePayToken"=>"{"version":"EC_v1","data":"1X5mCH0M8W21MOCVByb3Oqshz4ifX9p2oBmbk0BfBjyVU7iPt1bD2MHWS7sOelvqxKG1N2p5dd9z/K17KXBXMm8fg8Kn1gzt9TLu6NrUIbsu4N93a+uFth1KjpnsTVr0p/PFOpn7/mpD2EBvXtyjLFwsIZKLuRyqQq23gOFRwkAQVhJhM+OXagNIOtkxBnZ7FW1oPJE0spWFD0hF/7OCB729WAkj8XslmAd9iBLZ1ToQ39lJ3OrajCFZCblTK6Ntpm9dZ1yozZaO6cD/yNIPOOZvUOT6p7iUUt87uDh1KLQ4lLGraBrl0y0hYARt2sS+pBKh2TBzbIGBsm8x4i1tYyxLRqFeEC8BvVWoADebvgT0bEb0SVUd0vtwFCIZNJdKNAiJlpr6aVc5IO331w==","signature":"MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIID5jCCA4ugAwIBAgIIaGD2mdnMpw8wCgYIKoZIzj0EAwIwejEuMCwGA1UEAwwlQXBwbGUgQXBwbGljYXRpb24gSW50ZWdyYXRpb24gQ0EgLSBHMzEmMCQGA1UECwwdQXBwbGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxEzARBgNVBAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTMB4XDTE2MDYwMzE4MTY0MFoXDTIxMDYwMjE4MTY0MFowYjEoMCYGA1UEAwwfZWNjLXNtcC1icm9rZXItc2lnbl9VQzQtU0FOREJPWDEUMBIGA1UECwwLaU9TIFN5c3RlbXMxEzARBgNVBAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEgjD9q8Oc914gLFDZm0US5jfiqQHdbLPgsc1LUmeY+M9OvegaJajCHkwz3c6OKpbC9q+hkwNFxOh6RCbOlRsSlaOCAhEwggINMEUGCCsGAQUFBwEBBDkwNzA1BggrBgEFBQcwAYYpaHR0cDovL29jc3AuYXBwbGUuY29tL29jc3AwNC1hcHBsZWFpY2EzMDIwHQYDVR0OBBYEFAIkMAua7u1GMZekplopnkJxghxFMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUI/JJxE+T5O8n5sT2KGw/orv9LkswggEdBgNVHSAEggEUMIIBEDCCAQwGCSqGSIb3Y2QFATCB/jCBwwYIKwYBBQUHAgIwgbYMgbNSZWxpYW5jZSBvbiB0aGlzIGNlcnRpZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1bWVzIGFjY2VwdGFuY2Ugb2YgdGhlIHRoZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0ZXJtcyBhbmQgY29uZGl0aW9ucyBvZiB1c2UsIGNlcnRpZmljYXRlIHBvbGljeSBhbmQgY2VydGlmaWNhdGlvbiBwcmFjdGljZSBzdGF0ZW1lbnRzLjA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5hcHBsZS5jb20vY2VydGlmaWNhdGVhdXRob3JpdHkvMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwuYXBwbGUuY29tL2FwcGxlYWljYTMuY3JsMA4GA1UdDwEB/wQEAwIHgDAPBgkqhkiG92NkBh0EAgUAMAoGCCqGSM49BAMCA0kAMEYCIQDaHGOui+X2T44R6GVpN7m2nEcr6T6sMjOhZ5NuSo1egwIhAL1a+/hp88DKJ0sv3eT3FxWcs71xmbLKD/QJ3mWagrJNMIIC7jCCAnWgAwIBAgIISW0vvzqY2pcwCgYIKoZIzj0EAwIwZzEbMBkGA1UEAwwSQXBwbGUgUm9vdCBDQSAtIEczMSYwJAYDVQQLDB1BcHBsZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTETMBEGA1UECgwKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMwHhcNMTQwNTA2MjM0NjMwWhcNMjkwNTA2MjM0NjMwWjB6MS4wLAYDVQQDDCVBcHBsZSBBcHBsaWNhdGlvbiBJbnRlZ3JhdGlvbiBDQSAtIEczMSYwJAYDVQQLDB1BcHBsZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTETMBEGA1UECgwKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATwFxGEGddkhdUaXiWBB3bogKLv3nuuTeCN/EuT4TNW1WZbNa4i0Jd2DSJOe7oI/XYXzojLdrtmcL7I6CmE/1RFo4H3MIH0MEYGCCsGAQUFBwEBBDowODA2BggrBgEFBQcwAYYqaHR0cDovL29jc3AuYXBwbGUuY29tL29jc3AwNC1hcHBsZXJvb3RjYWczMB0GA1UdDgQWBBQj8knET5Pk7yfmxPYobD+iu/0uSzAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFLuw3qFYM4iapIqZ3r6966/ayySrMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly9jcmwuYXBwbGUuY29tL2FwcGxlcm9vdGNhZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjAQBgoqhkiG92NkBgIOBAIFADAKBggqhkjOPQQDAgNnADBkAjA6z3KDURaZsYb7NcNWymK/9Bft2Q91TaKOvvGcgV5Ct4n4mPebWZ+Y1UENj53pwv4CMDIt1UQhsKMFd2xd8zg7kGf9F3wsIW2WT8ZyaYISb1T4en0bmcubCYkhYQaZDwmSHQAAMYIBizCCAYcCAQEwgYYwejEuMCwGA1UEAwwlQXBwbGUgQXBwbGljYXRpb24gSW50ZWdyYXRpb24gQ0EgLSBHMzEmMCQGA1UECwwdQXBwbGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxEzARBgNVBAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTAghoYPaZ2cynDzANBglghkgBZQMEAgEFAKCBlTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAzMjMxMjUxMTdaMCoGCSqGSIb3DQEJNDEdMBswDQYJYIZIAWUDBAIBBQChCgYIKoZIzj0EAwIwLwYJKoZIhvcNAQkEMSIEIEVEuHwhsWe5uIwsKW5gVQI0Xhyf0M6/lrBz8PI4giL1MAoGCCqGSM49BAMCBEYwRAIgB22BvYA0nqs5LyDW73l8MSsGakrg67c7VCJRQ4vYkEcCIFK5OwvJybjf/HjjX2SfoBHJOatqCOzVPOvTTD9OfCWEAAAAAAAA","header":{"ephemeralPublicKey":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE5KCOrlXReZL8imQVIFtW/PiXJUxx8lssrNyloAiTiYBi5LVUqk81mhwgDVxNTqHDeuyhiqycy3k3C7WxZz0x3w==","publicKeyHash":"DJerlvkSPFYRVcmrQoTJ2o/B89bBfcoOgBIwZw0sWTo=","transactionId":"ea9438d447217155a1acaa8107d2504229972c7a935d0662aa90981bb131cc0a"}}", "type"=>"applepay"} permitted: false>, :returnUrl=>"broadkaztapp://", :shopperEmail=>"[email protected]", :merchantAccount=>"BroadkaztTechnologyECOM", "additionalData"=>{:allow3DS2=>true}, "channel"=>"iOS"}

Response:

<Adyen::AdyenResult:0x0000559e95c78c90 @response={"status"=>422, "errorCode"=>"5_002", "message"=>"Invalid Apple Pay Token", "errorType"=>"validation"}, @Header={"date"=>"Tue, 23 Mar 2021 12:56:57 GMT", "server"=>"Apache", "set-cookie"=>"JSESSIONID=CF55AB152D2107FC769069F28863A39F.test8e; Path=/checkout; Secure; HttpOnly", "pspreference"=>"861616504217222C", "transfer-encoding"=>"chunked", "content-type"=>"application/json;charset=UTF-8"}, @status=422>

Google Pay:

Request:

{:amount=>{:currency=>"NOK", :value=>22900}, :reference=>"cart name: - [email protected]", :paymentMethod=><ActionController::Parameters {"type"=>"paywithgoogle", "googlePayToken"=>"{"signature":"MEUCIQD4D+eri2UEohnpqfvAdlrqFLzm1n8yRgjxDugiK6XBAAIgCJMLxqwq40Br8vpgyN3+AR/QooQOULtXYh5ph0A63kY\u003d","protocolVersion":"ECv1","signedMessage":"{"encryptedMessage":"dZVnIwT6ymAhSZbACz7a4dW3U9ENSvVo7086VjMsXZyFJIha8fRaiFH8kzwRZEPPQv2i0tnziih69jCStl1n26b2wFIw9MHmSZhQp694QfO/bHry18r1pfkwdXURj5vjaJKPBO+7JGatp8NFJthbJTThdpk9IACocX9pZ33iCbLw/NjNtWbr3SFggc7U0zcUb6CDl4mrED4gft+qaEg2eXwsU7AQStQUVmSLwYge+/Xk6d3z0oi9NEM5+cde48AHpSMToGWIUyKxKbhNQUe3lXwnYvOf94b4kFZJJRfOhq5Gdk7Lz3/u4B4AkzgNf03Cch5ECclADqxmLZ/pPpoCvnL4XvOkqQ9pcKMWgKEfrbsEMEAojahlnw0+Mj8eZbLgzvFYK10N7H6luonO22whAqgumvVUI45i5OdSz4UVnY/AHUNFI9/VOWkEU3PeH2BA99TsAA11Q+ml999lhLwQ6USaKfhVisO4jb4uP8sIYQU3BCP9QJyxBg8js+kKr5ASEJWIIN6BdS30rwJMYxsAHsSzzfrQ+H1+KrMI2y74EXFVdz8mIqcb7IUNTY1F9cwrQKg0xZR1e5BP8KY5r06q6twHGCMGRfrj+05i","ephemeralPublicKey":"BEpHhkSW5+bV4kk7j7zRricjhbyzYNEaCr4ycjNdmMI9ZOF7C+S37E8ElvqNdtpMxqUgP8Ckzui0B1mAKcSOTSk\u003d","tag":"O1DpCJ9HzhaqQXJg8qPPLc4OP6s9bJUBFc0ehp3zIxM\u003d"}"}", "googlePayCardNetwork"=>"VISA"} permitted: false>, :returnUrl=>"adyencheckout://com.broadkazt", :shopperEmail=>"[email protected]", :merchantAccount=>"BroadkaztTechnologyECOM", "additionalData"=>{:allow3DS2=>true}, "channel"=>"Android"}

Response:

#<Adyen::AdyenResult:0x00007f0e101242e0 @response={"pspReference"=>"852616517595206J", "resultCode"=>"Authorised", "merchantReference"=>"cart name: - [email protected]"}, @Header={"date"=>"Tue, 23 Mar 2021 16:39:55 GMT", "server"=>"Apache", "set-cookie"=>"JSESSIONID=D1BB2049ECBAF4D9F0F13F9CB77A4757.test7e; Path=/checkout; Secure; HttpOnly", "pspreference"=>"861616517595019G", "transfer-encoding"=>"chunked", "content-type"=>"application/json;charset=UTF-8"}, @status=200>

Hi there,

We were hoping to take advantage of idempotency as described here but I don't see anything in the Faraday connection that would handle setting the header.

As this would be on a request level, maybe it could be fetched from request_data before setting up the connection and set the header if present?

Not sure if I should contact support or open an issue (feel free to close and redirect me)...

I feel like I'm missing something obvious. I'm using cards from this page:
https://docs.adyen.com/development-resources/test-cards/test-card-numbers#visa

This the error I'm getting and the request payload I'm sending:

# RESPONSE
{
  "status"=>422,
  "errorCode"=>"101",
  "message"=>"Invalid card number",
  "errorType"=>"validation",
  "pspReference"=>"881585609039675K"
}

# REQUEST
client.checkout.payments(
  paymentMethod: {
    type: 'scheme',
    card: {
      number: '4111111111111111',
      expiryMonth: '03',
      expiryYear: '2030',
      cvc: '737',
      holderName: 'Taylor Brooks',
    }
  },
  amount: {
    value: 104_15,
    currency: 'USD'
  },
  reference: '123456789',
  merchantAccount: '{{validMerchantAccount}}',
  splits: [
    {
      amount: { value: 100_00 },
      type: 'MarketPlace',
      account: '{{validAccountId}}',
      reference: '1234'
    },
    {
      amount: { value: 415 },
      type: 'Commission',
      reference: '4567'
    }
  ],
  additionalData: { RequestedTestAcquirerResponseCode: 1 }
)

With the new v5.0.0 release, it would be helpful to know what the breaking changes were.

ruby version: 3.0.0+
Library version: 9.2.0

The library provides only support for validating webhook payloads that include the HMAC signature in the request body AdditionalData (i.e. standard webhooks). There is no method to validate the HMAC signature of webhook payloads that include the HMAC signature in the HTTP header (.i.e banking webhooks).

Describe the solution you'd like
Provide a new function

Describe alternatives you've considered
Implement the HMAC validation in the application.

Note: I can try and send a PR later at some point