|
Sep 18
2009
|
Getting Real with RealexPosted by Dave in web development , security , realex payments , payment processing , online payments , ireland , e-commerce , Application Security |
The original Getting Real with Realex is a blog post by David Rice. In this Blog post David Rice explains how he is not 100% happy with his recently completed Active Merchant implementation using Realex Payments.
"After finishing this work, I’m not 100% happy with it. Why? Because for some reason, Realex decide to do things differently than all of the other gateway services. For no good reason either, as none of the differences I’m going to list below give any benefit to the customer."
David Rice highlights the following six differences between Realex and other providers:
- To perform any transaction it requires you create a unique identifier.
- To Capture, Void or Credit a transaction. You are required to supply an extra identifier as well as the standard (authorization code).
- To perform a credit, you need to supply a secondary password, if you have an automated system you need to store this password with your application just as you would with the primary password.
- There is no publicly available developer portal for implementation information, an account is required.
- There is no test gateway, only test accounts on the production gateway. Therefore, only people with an account can run the integration unit tests.
- They have a list of test credit cards that are sent out on a per-user basis. i.e. they don’t support the standard valid visa card numbers.
In my opinion, these differences are of benefit to the integration developer, the merchant, the customer and Realex. If you are viewing these differences in isolation from the point of view of a developer then it may seem like they are "for no good reason". If you look at the bigger picture while considering security and transaction integrity, you will see that they are important and serve a purpose. Here I will address each point in turn and explain why these differences are useful.
To perform any transaction it requires you create a unique identifier.
The unique identifier being referred to here is the unique order ID required for each transaction. Reconciliation of transactions between your records, your bank statement and your payment service providers records can be a difficult and time consuming process. Providing a unique identifier of your choosing, for each transaction can simplify this reconciliation process. You can record the details of the request sent to Realex and also the response received, in your own database linking them with this order ID. If your customers experience a problem you can easily find the details of the transaction using the order ID. I have worked with many different payment gateways and some of them do not allow you to specify your own unique identifier, instead force you to use one that they generate. Depending on the type of system that you are trying to build, the ability to be able to control the unique order ID can be very useful.
To Capture, Void or Credit a transaction. You are required to supply an extra identifier as well as the standard (authorization code).
The authorisation code is generated by the financial institution at the time of authorisation. This means, you can not guarantee that the authorisation code will be unique. Neither Realex or the merchant will have any control over it. As a result of this you must supply an extra identifier that is used by Realex to uniquely identify the transaction.
To perform a credit, you need to supply a secondary password, if you have an automated system you need to store this password with your application just as you would with the primary password.
The primary password is referred to as the shared secret. This is a form of authentication. It is used when generating the hash that must be included in every transaction that is sent to Realex. This is the method by which Realex can authenticate that the transaction came from the merchant. The secondary password is the refund password. This is a form of authorisation. The refund password indicates to Realex that the person performing the credit is authorised to to so. This refund password should not be common knowledge within an organisation. It should only be known to those who should be allowed to perform refunds. I would have serious concerns about implementing an automated system for doing refunds. Even if you have 100% confidence in your business logic and you are certain that refunds will only occur when they should, there will still be security concerns with such a system. In general, providing functionality, such as the ability to do refunds without requiring authorisation, is a bad idea. Even if the web application is running on an intranet, it will still be vulnerable to attacks. Examples of such attacks could be as simple as a rogue employee carrying out refunds to a card of their choice or something more complicated such as Cross-Site Request Forgery (CSRF). An external party could get you to view a site that you trust but contains malicious HTML which uses CSRF to carry out a refund. The advantage here is that the more sensitive crediting actions are only performed by persons designated by the merchant.
There is no publicly available developer portal for implementation information, an account is required.
I agree, this is valid point. In my expeience Realex are happy to work with developers, provide access to their developer resource centre and provide test accounts as needed.
There is no test gateway, only test accounts on the production gateway. Therefore, only people with an account can run the integration unit tests.
There are two points raised here. The lack of a test gateway may seem like an unusual approach, but if you are a developer integrating to a payment gateway, it has a number of advantages. Firstly, running against the production code eliminates the risk of possible differences between test and live environments. Secondly, switching from test mode to live mode is greatly simplified.
The second point raised is that only people with an account can run the integration unit tests. I can see the point David is making here and I am sure it is frustrating, but a counter argument would be, why should an organization allow unknown parties to access their test servers? Particularly when these servers are responsible for processing billions of Euro per year.
They have a list of test credit cards that are sent out on a per-user basis. i.e. they don’t support the standard valid visa card numbers.
The use of live credit card numbers in a test environment is a bad idea. Even if you just look at it from a compliance perspective, PCI DSS requirements are applicable, if the primary account number (PAN) is stored, processed or transmitted. Requirement 6.3.4 states "Production data (live PANs) are not used for testing or development".
As a developer myself I can understand the frustration that David Rice has experienced when working on the Active Merchant implementation. The chief principle behind the design of Active Merchant was the requirement for a simple and unified API to access different payment gateways. Getting the balance right between ease of integration and application security is always a difficult task. If the service in question is responsible for handling credit card information then I would prefer that the organisation implementing the service takes the side of application security over ease of integration. I think it is unfair to say that there is no good reason for the differences highlighted above. Hopefully after reading my post you will see that there are very good reasons for these differences.
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:
Yesterday I presented at the first Irish OWASP Application Security Conference. There were over 100 attendees and 
