Testing Payment Integrations in Ecommerce SFCC

Nowadays it is impossible to imagine our lives without the Internet and it is not just about social networks, messengers or online services that we use. Thanks to the World Wide Web, now we can get almost anything from anywhere in the world by making a purchase online in a few clicks. Provided the store's website is convenient, secure, and includes various payment and delivery options.

The growing popularity of online stores stimulates businesses not only to operate successfully, but also to grow at the speed of light. This also applies to online payment methods, which are evolving along with the market. Just a few decades ago trade was possible only in real life and payments were accepted only in cash, and today customers have a variety of payment options to choose from while shopping either online or offline.

Here’s the Table of Contents for you to skip to the part you’re most curious about:

• Online Payment Options for Ecommerce
• Basics About Payment Systems and Their Integration with SFCC
• Payment Integration Testing From The Perspective of The Website User
• The Main Areas of Payment Integration Testing Outside of The Website
• The Most Common Testing Challenges and Some Useful Tips

Online Payment Options for Ecommerce

Thanks to the continuous development of digital and banking services, there are different ways to pay for goods and services in ecommerce stores nowadays. All of them may vary in different parts of the world, but one remains immensely popular - the online payments take 41.8% of all transactions (Statista data).

Online payment systems can be divided into the following categories according to the type of payment: 

• credit/debit cards (the most common — Visa, MasterCard, American Express, Maestro);
• online payment systems (PayPal, Amazon Pay);
• services for offline payments, mostly in cash (OXXO Pay);
• e-banking (Sofort by Klarna, iDEAL, Giropay);
• e-wallets (Apple Pay, Alipay, Google Pay, WeChat Pay);
• payment deferral/payment in installments (Klarna Pay Later, Klarna Slice it, NewDay).

In response to the increasing popularity of online payments, the ecommerce business tries to provide as many opportunities as possible for end customers by integrating various payment services into their online stores. Each service, in its turn, has its own functionality and features of development, which must be taken into account at the stages of development and testing.

Let’s consider the aspects of testing payment services on the example of one of the world’s leading ecommerce platforms - Salesforce Commerce Cloud (SFCC).

Info. Salesforce Commerce Cloud (SFCC) - cloud-based software-as-a-service (SaaS) ecommerce solution previously known as Demandware.The global brands such as Carter's, Columbia, Converse, Crocs, Ecco, Fila, GoPro, HP, Hugo Boss, L'Oreal, Lacoste, Liebherr, Marks & Spencer, Mercedes-Benz, Mothercare, New Balance, Pandora, PUMA and many others operate on the basis of the SFCC. The platform is characterized by its reliability, flexibility, scalability and customization capabilities of individual components in accordance to business requirements.

Basics About Payment Systems and Their Integration with SFCC

Payment is a complex process that connects several services into one system to transfer payments from the buyer’s to the seller’s side securely. Nonetheless, it takes merely a few seconds while the system has time to process the transaction and send the result to the user. For better understanding, the payment flow and interaction between SFCC and payment services are illustrated on the scheme below.

Confirmation of the coherent work of the entire payment mechanism is the primary purpose of testing for a QA engineer.

So, the development of the integration starts with its connection. Although the development of the payment functionality is the main task for developers, it is important for the QA engineer to understand how services can be connected and how they interact with SFCC to build an optimal approach to testing.

There are the following ways to connect third-party services at the level of SFCC:

1. applying a ready-made cartridge (so called “out of the box” solution);
2. developing a cartridge from scratch.

Usually the need to build a cartridge from scratch appears very rarely. This method is quite expensive and requires extra time and money, which is not always a desirable option for business. In addition, a large number of payment services already have some ready-made cartridges, which are available on the SFCC Marketplace - developers just need to customize them according to the project requirements.

