Protx Gateway is broken for use with 3D secure
Elmo
Great job on ActiveMerchant, it's a great idea! I have however found a
bug in the Protx code.
The code in the parse method (below) in protx.rb is wrong for one very
important scenario and that is when processing transactions that are
subject to 3D secure verification (Mastercard Securecode or Verified
Buy Visa)
<pre>
# Protx returns data in the following format
# Key1=value1
# Key2=value2
def parse(body)
result = {}
body.to_a.collect {|v| c=v.split('='); result[c[0]] =
c[1].chomp if !c[1].blank? }
result
end
</pre>
Below is the fixed code. Since itis a private method it is not
possible to test it using unit tests. In my copy I have made this
method public so that I can test it.
<pre>
# Protx returns data in the following format
# Key1=value1
# Key2=value2
def parse(body)
result = {}
body.to_a.collect() do |v|
# Split response on '='
c=v.split('=');
# Initialise the key with the rejoined values in the rest of
the array
result[c.shift()] = (c.collect!{ |str|
str.chomp()}).join('=')
end
result
end
</pre>
Test method from protx_test.rb as follows
<pre>
def test_parse_can_handle_equals_sign
three_d_secure_response = "#{successful_response()}\n" +
"ACSURL=https://ukvpstest.protx.com/mpitools/accesscontroler?
action=pareq"
response = @gateway.parse(three_d_secure_response)
assert_equal("https://ukvpstest.protx.com/mpitools/accesscontroler?
action=pareq",
response["ACSURL"])
assert_equal("VSP Direct transaction from VSP Simulator.",
response["StatusDetail"])
end
</pre>
Sorry if I have broken any convention or etiquette rules.
Cheers
E
Cody Fauser
Thanks for discovering the bug. You can post your patch to the
ActiveMerchant bug tracker. Instructions for creating a patch can be
found at the bottom of our Guide to Contributing[2].
The best way to test this change in the code would be to mimic the
test_authorization_format test in test/unit/gateways/protx_test.rb.
This test overrides the ssl_post method in the ProtxGateway to return
a predefined raw response from Protx, which is found at the bottom of
the file in the method successful_response(). Then the test asserts
that the correct things happen. You should be able to change your test
quite easily.
Thanks again.
[1] http://code.google.com/p/activemerchant/issues/entry
[2] http://code.google.com/p/activemerchant/wiki/Contributing
--
Cody Fauser
http://shopify.com - e-commerce done right
http://www.codyfauser.com - blog
http://www.oreilly.com/catalog/rjsrails - RJS Templates for Rails
Elmo
I'll send over the bug fix shortly.
While I'm here. One of the things we would like to do with Protx in a
current project is use the REPEAT payment functionality that Protx
provide. Is this something that the AM lib could or should be extended
with in your opinion? If so then I'd be happy to contribute those
enhancements when we get round to them.
Regards
E
Cody Fauser
Is the REPEAT payment functionality a recurring payment system?
Elmo
reference to an initial payment. It does not require that credit card
details are submitted (again). There are however limitations. By
default only REPEAT payments up to the value of the original payment
may be made. If something called 'continuous authority' is enabled on
the merchant account (i.e. your Barclaycard Merchant Services account
for example) there is no such limit. There is also something called
REPEATDEFERRED which is just like an authorization but for a repeat
payment.
I have another question in relation to 3D secure. In rewriting my test
for correctly parsing a 3DAUTH response the question of whether a
3DAUTH response from Protx should be considered a successful response
or not. When using the following assertion 'assert_success(response)'
for example. I'm erring on the side of no. By my reckoning it should
be considered a failed response, which the client code should
interpret and respond to accordingly following a more in depth
investigation of what the cause of the failure is.
I guess that these two subjects should be two different discussions.
Regards
E
Cody Fauser
>
> Yes. It allows one to make recurring or repeated payments with
> reference to an initial payment. It does not require that credit card
> details are submitted (again). There are however limitations. By
> default only REPEAT payments up to the value of the original payment
> may be made. If something called 'continuous authority' is enabled on
> the merchant account (i.e. your Barclaycard Merchant Services account
> for example) there is no such limit. There is also something called
> REPEATDEFERRED which is just like an authorization but for a repeat
> payment.
We call these reference payments and we do them in ActiveMerchant in
the following way:
def authorize(money, creditcard_or_billing_id, options = {})
if credit_card_or_billing_id.is_a?(String)
# authorize with REPEATDEFERRED
else
# It is an actual credit card, so authorize as normal
end
end
trust_commerce.rb, payflow.rb, and pay_junction.rb are good to look at
as examples.
>
> I have another question in relation to 3D secure. In rewriting my test
> for correctly parsing a 3DAUTH response the question of whether a
> 3DAUTH response from Protx should be considered a successful response
> or not. When using the following assertion 'assert_success(response)'
> for example. I'm erring on the side of no. By my reckoning it should
> be considered a failed response, which the client code should
> interpret and respond to accordingly following a more in depth
> investigation of what the cause of the failure is.
>
So the response is actually just a URL to send the buyer to for 3D
Secure authentication? What is the flow for Protx after you redirect
the buyer to the 3D secure URL?
Elmo
diagram at the top of the page should give you an overview.
http://techsupport.protx.com/vspdirectcustom.asp
Regards
E