Quickstart
Overview
This guide explains how to organise payment processing via Payment Page. So that the form would open from the web service and return customers to this web service. And so that you could use tested and quick solutions—with clear instructions, libraries, and code examples And so that you could use programming solutions in one of the three popular programming languages—PHP, Python, or JavaScript.
If you are interested in something else, there are other options available.
With that, let’s get started.
Brief theory
Projects and keys
Working with the ecommpaypayment platform can be compared to using hotel services: to check into a hotel, you need a room and a key for this room, and to start working with the platform, you need a project and a key for this project. And like in case of hotel rooms, there can be a different number of projects for one client—for different aims and purposes—and each project requires its own key.
Usually, to work with the platform, having one test and one production project is enough. This case is typical and is used as the basis within the Quickstart guide. If for any reason you need more projects, make sure to identify this need in the communication with your account manager. In the meantime, you don't have to wait till this issue gets resolved: you can already start working on the implementation and setup with one test project.
If you have already obtained the identifier (project_id
) and the secret key (secret_key
) of the test project, have them at hand as you proceed with the implementation. Otherwise, you can get an access to the test project and return to this article.
To start working with the platform, you need a project and a key for this project. If you have already obtained the identifier (project_id
) and the secret key (secret_key
) of the test project, have them at hand as you proceed with the implementation. Otherwise, you can get an access to the test project and return to this article.
Workflow
For Payment Page to open correctly, the collection of parameters, signature generation, and the form opening should be set up. Along with that, it is important that data signing (which requires the secret key) is performed on the server side of the web service and the payment form opening—on the client side of the web service. Additionally, for the timely monitoring of results, setting up the server side to receive callbacks from the payment platform can be helpful.
This is an overall workflow.
Web service front end | Web service back end | In the payment platform | |
---|---|---|---|
1 | Creating an order. Collecting payment parameters and sending them to the web service back end (for signing the parameters) | – | – |
2 | – | Submitting additional parameters (if relevant) and signing them, then sending the information to the front end | – |
3 | Creating the request for opening Payment Page and sending it to the payment platform | – | – |
4 | – | – | Accepting the request, preparing and displaying the form to the customer, processing the customer actions and the payment, after that sending the callback with the payment result information and returning the customer to the web service |
5 | – |
Accepting the callback with the payment result information and updating the order status |
– |
6 | Displaying the payment information to the customer and the information about the customer further actions (if such actions are required, for example, for the product delivery) | – | – |
Generally, this workflow scheme on the client and server sides of the web service can be implemented in a number of ways. This article—for the convenient and quick launch of the work with Payment Page—describes all necessary procedures with the application of ready-to-use components (such as SDKs) and code examples to their fullest extent. Still it is always possible to combine our ready-to-use components with your solutions.
Parameters for opening the form
To display the payment form to the customer, in the simplest case, you just need to decide on the parameters of the payment amount and currency and add the following three identifiers to these two parameters: the identifier of the project, the payment, and the customer. In total, this makes up five required parameters. (And signing these parameters is technically required.)
Parameter | Description |
---|---|
|
Project identifier. Together with the key, it is provided by ecommpay and should be precisely specified even in test requests. Otherwise, this is going to look as if you are trying to enter someone else's hotel room and the payment platform reacts accordingly. from the payment platform. |
|
Payment identifier. It can have random values but always should be unique within the project used. Otherwise, an error occurs from the web service. |
|
Payment amount. In test requests it can be a random amount, while in real ones the amount should correspond to the amount of the order. The amount is specified in minor currency units. |
|
Payment currency code. It is specified in the three-letter ISO 4217 alpha-3 format. Test requests can contain any of the applicable codes, while every real request should contain the code of the currency in which the payment is being initiated. |
|
Customer identifier. It can have random values and be reused in different requests, however, the identifier of every real customer should exactly match the account of this very customer in the web service and be unique within the project. Otherwise, there can occur different issues that also concern displaying to the customer saved payment data of another customer. |
How to collect these parameters (as well as which of them should be specified on the client and on the server side of the web service) is for you to decide (with regards to your web service architecture and other factors). For the initial few times of opening the payment form, it is not necessary to automate the collection of parameters, you can deal with this after the primary testing of the payment form operation. There is just one thing left to mention—in addition to the required parameters, you can use other parameters, for managing the payment form look and behaviour; but since it is better to use these parameters after setting up the standard Payment Page opening, they are substantially described further.
Basic implementation
Variants of working with the form
The work of the web service functions with the payment form and callbacks can be implemented in different ways, which include creating in-house solutions and applying the CMS modules. Within this article, we consider the two variants of implementation implementing the work of the web service functions with the payment form and callbacks:
- with the use of the SDKs from ecommpay on the server side of the web service;
- with the use of the ready-to-use code from ecommpay on the server side of the web service.
You can choose among these variants, with regards to their differences, at your discretion. The SDKs can make the work with other programming languages a little easier and more available (full information about working with the SDKs is provided in a separate section). The work with the code examples can be a little more transparent and flexible in terms of embedding them in your own solutions (as well as when working with signatures). Still both variants are quite quick and complete, and you can choose any of them.
Along with that, whatever variant of the server functions implementation is used, within this article, we look at different variants of the payment form opening on the client side of the web service, including the usage of libraries from ecommpay. In general, this is what should be done for the implementation.
Web service back end | Web service front end |
---|---|
|
|
The collection of parameters and submission of additional ones, as said in the brief theory overview, can be implemented in various ways (for the primary testing, manual implementation is possible) which are up to you. Other actions are regarded further.
Work with SDK
Linking and setting up.
Work with code
Embedding and using.
Actions on the client side
Payment Page can be opened on the client side of the web service in various ways, and to get the feel of them, you can try several options even within the Quickstart guide.
The easiest option is to open the payment form in a separate browser tab.
To use other options—opening the payment form in a modal window and in an iframe element—you need to link the two libraries: CSS for the form to be displayed correctly and JavaScript for the form to open. This is done via adding the links to the libraries in the header of the web service HTML page.
For opening the payment form with the help of the JavaScript library, the signed set of parameters in the form of the JavaScript object should be used. The set can be formed by way of parsing the link received when the data was signed (in the PHP language, you can use the parse_url
and parse_str
functions for this) or using the server code for generating the signature (without generating the link) and adding the signature to other parameters.
After linking the libraries and dealing with the parameters, you can try opening the form.
For the primary introduction, these opening options can suffice. If you need a more tailored approach, refer to the documentation and contact our specialists.
Testing
When the payment form is opened in the production mode, it is intended to be used by the customer. In the test mode, you can put yourself in the customer's shoes and test various purchase scenarios as if you were paying for something. The key question here—what credentials should be specified?
In the test project, there are two available types of payment credentials: special test credentials, which allow you to test predefined payment scenarios, and random realistic credentials, which allow you to additionally test the payment form operation in various cases.
For bare minimum testing (to process payments according to the shortest scenarios, without the emulation of the 3‑D Secure authentication), use the following numbers of test cards:
4000 0000 0000 0077
—for a purchase to be processed;4111 1111 1111 1111
—for a purchase to be declined.
For the purposes of the more comprehensive testing, it is possible to use extended test data for card payments (including scenarios with the 3‑D Secure authentication) and various alternative payments, as well as random data including the credentials of cards, wallets, and other payment instruments. This is safe since all data in the test and the production environment is protected equally, although in the test environment there are no actual payments taking place.
After testing and ensuring the correct work with the form, the basic functions for purchase processing can be considered implemented, and when desired, you can move on to various additional aspects, which can be helpful at the initial stages of working with the payment platform, and to launching the solution operation.
Additional aspects
Monitoring of payment processing
After processing several test payments, you can explore how to monitor the overall payment situation. For this, use the register and the payment information tabs in Dashboard.
With questions about working with this interface, and about other issues, refer to the documentation and contact our specialists.
Refunds
When you need to refund a purchase, Dashboard can be used as well. When testing the work with the payment form, you can try to make full and partial refunds via the payment information tabs.
To delve into the topic about working with refunds, including mass refunds, you can use the separate article. Besides, knowing about refunds via Gate can be useful.
UX capabilities of the form
The work with Payment Page can be supplemented by various capabilities that include managing the form’s look and behavior—for example, setting the relevant language, filtering payment methods, or managing the ways of returning the customer to the web service. Some of such capabilities can be set up only via the ecommpay specialists, others can be applied without the anyone’s involvement, just via Dashboard or by sending additional parameters in the requests for opening Payment Page.
For testing the Payment Page operation, we recommend that you try the following:
- Customise the payment form with the help of the Payment Page Designer.
For this, in the Projects section of the Dashboard interface, use the tools of the Payment Page Designer tab (for more information, see Customisation).
- Try opening the payment form in different languages.
For opening Payment Page in a specific language, this language code (in the two-letter ISO 639-1 alpha-2 format) should be sent as the value of the corresponding parameter—
language_code
. The list of the languages supported by ecommpay is provided here. - Return the customer to the web service after payment processing.
After the payment processing and depending on the payment result, the customer can be returned to different pages of the web service. The URLs of such pages can be specified in the Projects section of the Dashboard interface (in the Redirect URLs tab) or sent in certain requests as the values of the parameters
merchant_success_url
andmerchant_fail_url
. - Apply the capabilities to suit your needs.
The information about different capabilities is provided in the overview and in the specialised section, and the list of the parameters for opening the form is provided in the separate article. All questions, as usual, can be forwarded to our specialists.
Launch
After implementing the basic functions, testing various capabilities, and defining the scenarios of the work with Payment Page relevant for you, you can start launching the production project. It is important that by this time all organisational issues have been resolved—in this case, the technical issues come down to configuring the project settings on the payment platform side and beginning to use the identifier and the key of the production project.
Good luck!