Worth to note. Using a ready-made cartridge does not mean that there will be fewer defects during the testing stage in comparison to the one developed from scratch. There are situations when a significant part of the cartridge needs to be developed or even redesigned to increase efficiency. Therefore, the QA engineer must carefully look for defects in the interaction of the SFCC and a third-party service. In addition, it is worth remembering that any problems that arise on the side of the service (for example, the broken login form on the provider's website) are the responsibility of the service, not the project team.

What concerns the operating features, the payment services may function as follows:

• as a direct integration;
• through the Payment Service Provider (PSP) that maintains work with multiple payment services at the same time (for example, Adyen or WorldPay).

Let’s take, for instance, a well-known service PayPal. It can function as a separate integration and this means that all payments will be processed on the PayPal side. Another option of implementation - PayPal can work through the PSP (for example, Adyen) and, accordingly, payments will be processed by this third-party service.

At the first glance, it might seem that managing all website payments in one place, especially if there is a variety of options, is the most convenient method. However, the final choice between the direct integration or PSP lies solely on the business side as it is based on many factors including financial benefits, personal arrangements, convenience and so on.

Payment Integration Testing From The Perspective of The Website User

There are two ways to embed payment services into ecommerce solutions based on the place of payment:

1. on-site payments - payment is made directly on the website of an online store without going to the service page (for example, payment by a credit card);
2. off-site payments - the user is redirected to the page of the selected service to complete the payment (for example, PayPal).

On-site payments are the best choice for businesses with a high amount of transactions. From the point of marketing psychology, a user that stays on the site is more likely to complete the payment having no distractions, while redirection to the other sites can be a little alarming. However, this method of integration forces the business to take care of all payment data security on their side, and make sure to install an SSL certificate.

The simplest example of the on-site payment is a payment by a bank card. Typically, a web page contains necessary inputs for a credit card, the data of which is then sent for processing to the provider. Another way to implement it is to integrate payment service widgets into the website pages using the iFrame technology. As a rule, the form of widgets is provided by the third-party service, and the development team needs to insert them into the proper website parts. The example of such a development in the SFCC is Amazon Pay. When a user authorises on the ecommerce website with Amazon Pay service during checkout, regular shipping and payment blocks are replaced with widgets that show user information stored in their Amazon account to complete the order payment.

What concerns the off-site payments, they possess the next advantages for companies:

• many payment services are well-known and have a high level of trust among their users (for example, PayPal or Klarna);
• such services are a ready-made solution for payment processing and are fully responsible for security and confidentiality of users.

The pattern of work for the off-site payments is quite simple: the site displays the checkboxes with an ability to choose a specific payment method on checkout pages. The user confirms the choice and is then redirected to the payment service page to complete the payment, and after this the user returns back to the store - to the order confirmation page.

Worth to note. Regardless of the integration method, it is worth remembering that payment services are directly accessible by the users of the online store. Everything related to the Frontend part of the website must be tested on all browsers and devices from the approved scope of the project. The visual aspects of payment methods are usually provided in the design or described in the functional specification of the project. Additionally, you should not forget about the validation of the fields, if the chosen payment type requires data entry (for example, credit card inputs), as well as to check the behavior of the website in case of a transaction error, broken service, return, failure etc. It is better to have its own script for each case and display the appropriate message if applicable - common courtesy in user experience.

The Main Areas of Payment Integration Testing Outside of The Website

The task of the QA engineer does not end with testing the successful order placement on the website from the perspective of a regular user. It is also important to ensure that all the required order data is displayed correctly in the SFCC Business manager and on the payment service side.

SFCC Business manager is, perhaps, one of the most important tools for storing and processing the data of all website orders. That is why it is extremely important to make sure that each successfully processed order has the appropriate order statuses, product data, order total, delivery and billing addresses, and other personal data of a user.

Among all the order data it is important to emphasize the correct calculation of the order total, because there are many factors that can affect it. The total cost usually consists of the total amount of all products in the order, taxes, delivery, packaging and may include other extra services of the company. In addition, the cost of delivery and taxation largely depends on the region. Some payment services, such as PayPal and ApplePay, allow customers to change the delivery address on the service side, so taxes and delivery cost should be adjusted accordingly. All these aspects make it incredibly important to check that subsequent costs are included in the order price correctly. 

Apart from the factors that increase the total cost, you need to consider the factors that can reduce it: sale prices, promo discounts or loyalty program bonuses. The standard promotions “out of the box” in the SFCC are:

• product level promotions;
• order level promotions;
• shipping level promotions;
• bonus products;
• coupons.

Applying each type of the discount to the order allows you to make sure that the final payment amount is sent correctly, and the user is charged the exact payment, especially if there are hundredths in a price (for example, such prices as 9.99). The same applies to the orders partially or fully covered by the loyalty bonuses.

Simultaneously with the creation of the order in the Business manager, the above mentioned data is sent to the payment service provider for payment processing. In fact, it depends on the status of payment, whether the order is considered successful or not. If all data is entered correctly and there is a sufficient amount in the user's account, the payment will be deducted. If any problems occur (for example, insufficient funds or suspected fraud), the transaction will not take place and the order in Business manager will be marked as Failed.

Along with payments, it is usually possible to perform other transactions with funds, such as cancellation, partial or full refund from the admin panel of the payment service. Such situations arise quite often in case of product return or absence of goods in a warehouse. Although payments are mostly managed out of the SFCC (sometimes the cancellation feature may also be available to the users in their personal accounts), data synchronization and its relevance are important for business continuity, as the SFCC is closely linked to other company services (for example, shipping prodivers, order management systems, etc.).

To provide synchronization, the payment service sends the notification in case of a change in payment status or a transaction, which allows to update the order data in the SFCC correspondingly. Each operation can cause its own behavior scenario, that should be described in the project documentation. Therefore, it is necessary to test the correctness of the processing of all possible events according to the project requirements. Lack of a well-established connection with the payment service can cause incorrect data transmission while placing an order, which in its turn increases the time to eliminate such errors. Lost time is lost money. 

The Most Common Testing Challenges and Some Useful Tips

In general, testing the third-party integrations is not always easy, but it is definitely interesting. The QA engineer should track many aspects of work of a payment system to provide a stable operation of the service in future. Regardless of the project complexity, one might encounter such challenges while testing:

• data processing - some symbols which are acceptable for the website may cause error during processing on the provider's side (for example, special characters [! # $% & '* + - / =? ^ _ `{|} ~] or emojis);
• payment processing error emulation, testing status codes of the service response - each service has its own instructions for such cases that you have to work with;
• testing of partial and full payment of orders by gift cards, loyalty program bonuses, credit funds, etc. - it is necessary to clearly specify and send the amount of money to be paid by a user;
• non-standard payment functionality such as a possibility to split payments - this method allows you to divide the payment of one order between several payment services at the same time and requires more attention to the exact distribution of the order total between the specified user accounts.

The challenges on the list are just some of the highlights that you often have to work with while payment integration testing. Many more unforeseen situations may occur during the active phase of development, but everything is possible to solve.

Finally, here are some tips that will be of use in any payment service testing:

• As a rule, payment services have detailed documentation for developers on development and testing. This documentation should become your handbook for the time of your testing.
• SFCC documentation is also an important artifact - many details about the connected cartridge can be there.
• Use mind maps and other visualization tools that are convenient for you if the integration seems to be too complicated. It helps to depict the payment process and the possible test cases (an example of such a mind map is below).
• It is impossible to test and predict everything, but there are the mandatory areas that must be covered by the test cases, and first of all it is order placement by all supported payment methods (happy path).
• The functionality of payment services is advanced and some parts of it may not be used by business at all. In order to not waste the precious time on the delayed or unnecessary functionality, you should always follow the list of project requirements and clarify them if necessary.
• And most importantly: in case of any unclear situations with payments during the testing process, do not forget to check the service logs and the browser console. This will help you to analyze the situation in more detail and describe the problem much better.

It is always exciting to work with payment integrations and it doesn't matter if you are testing them for the first time or for the hundredth time. Each time you may discover something new, improve your technical knowledge or develop a more optimal approach to testing. Although most of the functionality remains the same from project to project, there may be some situations which will require a quick response. The more experience you have, the better decisions you take.