3D secure functionaility
Simon Tokumine
I see that there has been some discussing about 3D secure (Verified by
Visa/ Mastercard SecureCode) implementation and protx already[1]. I've
recently completed upgrading an old PHP site of mine to 3D secure, and
am looking to port the implementation to AM. Before I start though, is
there any work going on this front already that I can contribute to/
help? Either "official" or not, I don't mind as long as the outcome is
good - I'd rather be as DRY as posible with payment gateway coding ;)
Many thanks,
Si
[1]
http://groups.google.com/group/activemerchant/browse_thread/thread/10fbbe7caa9391c1/cb3b88fdda5d8ffd?hl=en&lnk=gst&q=protx#cb3b88fdda5d8ffd
Steve
We are currently with an excellent payment gateway called
SecureTrading in the UK but are thinking of switching to Protx as it
is supported by AM.
However from what I've read AM's support for Protx is sketchy and
especially because 3D Secure is required for all Maestro
transactions...
So if you want do work on 3D-secure for Protx on AM I would be very
interested to share/contribute!
Steve
On Jul 2, 1:28 am, Simon Tokumine <si...@japancentre.com> wrote:
> Hi all,
>
> I see that there has been some discussing about 3D secure (Verified by
> Visa/ Mastercard SecureCode) implementation and protx already[1]. I've
> recently completed upgrading an old PHP site of mine to 3D secure, and
> am looking to port the implementation to AM. Before I start though, is
> there any work going on this front already that I can contribute to/
> help? Either "official" or not, I don't mind as long as the outcome is
> good - I'd rather be as DRY as posible with payment gateway coding ;)
>
> Many thanks,
>
> Si
>
Cody Fauser
--
Cody Fauser
http://shopify.com - e-commerce done right
http://www.codyfauser.com - blog
http://peepcode.com/products/activemerchant-pdf - ActiveMerchant PeepCode
http://www.oreilly.com/catalog/rjsrails - RJS Templates for Rails
Ed W
> Doesn't SecureTrading require you to run a Java client on your servers?
>
>
Possibly why he wants to move to Protx...
Anyway, his question was on 3D secure. The basic idea is that after
what looks like a normal request to process a card, instead of getting a
success/fail you actually get a redirect response. You redirect to that
new site which does some additional authentication and finally arrive
back on your site again.
Clearly not to hard to customise as a one off to handle Protx or
whatever, but the question is whether AM will evolve to handle this
within the API? I guess it blurs the boundaries between the integration
and payment type gateways? To a large extent we seem to be moving
towards a bit of both kind of situation?
Ed W
Cody Fauser
something like an authenticate() method on the gateway that takes the
buyer's details and returns the URL for redirection.
The buyer is then redirected to the 3D Secure website and logs into
their account. 3D Secure website then returns the buyer back to the
checkout with the information from the bank like the CAVV, etc.
Finally the normal purchase() or authorize() method is called with the
additional 3D secure data returned from the bank.
PayPal Payflow Pro seems to have a great implementation:
https://www.paypal.com/en_US/pdf/PayflowPro_FPS_Guide.pdf, but it
seems some services like Protx try to make the entire process more
"simple" and as a result make it harder to abstract a generic
solution.
It think the best way to get started would be to implement Payflow Pro
as a reference because they have great documentation, a good
implementation and a good test environment. Then we can try and
shoehorn the other gateways into that.
--
Steve
My partner implemented the Securetrading gateway about 2 years ago and
thinking about it I think it does use a JAVA client.
The reason I am considering switching to Protx is just because I
didn't want to spend too long writing XML interfaces again in ROR and
would rather not reinvent the wheel and use AM.
Cody - I have only just downloaded the AM plugin - have read your
'Process Credit Card Payments' recipe in Advanced Rails Recipe - but
getting this error on Protx gateway.
>> p = Purchase.create(:amount => 1, :description => "test", :order => '123', :credit_card_id => 3)
NoMethodError: undefined method `name' for #<CreditCard:0x212df20>
Looking under the hood it seems the 'name' method is defined in /
billing/credit_card.rb
Am I supposed to include that in my credit_card model? You include
ActiveMerchant::Billing::CreditCardMethods only in your CreditCard
model in your recipe.
I'm going to look through the rest of the source code later but it
would be helpful if I'm missing something simple :)
Another thing... if we do store credit card details does it HAVE to be
on two separate applications/servers as you have it in your recipe? Is
it required by the PCIDSS? I thought it just requires some sort of
encryption...
Steve
Ed W
> I've looked a lot into this problem and the ideal solution is to add
> something like an authenticate() method on the gateway that takes the
> buyer's details and returns the URL for redirection.
>
> The buyer is then redirected to the 3D Secure website and logs into
> their account. 3D Secure website then returns the buyer back to the
> checkout with the information from the bank like the CAVV, etc.
>
> Finally the normal purchase() or authorize() method is called with the
> additional 3D secure data returned from the bank.
>
> PayPal Payflow Pro seems to have a great implementation:
> https://www.paypal.com/en_US/pdf/PayflowPro_FPS_Guide.pdf, but it
> seems some services like Protx try to make the entire process more
> "simple" and as a result make it harder to abstract a generic
> solution.
>
I'm going to bow to your experience having not studied the Paypal
gateway, but I *think* one of us misunderstands the protx flow (no
disrespect intended - it's probably me!)
My understanding of the protx "direct" process is that you
a) collect the CC details from the customer
b) post them directly to Protx which decides if the transaction is good,
if the customer is enrolled in 3D and if you setup the rules to do so
decides to continue with a 3D auth. It might return you success/fail at
this stage, but otherwise returns you a URL to redirect the customer to
and a unique ref code, plus a security hash
c) you redirect the customer to the banks 3D page + the magic extra
digits and also the return URL
d) bank redirects the *customer* back to your URL (no direct auth from
the bank - question: what happens if the auth is successful but the
redirect back fails?)
e) App then posts back to Protx for final verification of the results
from the 3D secure and the results of that post are basically as per b)
above in the case of no 3D requirement, ie c)-e) are the 3D callout process
In contrast they also offer Protx "server" option which is a halfway
house (and attractive to me). Here they basically offer to run steps
a)-e) above for you and let you know the results - they give you a
reference to the transaction to then issue repeats/voids, etc. This
seems very attractive because the site *doesn't* need to be PCI
compliant to use this process (cool)
The process flow here is:
a) direct post to Protx to setup the transaction, result is a URL to
redirect to
b) redirect customer to protx which does all the heavy lifting on
templated pages of your choice (make it look like your site, etc), and
finally directly posts the result (success/fail, etc) back to the URL of
your choice
c) you answer the post with some info including the URL you want the
customer redirected to
d) Protx redirects the customer back to your site via the URL in c)
The point of describing the above is that I would like to implement this
in AM. Can you offer an opinion if this is best done as an integration
or as per Protx "direct"?
Curiously if you use the method above, you can still use Protx "Direct"
for all the advanced stuff like repeat transactions, voids, etc.
Basically they are just letting you outsource the CC collection screens
Grateful for your thoughts
Ed W
mrbmo...@googlemail.com
Have you had any luck with this yet, or any good pointers? I'm just in
the first stages of looking into adding 3D secure to AM for a Protx
implementation.
Many thanks,
Ben
>
> I see that there has been some discussing about 3D secure (Verified by
> Visa/ Mastercard SecureCode) implementation and protx already[1]. I've
> recently completed upgrading an old PHP site of mine to 3D secure, and
> am looking to port the implementation to AM. Before I start though, is
> there any work going on this front already that I can contribute to/
> help? Either "official" or not, I don't mind as long as the outcome is
> good - I'd rather be as DRY as posible with payment gateway coding ;)
>
> Many thanks,
>
> Si
>