In my experience with IBM Websphere Commerce projects I had a chance to integrate web stores with many payment systems like Klarna, Nets, Arvato and few others. Proper integration of payments is a key element of web store checkout flow. I’d like to share my thoughts about it.
First of all when you starting integration get familiar with an external payment system. Third party’s payments provider usually exposes API, either SOAP or REST services. Try it step by step. A useful tool is SOAP UI, which helps you to perform test requests to payment backend. Usually you need to ask for test credentials required for authentication. Some payment providers offer additionally web interface for transaction monitoring and other management functions.
When you are sure you understand external system API and you are able to place sample transaction then you can move to the implementation phase.
It’s a good idea to have an implementation that is a reusable component. I suggest creation of new Java project that will be responsible for communication with backend payment system. For SOAP API web service client java code (JAX-WS) can be generated based on WSDL file of services. Eclipse RAD has powerful Wizard for web service client code generation.
For REST API services client implementation it is recommended to use Java HTTP transport library. A good choice is Apache HTTP-Components Client library. It covers all HTTP methods implementation (GET, POST, PATCH, etc.). It also supports most of the widely used authentication methods (Basic, Digest, NTLM, etc.).
Usually we define facade interface, which contains all business methods needed for payment fulfillment. Another issue with REST API client is processing of the response. Some services use JSON as output other use XML format. While in Java we usually expect objects thus we need conversion mechanism. For JSON processing we can use JSONObject class from Apache Commons. For processing XML response good choice is JAXB, which is available in JDK 1.6. Consider also proper handling of error responses. It might be useful to define custom Java Exception to wrap up failure cases.
Business methods from client facade take some arguments that hold information required by the system to initiate the payment transaction. These are usually data related to order details and shipping or billing address. I suggest using suitable Data Objects for that purpose. Depends on the case it can be custom POJO class. For SOAP services, generated object types can be used. It is important to keep client implementation separated from Websphere Commerce Data Access Objects. For that reason we need some additional business logic in Websphere Commerce.
Let’s implement helper classes for extraction of all the data needed for transaction fulfillment. Use dedicated Websphere Commerce DataAccessBeans to retrieve order details, address details and other necessary information. Encapsulate extracted data in POJOs. That will be the glue between web service client and Websphere Commerce. Another area of implementation may be custom DataBean or Commerce Command for backing UI frontend.
Establishing a connection with an external service requires additional information like URL, user credentials etc. Such information is usually stored in the database. We can use default WC table STORECONF to store configuration properties. Data value for each property can be easily loaded via XML files. In Java application it’s possible to retrieve store configuration properties via the registry. The StoreConfigurationRegistry is a cache for the STORECONF table. When more properties are required, create a wrapper object for all of them.
Payment integration may require store frontend changes. Some payment systems need customization of shopping cart page, other expects changes of UI checkout flow pages. Each case must be analyzed separately. In most cases web front is based on Websphere Commerce reference Aurora store. Below you can see additional payment form embedded on shopping cart page.
Most of the professional payments providers offer secure services. That means communication over HTTPS and SSL certificates. These require additional configuration steps with the application server. Please use IBM WAS Admin Console to add payment service host, port and alias to retrieve SSL certificate.
The good code is testable code. It’s nice habit to cover main implementation facade with tests for each business method (request type). Let’s use jUnit framework for implementation of tests. You can either run tests with mock services or real services. For mocking of SOAP or REST services use already known SOAP UI. Consider tests for failure cases as well.
Ready-made web service client implementation with tests is a great foundation for later plugin development.
See what we have to offer - Careers