How to make payment for services more convenient: IaaS provider experience

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.
 
 
How to make payment for services more convenient: IaaS provider experience 3r311.
 
[i] /Flickr /3r317. Muhammad Ashiq
/ CC BY-SA 3r3104.
 
 

Background question


 
We are in 1cloud We have been providing IaaS services since 2012. During this time, we are 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 from this caused certain difficulties . In the first case, in order to import the client ID in 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 API requests did not match its description, but with the help of technical support, the situation was also resolved. We did not stop at these decisions 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.
 
 

Due to what can be improved 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 (each ten minutes are debited).
 
 
To replenish the balance with a bank card, in the case of PayMaster, the client had to go through a four-step process:
 
 
3r361  
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.
 
3r3-300. [i] 3r3102. Disclaimer: [/b] The algorithm described above concerns bank card payments made by individuals. Legal entities pay for the services of an 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. 3r3104. 3r3105.
 
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 3r33222.
 
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 made it difficult to work with our control panel, for example, if, after payment, the user wanted to add capacity to his IT infrastructure.
 
 
3r3-300. [i] “According to analysts, only a handful of customers followed the link and returned to our site,” says 3r3102. Sergey Belkin 3r3103. , head of development department 1cloud.ru. - In part, this was 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. " 3r3104. 3r3105.
 
Additionally, 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 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 security scan at 3r3124. standard PCI DSS
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:
 
 
3r3146. 3r3147. this.createCryptogram = function () {
var result = checkout.createCryptogramPacket ();
if (result.success) {
//formed the cryptogram
alert (result.packet);
}
else {
//errors were found in the entered data, the object `result.messages` format:
//{name: "There are too many characters in the name of the cardholder", cardNumber: "Incorrect card number"}
//where `name`,` cardNumber` correspond to the values ​​of the attributes `
`
for (var msgName in result.messages) {
alert (result.messages[msgName]);
}
}
};
$ (function () {
/* Creating a checkout * /
checkout = new cp.Checkout (
//public id from the personal account 3rr3249. "test_api_00000000000000000000100?
//tag containing the data fields of 3rrr4949. 00? 3233232. //tag containing data fields of 3rrr4949000000001", 3rr3249. //containing the data fields of 3rrr???? 3r34932. //containing the data fields of 3rrr???? 3133232. //3rr???) document.getElementById ("paymentFormSample")); 3r-3232.});
3r3174. 3r? 3175.
 
The form itself for entering bank card data looks like this:
 
 
3r3182.
 
 
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 the representatives of the payment gateway explained to us, the 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 made more visual information about our discount program : in case of a one-time replenishment of an account in the amount of from 5 thousand rubles, 10% of it is credited as bonuses, from 1?000 rubles - 20%, more than 10?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 in 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 a token for the “service card” pair and sends it in the postback response. This token is preserved, 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.
 
 
P.S. Fresh material from our corporate blog:

 
 
DevOps in the cloud service on the example of 1cloud.ru
 
What you need to know about digital signatures
 
Risk minimization: how not to lose your data 3r33239.
 
+ 0 -

Add comment