Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Two failing functional API specs #29

Closed
wvanbergen opened this Issue Aug 7, 2011 · 29 comments

Comments

Projects
None yet
6 participants
Owner

wvanbergen commented Aug 7, 2011

The following to API specs are failing:

  1) Adyen::API with an actual remote connection stores the provided ELV account details
     Failure/Error: response = Adyen::API.store_recurring_token(
     Adyen::API::SimpleSOAPClient::ServerError:
       [500 Internal Server Error] A server error occurred while calling SOAP action `storeToken' on endpoint `https://pal-test.adyen.com/pal/servlet/soap/Recurring'.
     # ./lib/adyen/api/simple_soap_client.rb:122:in `block in call_webservice_action'
     # ./spec/api/spec_helper.rb:53:in `start'
     # ./lib/adyen/api/simple_soap_client.rb:119:in `call_webservice_action'
     # ./lib/adyen/api/recurring_service.rb:36:in `store_token'
     # ./lib/adyen/api.rb:338:in `store_recurring_token'
     # ./spec/functional/api_spec.rb:61:in `block (2 levels) in <top (required)>'

  2) Adyen::API with an actual remote connection stores the provided creditcard details
     Failure/Error: response = Adyen::API.store_recurring_token(
     Adyen::API::SimpleSOAPClient::ServerError:
       [500 Internal Server Error] A server error occurred while calling SOAP action `storeToken' on endpoint `https://pal-test.adyen.com/pal/servlet/soap/Recurring'.
     # ./lib/adyen/api/simple_soap_client.rb:122:in `block in call_webservice_action'
     # ./spec/api/spec_helper.rb:53:in `start'
     # ./lib/adyen/api/simple_soap_client.rb:119:in `call_webservice_action'
     # ./lib/adyen/api/recurring_service.rb:36:in `store_token'
     # ./lib/adyen/api.rb:338:in `store_recurring_token'
     # ./spec/functional/api_spec.rb:70:in `block (2 levels) in <top (required)>'
Contributor

troessner commented Aug 8, 2011

Both specs are running fine on my machine - seems like a temporary failure to me. Unfortunately I can't hit "rebuild" on travis-ci...:-)

Owner

wvanbergen commented Aug 8, 2011

Are you sure? These tests won'r run by default; you need to create /spec/functional/initializer.rb with actual (test) credentials.
For this reason, these tests won't run on Travis CI.

Unfortunately, the 500 error response I am getting is not very helpful in pinpointing the issue.

Owner

wvanbergen commented Aug 8, 2011

Also, these tests have been failing for me for a long time, so it is not a temporary failure.

Contributor

troessner commented Aug 8, 2011

Haha, yeah, I read:

[!] To run the functional tests you'll need to create spec/functional/initializer.rb' and configure with your test account settings. Seespec/functional/initializer.rb.sample'.

but the output

Finished in 0.00451 seconds
1 example, 0 failures

tricked me into believing that it was ok..:-)

Anything I can do to help?

Owner

wvanbergen commented Aug 8, 2011

Not sure. I haven't implemented the API stuff myself, @alloy did. Maybe he can give you some pointers.

Contributor

troessner commented Aug 8, 2011

@wvanbergen, @alloy I'd be willing to look into this but since this seems to be a non trivial problem I'm not sure how soon I can get to that.

Maybe it would be best to disable the failing specs for now to make travis happy. I normally wouldn't suggest disabling specs but if they had been disabled / not working before we wouldn't loose test coverage anyways...

Owner

wvanbergen commented Aug 8, 2011

Travis is not failing on these tests because they will not run there. The Travis issue is something else and seems to be JRuby related.

Functional tests are disabled until you provide Adyen credentials which it can use to actually run the specs. We would need to share these credentials in this public repository if we want these tests to always run.

Collaborator

alloy commented Aug 9, 2011

I’ll look into these somewhere the coming week. Here's a ticket where there was some more discussion about this: #25

@alloy alloy was assigned Aug 9, 2011

Collaborator

alloy commented Aug 9, 2011

Owner

wvanbergen commented Aug 10, 2011

I fixed the failing tests on Travis. They were caused by regressions in Nokogiri 1.5.0 on JRuby. We now depend on Nokogiri 1.4.6 for JRuby to temporarily fix it, and I filed an issue for nokogiri: https://github.com/tenderlove/nokogiri/issues/514

Still to be fixed: the functional specs.

Owner

wvanbergen commented Aug 24, 2011

Now we have better handling of 500 errors with useful error messages, these failing specs should be easier to fix. :)

Contributor

troessner commented Nov 15, 2011

@wvanbergen, unfortunately not.
I created a valid initializer with our adyen account data, on executing the two failing specs I get:

https://gist.github.com/1367169

which basically says: security 010 Not allowed

Which probably even in SOAP land is a candidate for "most useless error message" ever.

This is the innocent looking request body:

https://gist.github.com/1367170

Ideas?

Owner

wvanbergen commented Nov 15, 2011

Useless message indeed, something in which Adyen excels.
The request body contains some escaped characters (e.g. \n), is that just the result of you pasting it here?

