|
Oct 07
2009
|
Getting Real with Realex (Part 2)Posted by: Dave on Oct 7, 2009 Tagged in: web development , security , realex payments , payment processing , online payments , e-commerce , Application Security
|
|
This post is a follow up on the discussion with David Rice surrounding Realex Payments Integration. In my original post I addressed the 6 issues raised by David Rice in his blog post getting Real with Realex. David Rice has since updated his post to clarify and expand on some of his points while also addressing some of my comments. An important update that David Rice has made relates to his initial comment saying:
"For no good reason either, as in my opinion none of the differences I’m going to list below give any benefit to the customer."
David Rice has updated the post to clarify that he is looking at it from "the standpoint of someone integrating payment solutions into a SaaS application with the goal of it being easily used with a different merchant per client."
This clarification changes my view of his article. I have to agree with most of David Rice's points when you look at them solely from the point of view of creating an abstracted payment gateway implementation. I strongly feel that my arguments stand as payment gateway integration is only one of the many factors that you will consider when choosing a payment service provider. In my previous post I outlined why the use of a secondary password for credits is useful in terms of security. In his updated post David Rice explained that:
"In the context of a back office application I think that encapsulating this as part of your own application logic and only allowing certain users to perform refunds is better from a usability standpoint"
I agree that only allowing certain users to perform refunds is the correct approach for reducing the risk of fraud within an organisation but this does not provide any protection against vulnerabilities such as Cross Site Request Forgery (CSRF). I mentioned CSRF in my original post but I did not go into any detail on how such an attack could be executed. I will do a blog post over the next few days with an example to explain how such a CSRF attack could be executed in this environment.
To conclude if you consider the 6 issues highlighted by David Rice only from the perspective of creating an abstracted payment gateway implementation then they are valid arguments. In the real world you will not choose a Payment Service Provider based solely on how easy it is to create an abstracted payment gateway implementation. My aim with my two blog posts on this subject was to show that there are reasons why things are implemented in this manner. It is always going to be a difficult task to get the balance between security, usability and ease of integration right. I have enjoyed the discussion with David Rice on the various issues and it has helped me to see things from a different perspective i.e. usability and easy of integration. I hope David Rice and the readers of this Blog have found the discussion informative - you can see both arguments for each of the issues highlighted.
Dave
--
If you liked this article then you can:
- Subscribe to our
Blog RSS feed - Become a fan of webpayments.ie on Facebook
- Follow us on Twitter
Related Blog Posts:
written by David Rice , October 08, 2009
Hey David,
Thanks for continuing the discussion.
On your now repeated point that I'm solely focusing on implementation I would have to disagree with you. I work on a high level with businesses on the architecture of solutions which always have valid business reasons behind them
I agree, protection against CSRF should be on anyones list if they're involved with web applications. In general though, Software as a Service applications will make heavy usage of Authentication and Access control patterns as well.
I would also say about your point that in the "real world" people would not use this as their reason for choosing a gateway provider... that this is the real world and I have already demonstrated that there is a business need, not just to create as close to perfect an implementation.
Granted, the majority of Realex's customers will most likely never have this need, but some potential customers will and they are in danger of going elsewhere because less development spend is required.
The whole premise for my article was not to knock, but to inspire and set out good reason why there may be some customers Realex could gain by taking some of those points on board. Particularly as I am intrinsically more likely to try and support an Irish provider with my business than give it away to someone else.
Thanks.
Dave
written by dave lowry , October 08, 2009
Hi Dave,
Thank for your comments. In relation to the "real world" comment I do not think I phrased it correctly in my post
What I was trying to emphasise was that for the majority of merchants ease of integration will only be one of many factors that they will consider when choosing a payment gateway. For some merchants price may be the most important factor, for someone else it may be reliability. I agree that in the example you have described (which is a real world example) the business needs dictate that ease of integration must be the key factor in that decision. I had viewed your article more of a criticism than an inspirational piece, though reading your post again in light of our discussions I can better see what you were highlighting. Thanks for keeping in contact on this, I thoroughly enjoy such good discussion.
Thanks,
Dave
written by osearcaigh , October 09, 2009
Hi guys, I've been following this with great interest. I'd be interested to follow both your opinions on the pros and cons involved in choosing a provider, apart from price and features, more regarding security versus ease of use and ease of implementation, seems between you there's a lot of knowledge.
I've started a forum post if you'd like to continue the discussion:
http://webpayments.ie/index.php?option=com_ccboard&view=postlist&forum=1&topic=26
