Overview

Introduction

The ecommpay payment platform allows you to process different types of payments almost everywhere in the world with support for a wide range of currencies, payment methods, and payment scenarios. It relies on exceptionally thought out and organised processes and high-performance computing resources, which, from the technical standpoint, makes the platform an advanced information system—state of art, high-integrity, and efficient. Thanks to this, all required actions in the platform are executed in milliseconds while merchants and their customers can expand ranges of services they offer and enjoy high quality performance of the platform.

Figure: Processing payments via main interfaces of the platform

At the same time, the scalability of the ecommpay payment platform, with its plethora of capabilities and use options, leads to a wide range of ways of how merchants can work with it. This makes the interaction with the platform convenient and efficient, but it can also be challenging, for example, when the merchant needs to find the most optimal solution that fits the merchant's business needs. To make sure that your questions about working with the platform are answered, you can use this documentation portal (including the documentation survey on the home page). You can also contact your account manager and the technical support.

Key concepts: projects and payments

While the integration workflows and scenarios can vary, working with the platform starts with registering in it a specific merchant and a project of interaction between the merchant's web service and the platform. Along with that, the project is assigned a permanent identifier, and a wide range of customisable properties is set up for it. These properties include support for payments methods and currencies and various parameters that determine payment processing workflows and procedures. Once this has been done (and only then), it is possible to process payments in the project of the merchant, with payments defined as compound actions performed to carry out transfers of funds between merchants and their customers.

The number of projects set up for one merchant can vary. Most often, one project is enough, but in certain cases, the number of projects can increase. As a rule, the optimal number of projects is determined by the ecommpay specialists on the basis of the merchant's business specifics and goals. More importantly, this number can be changed in the course of collaboration with ecommpay.

As for payments, they can include a different number of operations that have to do with the transfer of funds. For example, within one payment, first a purchase takes place, and then—a full or partial refund. As another example, a series of regularly recurring debit operations for a fixed amount is processed within one subscription payment. And so on. Available payment types, operations, and their statuses are strictly defined in the platform and are described in this section. Meanwhile, as you read, it is important to keep in mind that payments are processed within projects and can include a varying number of operations.

Overall, this logic—that to work with the platform, the merchant's project needs to be registered and that within these registered projects payments are processed and include a certain number of operations—can be considered the basis for understanding the interaction with the platform. It applies to all actions in the ecommpay platform starting from test integrations and processing test payments and ending with distributing permissions for accessing information about individual payments and operations by individual projects.

Tools: interfaces and components

To work with the ecommpay payment platform, you and your web service can use specialised interfaces each of which allows you to achieve specific business goals. These interfaces include:

• Payment Page—the payment form developed by ecommpay that is invoked via an API and allows you to process purchases and perform other actions with the use of various payment methods.
• Gate—the payment API that provides you with the largest range of capabilities for working with payments of all supported types and payment methods and implies that your web service utilises in-house UI solutions.
• Dashboard—the web interface for your employees that allows them to configure projects, including the interface of Payment Page, and to monitor the state of all payments (processed and in-progress), to manage their execution, and to initiate various payments and operations.
• Telegram bot of the ecommpay technical support—a solution that complements interaction via Dashboard and allows you to receive information about payments with recommendations for further actions in case of declines. It also forwards your inquiries to the ecommpay specialists using the Telegram messenger.
• Data API—an API that allows you to retrieve information about operations, chargebacks, and balances for the projects in use. It also helps you establish the workflow of monitoring and analysing payment processing outside of Dashboard (for example, in the external BI system).

At the same time, for more convenient ways of working with the platform, you can also use additional components—self-contained software products that can be implemented in the web service to achieve specific goals. These components include:

• SDKs for mobile applications—software development kits (SDKs) to integrate Android and iOS applications with the ecommpay payment platform. Merchants can use a special version of Payment Page or their own user interface.
• Integration modules for CMS—plug-ins (certain systems refer to them as cartridges) that help connect the merchant's web service created in a popular CMS system or a specialised ecommerce platform to the ecommpay platform.
• SDKs for data signing—language-specific specialised software development kits (SDKs) that facilitate signing data sent in requests and verifying data integrity in responses and callbacks in the API interaction with the platform.

Finally, there is also a Telegram bot for processing payments: it is a specialised bot embedded in Telegram that allows merchants to process payments through the interaction of the merchant bot with the Telegram messenger and the payment form of ecommpay.

Together these interfaces and components serve as tools that allow merchants to work with the platform. In different cases, this work can be organised with the use of a different number of tools. Thus, sometimes a task can be completed by using one interface (Dashboard), and in other cases, using SDKs for mobile applications and data signing, Payment Page, Gate, Dashboard, and the Data API can be more effective. As a rule, the key factors affecting the choice of this or that tool include payment types and user scenarios, web service development methods, and the preferred ways to organise work with the platform. These factors, for example, are taken into account in the responses that are given as a result of taking our survey available on the home page. Similarly, when the ecommpay specialists help you find the most optimal solutions for your business, these factors are taken into consideration as well.

