Among the aspects of any e-commerce platform, payments occupy one of the most important positions. The Hybris payment gateway integration issue hides a lot of difficulties for developers with both the documentation and technical components. This article is intended to provide information on the payment process in SAP Commerce Cloud, its architecture, as well as integration methods. We will concentrate on the list of possible difficulties that may arise during the implementation of the payment module. Finally, you will learn through our use case example how to deal with a series of integration challenges.
Payments in SAP Commerce
SAP Commerce Cloud has a wide range of integration potential, due to which it is able to function with almost any payment gateway. This provides great popularity among the global PSP (Payment Services Providers) leaders. It is worth noting that Hybris payment integration is usually less complicated for a B2B company since, in such cases, it settles an account.
The payment process is available directly out of the box in SAP Commerce and includes the following stages:
- The client visits a site, chooses a product and preferred payment option, where the payment page appears.
- The page shows a form to pay for or contains a specific pop-up window with data displayed from PSP servers.
- The client enters billing information and confirms the payment.
- SAP Hybris payment gateway confirms the request for the payment process.
- Upon completion of the transaction, PSP returns information to the seller, while funds are held for this time.
- Depending on the merchant fulfillment process, payment can be settled immediately or when events occur, for example, when the order is ready for delivery.
Previously, invoices played a special role for making B2B payments. To integrate them with SAP, automatic billing and invoicing processes were developed. Now the number of B2B/B2C projects has significantly increased, alternative options appeared, so the necessity of paying invoices has gone. You should integrate the payment process out of the box with all the new options. SAP Commerce is designed to support only debit or credit cards. Its architectural model is quite simple; payment service sends a signal to the card service, which calls various commands from interface:
- partial capture;
- standalone refund;
- follow on the refund.
The payment data model consists of two parallel processes: credit card info is sent while the money remittance is made with at least one transaction entry code. These two processes form an order. Each of them can contain several payment objects: they allow saving information about multiple payments per order, additionally considering different billing addresses.
Having examined the nature of money transaction processes in SAP Commerce, let’s move on to the next section, where we will consider how best to approach the issue of integrating payment modules.
Hybris payment integration methods
There are three different methods of how you can integrate the payment module in Hybris. Each of them differs in terms of safety and amenities.
- Direct Integration. This method transfers the client when paying to the checkout page inside the site, and sends the data to the PSP by using the API. With this approach, the merchant assumes the security of the sensitive data of the client, for which you need to be certified PCI DSS. Besides, when choosing direct integration, we recommend that you conduct a third-party audit to check the PSP for compliance with the required level of security and quality.
- Hosted Order Page (HOP). This method redirects the customer upon purchase to a payment page of a third-party PSP to enter card details. This option is considered the safest since PSP is always PCI DSS (Payment Card Industry Data Security Standard) certified. Note that it can be redirected to another page as well as in a pop-up window. A complete redirect is usually safer.
- Silent Order Page (SOP). This method can be taken as enhanced Direct Integration. SOP also offers filling out a checkout form directly on your site, but instead of sending sensitive data via API, the system sends it directly to the payment gateway. Please note that during this period of time, a window appears for outside interference, since the sensitive data processed by the system is opened for third party verification.
This solution should be used for full control over transactions and full management of your own payment page. When identifying its pros and cons, it turns out that almost all of them are completely dependent on you and how technologically safe will be the environment you create. What you will not be able to influence is the almost complete impossibility of implementing a reduced level of client authorization.
Overall, Direct Integration is considered the safest method, which is why we at Aimprosoft choose to use it.
Of the HOP drawbacks, the most basic one is the dependence on the provider and the safety of its environment. If you fully trust it, this will not become a stumbling block, but if you prefer to rely on yourself first and foremost, HOP will not afford such luxury.
Each method has its strengths and weaknesses, so it is sensible to make a choice depending on the requirements and particularities of your project.
Pitfalls and challenges
When integrating a payment solution, difficulties of varying complexity and scale may arise, so let’s address the most common ones.
- Error handling
- Payment form improvement
- Omnichannel payments
Often, when entering incorrect data in the checkout form, such as a wrong CVV code, an error occurs, so an actual session is reset, as well as all the information entered. This negatively affects the user experience and reduces the credibility of the site. To avoid it, we advise you to enter the possibility of making an error with saving the entered data. It will be even more convenient to enable customers to edit and modify the order.
For maximum security, we recommend hiring an audit team for full-sized verification. In this context, you should pay special attention to OWASP top 10 and ESSL data interception connections.
This form should be simplified, and the support for various money remittance methods should be expanded. So, in addition to handling various providers, we recommend ensuring support for electronic wallets, as well as a money transfer system without a credit card.
The support and proper configuration of this system, consisting of sites, social networks, instant messengers, and offline terminals, is not easy at all but nonetheless very rewarding. To facilitate this task, we recommend using one processor for all your money remittance processes. With proper setup, you can achieve the ability to view all payments in one place, even if you pay in different ways (invoices, cards, mobile payments or cash on delivery). Thus, you will reduce the cost of maintenance and vendors, and in return, save time by coordinating transactions and centralized reporting.
The most important challenge in creating an omnichannel payments module is the first and foremost an operational rather than technical factor. Controlling all channels and dealing with threats like fraud across all of them can be a real challenge. To facilitate the work with the omnichannel option, you can centralize all payments in a single matrix structure and have an effective disaster recovery plan.
In addition, we recommend constantly patching your software and updating security solutions with the latest versions to counter sophisticated malware.
Our use case
There is no better way to delve deeper into SAP Hybris payment integration than giving an example of a use case from our practice. Let’s consider the B2C website of the famous retailer from California.
The customer needed to change the existing site in accordance with the new SA SOP (Secure Acceptance Silent Order POST) requirements, which led to a number of changes in the transactions. The scale of the changes turned out to be so large that it affected almost the entire payment mechanism of the site.
During payment integration in Hybris, we encountered a number of challenges. To begin with, we joined the project at one of its development stages, so our software engineers were dealing with the implementation and integration of the payment process into a stranger’s code. Consider contacting a team of professionals who will write a code of such quality that can be easily rewritten and understood by other developers. However, it is desirable that one team conduct work on the task from beginning to end.
Our specialists started work by investigating and analyzing the existing SA transaction flow, after which the following decisions were made:
- identification of SA profile for transactions;
- changes applied to the token creation process by using SA SOP;
- new payment flow implementation to use recent security behavior for stores that required it.
In addition, we were faced with the task of remaking PayPal through Cybersource. The site had only a direct connection between Hybris and PayPal. We were instructed to insert Cybersource into this flow and only after its own verification, the data had to be sent further.
The creation and change of commands in PayPal was necessitated by a chain reaction to the modification of related processes. For example, one of them was order processing flow, which required modification after the ”capture” command appeared.
The checkout needed a massive overhaul. The client could not use the standard SAP Commerce Cloud checkout solution, so a new logic was implemented, and refactoring was performed. We have implemented traditional checkout: one-step at that time, it was modified to multi-step as a single-page app.
Paypal refactoring required from our developers implementation of:
- new classes for new service calls usage;
- several changes for using new CyberSource services and classes;
- re-authorization and refund.
In addition to the whole payment operations restructuring, we had to make minor corrections:
- pick-up in store, which consisted of redoing orders. It has given a choice to the user of the delivery location for personal pick-up;
- creation of service to find store by geolocation;
- localization for different countries and related changes in payment features. Japan has become a particularly difficult issue because the state of content data in the project was inconsistent.
The final result was a successful restart of the site complied with all the safety and quality requirements of the payment system, as well as continued cooperation with the client on other projects.
When creating your commercial project, you inevitably will face Hybris payment module integration. In this article, we tried to illuminate all the shaded issues and reveal the disguised pitfalls so that your experience in working with it will be successful. To achieve maximum operational efficiency in a payment solution, contact us — we have hundreds of integrations in Hybris behind, and can help yours be the same high level of quality.
You may also want to read