Skip to content
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

malformed params returned on verification error via Transparent Redirect #38

Open
eostrom opened this issue Mar 21, 2013 · 4 comments
Open

Comments

@eostrom
Copy link

eostrom commented Mar 21, 2013

I don't have a minimal test case for this yet, but I wanted to get some notes down on the behavior I'm seeing.

Given I have turned on verification:

FakeBraintree.verify_all_cards!

When I submit a TR request with an "invalid" credit card number ("1234123412341234"), I get back an error result with a string where the params hash should be:

(rdb:1) p result
#<Braintree::ErrorResult params:{...} errors:<> credit_card_verification: #<Braintree::CreditCardVerification status: nil, processor_response_code: nil, processor_response_text: nil, cvv_response_code: nil, avs_error_response_code: nil, avs_postal_code_response_code: nil, avs_street_address_response_code: nil, merchant_account_id: nil, gateway_rejection_reason: "cvv", id: nil, credit_card: nil, billing: nil, created_at: nil>>
(rdb:1) p result.params
"\n  "

Weirdly, result.inspect suggests params is a hash, but result.params is a string. I'd expect it to be a hash of the user-submitted params, which I can use to repopulate the form.

(I don't know why it's saying the rejection is due to "cvv"; AFAIK it's only the card number that's invalid.)

I looked at the situation from within FakeBraintree::Customer#failure_response:

/Users/eostrom/.rvm/gems/ruby-1.9.3-p194@iowl/gems/fake_braintree-0.2.1/lib/fake_braintree/customer.rb:164
gzipped_response(code, FakeBraintree.failure_response(credit_card_number).to_xml(:root => 'api_error_response'))
(rdb:2) p FakeBraintree.failure_response(credit_card_number)
{"message"=>nil, "verification"=>{"status"=>nil, "processor_response_text"=>nil, "processor_response_code"=>nil, "gateway_rejection_reason"=>"cvv", "cvv_response_code"=>nil}, "errors"=>{"errors"=>[]}, "params"=>{}}
(rdb:2) p FakeBraintree.failure_response(credit_card_number).to_xml(:root => 'api_error_response')
"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<api-error-response>\n  <message nil=\"true\"/>\n  <verification>\n    <status nil=\"true\"/>\n    <processor-response-text nil=\"true\"/>\n    <processor-response-code nil=\"true\"/>\n    <gateway-rejection-reason>cvv</gateway-rejection-reason>\n    <cvv-response-code nil=\"true\"/>\n  </verification>\n  <errors>\n    <errors type=\"array\"/>\n  </errors>\n  <params>\n  </params>\n</api-error-response>\n"

I don't know if that's how an empty hash should be encoded to XML (it doesn't seem to be decoded properly, by whatever's decoding it), but I don't think the params hash should be empty in the first place.

I'm using Ruby 1.9.3, Rails 3.2.12, Braintree 2.22.0, Fake Braintree 0.2.1, and obviously a bunch of other gems. I'd appreciate any informed suggestions about where the trouble might be, or how to figure that out.

@eostrom
Copy link
Author

eostrom commented Mar 21, 2013

... Actually, looking a little deeper, it's obvious why params is empty: FakeBraintree.failure_response hard-codes the empty params (and the "cvv"). I would like to change this so I can write an integration test for verification errors, but I'm not sure how to go about it.

@gabebw
Copy link
Contributor

gabebw commented May 24, 2014

Ah, yeah. I'll look into this!

@scottymac
Copy link

+1 for this. Just ran into it. I'm using the BraintreeFormBuilder and it expects those params to be available in the result object so that it can re-populate fields following an error.

@gabebw
Copy link
Contributor

gabebw commented Dec 10, 2014

Just an update: I'm aware that this is still an issue, but haven't had time to look at it yet.

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

No branches or pull requests

3 participants