Capabilities and procedures

Capabilities of the ecommpay platform are diverse and, more importantly, are supported to a varying degree with different tools. Thus, Payment Page allows you to initiate authorisation holds as part of performing two-step purchases, but to withdraw or release the held funds you need to use Gate or Dashboard (or set up automatic capture operations after a specific time lag). This is true about each tool and, therefore, it is important to keep in mind that:

• each tool of the platform is intended for achieving its own specific set of goals.
• Achieving any applicable goal can be accomplished with the use one or several tools.
• To ensure efficient use of platform, it is often beneficial to combine its capabilities and tools according to the specifics of goals you are working to accomplish.

It can also be added that from the technical standpoint supporting any capability implies performing certain procedures, and for different tools these procedures, this way or another, will have to do with the configuration of the web service, the customers, or employees of the merchant. For example, the 3‑D Secure authentication of the customer used in purchase processing does not require active participation of the web service when processing involves payment interfaces of ecommpay (only customer actions are required). However, when processing occurs via Gate, the web service is required to perform a whole number of actions (accepting and processing data and redirecting the customer). These aspects of using different tools and capabilities are worth keeping in mind.

The capabilities of the platform can be divided into several groups functionality-wise:

• Processing payments of different types (or performing essential payment procedures)—a group of capabilities that ensure basic functions of the platform.

  These capabilities allow processing purchases of different types (in one or two steps, one time or with different kinds of repetition), payouts, and 'nominal' payments for verifying payment instruments with the use of various payment methods.

• Performing auxiliary payment procedures—a group of capabilities that ensure compliance with the requirements imposed on payment processing in specific cases.

  These capabilities allow executing procedures that are not always required but mandatory in certain cases and situations due to the requirements imposed by payment systems, regional specifics, or other conditions. As a rule, these procedures include additional customer verification, 3‑D Secure and AVS checks being the prime example.

• Expanding the scope of payment scenarios (or using additional capabilities)—a group of capabilities that ensure flexible configuring of the integration for specific situations and business needs to improve payment services.

  These capabilities allow performing procedures that can be considered complementary enhancements: they are not required to process payments, but they facilitate the variability of payment scenarios, boost payment interfaces conversion and payment acceptance rates, strengthen fraud prevention and increase customer loyalty.

• Managing payment solutions—a group of capabilities that allow merchants to manage payment solutions but do not affect payment processing per se.

  These capabilities are intended for simplifying the use of procedures for monitoring and analysing payment information, handling chargebacks, managing balances and other processes important for maintaining merchants' business operations.

Together, these groups of capabilities ensure full functionality and scalability of the platform for merchants.

Integration steps

Depending on the tools that will be used for working with the platform, the actual steps and the order in which they should be taken are going to vary significantly. In general case, you need:

1. Address the following organisational issues of interaction with ecommpay:

   1. If your company is not yet a client of ecommpay and has not obtained the project identifier and a secret key for interacting with the platform, submit an application. Once the application receives its initial approval, you will have the contact information of the ecommpay specialists in charge of your onboarding.
   2. For processing payments made with Visa and Mastercard, provide your ecommpay account manager with the documents of compliance with the PCI DSS requirements. The following documents are required:
      • From all merchants—the ASV scan report.

        ASV scanning must be performed by the authorised scanning service providers (PCI SSC Approved Scanning Vendor, ASV) quarterly and after every significant change in the network infrastructure. The ecommpay merchants can select these providers on their own and, if relevant, involve a provider that is in partnership with ecommpay. To have the scanning services via the partner arranged, contact your account manager.

      • From the merchants processing over 6 million operations annually (Level 1)—the Attestation of Compliance, AOC.
      • From the merchants processing up to 6 million operations annually (Levels 2, 3, and 4)—the Self-Assessment Questionnaire, SAQ.

        With questions on completing the questionnaire, contact your ecommpay account manager.

   3. Coordinate the procedures of integrating with the payment platform, testing (including testing card payments and some alternative payment methods), and launching the functionality with the ecommpay technical support specialists.
2. Complete preliminary technical tasks by using either your in-house resources or the specialised components offered by ecommpay if needed. Make sure to implement signature generation and callback response processing on the server side of the web service.

3. Test the required actions and launch the integration solution in coordination with the ecommpay technical support.

   Upon testing and monitoring, when the required actions are performed correctly, the ecommpay technical support specialists will switch to interacting with the web service in the full-time support mode.