How to make payment for services more convenient: the experience of an IaaS provider
One of the important issues when working with the services of an IaaS provider is the convenience of payment. From the first day of the start of our project, we tried to simplify the process of making payments using bank cards and continue to improve this mechanism. Today we decided to talk about where we started and share our experiences.
/ Flickr / Muhammad Ashiq / CC BY-SA
We have been providing IaaS services since 1cloud . During this time we managed to work with a large number of payment gateways. One of the first was "Money Online". We worked with him for two years, and then began to connect alternative services in case of potential technical difficulties.
')
Alternatively, they considered PayPal and Robokassa. As a result, both platforms were connected, although with this there were certain difficulties . In the first case, in order to import the client ID into the payment form, we had to adjust the CSS rules and modify the standard elements on the web page. In the situation with Robokassa, a number of requests to the API did not match its description, but with the help of technical support, the situation was also resolved. We did not stop at these solutions and considered other options that potential partners offered us.
So, we started working with the PayMaster payment system (it replaced “Money Online”), which offered us favorable terms for the commission and a convenient API. For a long time, this payment gateway acted as the main one. However, recently we decided to redesign the usability of our service and simplify the process of payment for bank card services for individuals. In order for UX to meet our requirements, we integrated another payment gateway - CloudPayments.
We work on the prepay model. The client replenishes his account in his personal account, and then funds are debited from this account as IaaS services are consumed (debit is made every ten minutes).
To replenish the balance with a credit card, in the case of PayMaster, the client had to go through a four-step process:
We decided to simplify the payment process for users and, in general, to improve the appearance and usability of forms for filling in bank card data. To do this, we have identified for ourselves two tasks, which we describe below.
As we noted above, when a user paid for our services, he had to go to the payment gateway site to fill out the card details. So a person had to press a lot of confirmation buttons and wait for the loading of pages with information about the account replenishment.
At the same time, another problem arose - after the user deposited money into the account, he remained on the payment gateway page until he clicked on a special link to return to 1cloud.ru. This complicated the work with our control panel, for example, if after the payment the user wanted to add capacity to his IT infrastructure.
In addition, we wanted to reduce the number of user-filled fields to a minimum, leaving only those that are really necessary for the operation. To accomplish this task, we chose the CloudPayments payment gateway, whose employees initially attracted our attention with quick and complete technical support responses.
In addition, this payment gateway had a representative office in Kazakhstan. This made it possible to implement a new payment method for our hosting service oblako.kz . Otherwise, all our transfers from Kazakhstan to Russia (or vice versa) would be subject to an additional commission.
CloudPayments suggested using a special chekout script . It allows you to implement the payment form directly in our control panel and transfer the completed data to the payment gateway, without saving them on our side.
To implement the script, we had to go through a PCI DSS security scan at one of the accredited organizations - such was the requirement of CloudPayments. Scanning is needed to confirm technical compliance with the standard and eliminate the possibility of theft of user data while filling out forms on the site.
The PCI DSS compliance audit was conducted by ARinteg. We sent them a request in which we indicated a desire to undergo an audit, filled out a questionnaire and set a date for the inspection. On the ARinteg side, preparation for scanning takes about half a day (that is, you can scan almost immediately), but we took an additional four to five days to thoroughly prepare our infrastructure.
Scanning lasted about 15 hours, although it happens that the test takes several days. ARinteg specialists checked for SSL and protection against requests-injections and other vulnerabilities on our site.
We did not pass the initial test, and we were given a list of problems that needed to be fixed. All of them were insignificant, for example, there was a post-method that was used when the user evaluated our step-by-step instructions on the site. We have eliminated all comments, and the second audit attempt was successful. Then we could go to the implementation of the chekout script.
The script is registered on our website, collects card data from this form and makes a cryptogram of them for payment through the API CloudPayments. It looks like this:
The form itself for entering bank card data looks like this:
During the implementation of the script and the form, we managed to reduce the number of user-filled fields to a minimum. Left only those that are really necessary for the operation. For example, removed the field "Name" and "Last Name". As representatives of the payment gateway explained to us, banks do not check this data (only the card number, date and CVV are important), so we decided to drop them and simplify the whole process.
Additionally, we have made more visual information about our discount program : in case of a one-time account replenishment in the amount of 5 thousand rubles, 10% of it is credited as bonuses, from 10,000 rubles - 20%, more than 100,000 rubles - 25%. We also added the ability to save map data for users. All this information is stored on the side of the payment gateway CloudPayments in encrypted form.
This is a payment that occurs automatically on some condition. Very often this feature is used by subscription services. However, most payment gateways offer only the option when automatic replenishment occurs on a schedule (on a given date). It is also important for us that the opportunity to replenish the account is automatically available at any time when the client has run out of funds on the account (as we work on prepay). Therefore, for the implementation of autopay, we used the method that is used when paying with a “memorized” card (by time token).
It works as follows: after the first successful payment made by the user, the gateway generates its token for the “service card” pair and sends it in the postback response. This token is saved, and when you pay again, it is transferred, and not the card data. It turns out that we are sending a request to the gateway, in which we indicate our API key (the identifier that the request came from 1cloud), the token and the amount. The gateway checks whether such a token was created, and if everything is in order, it processes the payment for the specified amount.
The date when it is necessary to make an auto payment is calculated dynamically based on the current consumption of services by the user and the balance of funds in the account. Suppose a client has a thousand rubles on his balance, and he has consumed two rubles over the last ten-minute interval. It is clear that the approximate date of zeroing will come in five hundred ten-minute intervals - this is approximately 34 days. Thus, we can make an auto payment several days before the end of the funds. The client chooses the size of the auto payment.
Now we are testing these solutions and evaluating the results of implementation. According to a vote held among customers, most are pretty changeable. We will further study the feedback on the work of the system, analyze the data and, if necessary, make adjustments.
/ Flickr / Muhammad Ashiq / CC BY-SA
Background question
We have been providing IaaS services since 1cloud . During this time we managed to work with a large number of payment gateways. One of the first was "Money Online". We worked with him for two years, and then began to connect alternative services in case of potential technical difficulties.
')
Alternatively, they considered PayPal and Robokassa. As a result, both platforms were connected, although with this there were certain difficulties . In the first case, in order to import the client ID into the payment form, we had to adjust the CSS rules and modify the standard elements on the web page. In the situation with Robokassa, a number of requests to the API did not match its description, but with the help of technical support, the situation was also resolved. We did not stop at these solutions and considered other options that potential partners offered us.
So, we started working with the PayMaster payment system (it replaced “Money Online”), which offered us favorable terms for the commission and a convenient API. For a long time, this payment gateway acted as the main one. However, recently we decided to redesign the usability of our service and simplify the process of payment for bank card services for individuals. In order for UX to meet our requirements, we integrated another payment gateway - CloudPayments.
How can you improve the UX payment process?
We work on the prepay model. The client replenishes his account in his personal account, and then funds are debited from this account as IaaS services are consumed (debit is made every ten minutes).
To replenish the balance with a credit card, in the case of PayMaster, the client had to go through a four-step process:
- Enter the amount to pay in the form in the control panel, click "Pay" and go to the payment gateway page.
- Specify a phone number or email address to receive a check and click Continue.
- Enter the card details and press the “Pay” button again.
- Specify the transaction confirmation code sent by the bank as part of the 3D Secure procedure.
Disclaimer: the algorithm described above concerns payments by bank cards that individuals make. Legal entities pay for the services of the IaaS provider for the invoices. While improving usability, we refined the mechanisms of automatic billing of such invoices, but we will not consider them as part of this material, since legal entities do not interact with the payment gateway.
We decided to simplify the payment process for users and, in general, to improve the appearance and usability of forms for filling in bank card data. To do this, we have identified for ourselves two tasks, which we describe below.
Task 1: exclude the transition to the payment gateway page
As we noted above, when a user paid for our services, he had to go to the payment gateway site to fill out the card details. So a person had to press a lot of confirmation buttons and wait for the loading of pages with information about the account replenishment.
At the same time, another problem arose - after the user deposited money into the account, he remained on the payment gateway page until he clicked on a special link to return to 1cloud.ru. This complicated the work with our control panel, for example, if after the payment the user wanted to add capacity to his IT infrastructure.
“According to analysts, only a handful of clients followed the link and returned to our site,” says Sergey Belkin , head of development at 1cloud.ru. - This was partly due to the fact that the client had to click the “Return to online store” link. This is despite the fact that our service is not an online store. ”
In addition, we wanted to reduce the number of user-filled fields to a minimum, leaving only those that are really necessary for the operation. To accomplish this task, we chose the CloudPayments payment gateway, whose employees initially attracted our attention with quick and complete technical support responses.
In addition, this payment gateway had a representative office in Kazakhstan. This made it possible to implement a new payment method for our hosting service oblako.kz . Otherwise, all our transfers from Kazakhstan to Russia (or vice versa) would be subject to an additional commission.
CloudPayments suggested using a special chekout script . It allows you to implement the payment form directly in our control panel and transfer the completed data to the payment gateway, without saving them on our side.
To implement the script, we had to go through a PCI DSS security scan at one of the accredited organizations - such was the requirement of CloudPayments. Scanning is needed to confirm technical compliance with the standard and eliminate the possibility of theft of user data while filling out forms on the site.
The PCI DSS compliance audit was conducted by ARinteg. We sent them a request in which we indicated a desire to undergo an audit, filled out a questionnaire and set a date for the inspection. On the ARinteg side, preparation for scanning takes about half a day (that is, you can scan almost immediately), but we took an additional four to five days to thoroughly prepare our infrastructure.
Scanning lasted about 15 hours, although it happens that the test takes several days. ARinteg specialists checked for SSL and protection against requests-injections and other vulnerabilities on our site.
We did not pass the initial test, and we were given a list of problems that needed to be fixed. All of them were insignificant, for example, there was a post-method that was used when the user evaluated our step-by-step instructions on the site. We have eliminated all comments, and the second audit attempt was successful. Then we could go to the implementation of the chekout script.
The script is registered on our website, collects card data from this form and makes a cryptogram of them for payment through the API CloudPayments. It looks like this:
this.createCryptogram = function () { var result = checkout.createCryptogramPacket(); if (result.success) { // alert(result.packet); } else { // , `result.messages` : // { name: " ", cardNumber: " " } // `name`, `cardNumber` `<input ... data-cp="cardNumber">` for (var msgName in result.messages) { alert(result.messages[msgName]); } } }; $(function () { /* checkout */ checkout = new cp.Checkout( // public id "test_api_00000000000000000000001", // , document.getElementById("paymentFormSample")); }); The form itself for entering bank card data looks like this:
During the implementation of the script and the form, we managed to reduce the number of user-filled fields to a minimum. Left only those that are really necessary for the operation. For example, removed the field "Name" and "Last Name". As representatives of the payment gateway explained to us, banks do not check this data (only the card number, date and CVV are important), so we decided to drop them and simplify the whole process.
Additionally, we have made more visual information about our discount program : in case of a one-time account replenishment in the amount of 5 thousand rubles, 10% of it is credited as bonuses, from 10,000 rubles - 20%, more than 100,000 rubles - 25%. We also added the ability to save map data for users. All this information is stored on the side of the payment gateway CloudPayments in encrypted form.
Task 2: implement auto payment
This is a payment that occurs automatically on some condition. Very often this feature is used by subscription services. However, most payment gateways offer only the option when automatic replenishment occurs on a schedule (on a given date). It is also important for us that the opportunity to replenish the account is automatically available at any time when the client has run out of funds on the account (as we work on prepay). Therefore, for the implementation of autopay, we used the method that is used when paying with a “memorized” card (by time token).
It works as follows: after the first successful payment made by the user, the gateway generates its token for the “service card” pair and sends it in the postback response. This token is saved, and when you pay again, it is transferred, and not the card data. It turns out that we are sending a request to the gateway, in which we indicate our API key (the identifier that the request came from 1cloud), the token and the amount. The gateway checks whether such a token was created, and if everything is in order, it processes the payment for the specified amount.
The date when it is necessary to make an auto payment is calculated dynamically based on the current consumption of services by the user and the balance of funds in the account. Suppose a client has a thousand rubles on his balance, and he has consumed two rubles over the last ten-minute interval. It is clear that the approximate date of zeroing will come in five hundred ten-minute intervals - this is approximately 34 days. Thus, we can make an auto payment several days before the end of the funds. The client chooses the size of the auto payment.
What's next
Now we are testing these solutions and evaluating the results of implementation. According to a vote held among customers, most are pretty changeable. We will further study the feedback on the work of the system, analyze the data and, if necessary, make adjustments.
PS Fresh materials from our corporate blog:
Source: https://habr.com/ru/post/433948/
All Articles