Other than that I am useless for the SOAP API. Ping @alloy. :)

Contributor

troessner commented Nov 15, 2011

Here's the complete request:

https://gist.github.com/1367328

The request body contains some escaped characters (e.g. \n), is that just the result of you pasting it here?

That's from the actual request - looks bogus, doesn't it?

Especially

[" recurring:elv\n payment:bankLocationBerlin/payment:bankLocation\n payment:bankNameTestBank/payment:bankName\n payment:bankLocationId12345678/payment:bankLocationId\n payment:accountHolderNameSimon 1321370481 Hopper/payment:accountHolderName\n payment:bankAccountNumber1234567890/payment:bankAccountNumber\n /recurring:elv\n"]

looks like an error.

Did these specs ever pass?

Owner

wvanbergen commented Nov 15, 2011

I'm not 100% sure, but I think they never did.

Contributor

troessner commented Nov 15, 2011

When I change

content = []

at https://github.com/wvanbergen/adyen/blob/master/lib/adyen/api/recurring_service.rb#L72

to

content = ''

the request looks a lot saner:

https://gist.github.com/1367403

However the response is still, uhm, suboptimal (or as I would put it: FUBAR):

https://gist.github.com/1367407

So still the good old: security 010 Not allowed

Contributor

troessner commented Nov 15, 2011

To be honest I am pretty sure this feature never possibly worked out.

I suggest that we throw it out until somebody submits a working, tested version of this feature.

In my last pull request: #35

I implemented the ELV payment as an ad hoc payment with no recurring token whatsoever.

This version is tested and we use it in production.

@alloy had some remarks regarding my pull requests, maybe we can bring to a state where we are all confident integrating it.

@wvanbergen wvanbergen closed this Jan 14, 2013

Contributor

joost commented Sep 18, 2014

I have the same 'general' error message (security 010 Not allowed).
Debugging however gave me an invalid generated SOAP XML document:

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soap:Body>
  <recurring:storeToken xmlns:recurring="http://recurring.services.adyen.com" xmlns:payment="http://payment.services.adyen.com">
    <recurring:request>
      <recurring:recurring>
        <payment:contract>RECURRING</payment:contract>
      </recurring:recurring>
      <recurring:merchantAccount>MyAccount</recurring:merchantAccount>
      <recurring:shopperReference>test</recurring:shopperReference>
      <recurring:shopperEmail>test@test.com</recurring:shopperEmail>
      ["        <recurring:card>\n          <payment:holderName>test</payment:holderName>\n          <payment:number>4111111111111111</payment:number>\n          <payment:cvc></payment:cvc>\n          <payment:expiryYear>2016</payment:expiryYear>\n          <payment:expiryMonth>06</payment:expiryMonth>\n        </recurring:card>\n"]
    </recurring:request>
  </recurring:storeToken>
  </soap:Body>
</soap:Envelope>

As you can see the XML string (got this from post.body in simple_soap_client.rb) seems to not correctly handle the Array?!

Any ideas?

Owner

wvanbergen commented Sep 18, 2014

I am fixing some issues with the test account here: #91

However, that should not cause your issue. How are you calling the method in Ruby?

Contributor

joost commented Sep 18, 2014

response = Adyen::API.store_recurring_token({reference: 'test', email: 'test@test.com', statement: "test"}, {holder_name: 'test', number: '4111111111111111', expiry_month: '06', expiry_year: '2016'})

@joost joost added a commit to joost/adyen that referenced this issue Sep 18, 2014

@joost joost Fixing wrong SOAP body in Adyen::API.store_recurring_token
See comments in #29.
471672d
Contributor

joost commented Sep 18, 2014

Dug a bit deeper and found that the created 'SOAP' is simple strings in lib/adyen/api/templates/recurring_service.rb (not very dynamic?).
Anyway the above pull requests fixes the formatting. On my Adyen test environment it still gives a Access to the specified resource has been forbidden 403 error.

Owner

wvanbergen commented Sep 18, 2014

So I did find a bug in the code. For some reason, Adyen still accepts the wrongly formatted XML. Opening a PR soon to fix it

Owner

wvanbergen commented Sep 18, 2014

I'd like to move to the REST API so we don't have to deal with these weird XML/string building exercises anymore. See #90.

Contributor

joost commented Sep 18, 2014

👍

Contributor

joost commented Sep 18, 2014

Looking at Recurring payments manual (v2.30) it seems recurring:storeToken is not/no longer available moved to another manual :).

Contributor

joost commented Sep 22, 2014

The 403 error was due to wrong configuration of the webservice user. Some kind of 'role' needed to be added. The call now works correctly.
THE END :)

jaemo commented Aug 27, 2015

@joost I know this is going back a bit in time but did you ever learn the nature of the role that was added to the webservice user? I am getting the same error while trying to set up a sandbox.

Contributor

joost commented Aug 27, 2015

Long time indeed. I think it was something we had to configure in the Adyen (web) backend. There you should change some stuff on your 'webservice user'.

Let me know if it works.

I ran into exactly this today. At least I know a lot of people with the same issue 👍 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment