Our projects: SMS payments "for the lazy"
For 5 years of the existence of the smscoin project, not only the team has grown, but also the field of activity of our company. SMS billing remained the main focus of our project; but we went further, changing the development methods, testing a lot of the latest technologies in active business applications, developing in other equally interesting areas. It is about these projects and interesting experience gained in the process of their development, and will be discussed in a series of articles, the first of which is in front of you.
In order to justify the presence of Django in the list of tags, I note that this is our first public project on Django, even though the framework itself was previously used in internal development.
')
If you are interested in how you can connect SMS payments to your resource without writing a single line of code without registering on our website and getting all the money in advance, please read further.
The story about this project should start with a certain background. At one time, we offered the sms: safe service, whose task was to generate instructions for paying sms for amounts exceeding the maximum available tariff in a particular country (if it is unknown, the maximum amount of payment is extremely limited and differs in each country). So, if a partner wanted to get $ 5, then in the service settings he had the opportunity to choose in the drop-down menu the possibility of payment with sending several SMS, the total cost of which is closest to the desired total amount. For example, it was possible to choose 3 sms for $ 2 or 5 sms for $ 0.9. An important condition was that the cost of all SMS when paying remained the same. In fact, it was just a multiplication of the tariff by the number of SMS that must be sent.
The service was not popular for several reasons. This is a difficulty in understanding the scheme of work, and a nontrivial integration scheme, and the limitations of the scheme in fitting to the cost (it was impossible to make 2 sms for $ 2 and 1 sms for $ 0.9, to get the sum from the example above), or too many sms and A more accurate amount or a small SMS, but an amount that is far from desired. As a result, we came to the decision to freeze the service and not to offer it to partners.
Anyway, the demand remained, and although some of the partners could implement such logic on their side (thank God, we have all tariffs exported), many for one reason or another expected that we would provide them with such a solution. As you know, demand creates supply, and a year ago we invented and quickly implemented a new version of the service as a separate project.
This time we decided to go ahead and realize the “wet dream” of any seller: do nothing and get money for the goods ahead. For this we needed 2 simple things - the product and its value. For the goods, it was decided to take the vouchers provided by the seller for the service, or balance replenishment. These can be either PIN codes or login-password, or even activation links. This mechanism is widely used on file sharing services or social networks. Apple has such vouchers in iTunes and used to have Skype. In other words, vouchers are quite a popular way to spend money, which works on many popular services.
With the product and its price (which is determined by the seller), in general, determined. It remained to modify the technical part. For development chose Django, which was previously used. It is worth noting that for the developer of this project it was the first and generally successful experience (the project works and brings money). From a technical point of view, it was decided to use all the automation power provided by SmsCoin and instructions generated automatically by a function that considers the selected country and amount as parameters and outputs an array of data from which the instruction for the user is built. Unlike the original sms: safe service, different rates can be combined, but the main goal is to reduce the number of sent sms.
In order to distinguish one payment from another, a unique message text is generated for the user, and all SMS with this text are attached to its payment. To avoid cases of fraud, so common in the field of SMS payments, all SMS should be sent from the same country and in principle from the same number. In order for users to clearly know how much they have already paid and how much is left, upon receiving an SMS, the status in the instruction changes from “expected” to “received”. And in general, all the instructions are simple and clear. It was decided not to limit the time of the transaction, as there may be a situation in which the subscriber does not have enough funds to send all SMS at once, and he needs to replenish the balance. So that users can return to the open transaction or re-view the code obtained earlier, we decided to add the ability to search for a transaction.
The result was a very interesting project with the straightforward name smspay4.com . For end users, the interface is absolutely minimalistic: payment instructions, feedback form and transaction view form. There is simply no place to get lost, only one way - to successful payment.
For sellers, the project came out even more interesting. There is no need to register anywhere (in principle, and nowhere) - we are registering just on the seller’s website (or communicate by mail). The whole integration process is to add a link to the payment page, created specifically for the seller’s project. Financial calculations also mainly work on a prepaid basis, i.e. we first pay and buy vouchers, and when they are sold - our concern is already, and the seller has already received his money.
As a result, in principle, the trivial logic and clear implementation formed the basis of the project with a rather interesting sales scheme, which is perfectly suitable for the mass of services and does not require any actions from them. To understand everything written earlier, I’ll provide a link to the payment page of one of the projects we work with according to this scheme - smspay4.com/project/hotfile
The project came out simple (at least its part visible to the user), but fully meeting the specified requirements. As far as we know, none of the competitors have such a solution, which is also nice :-). All who are interested in cooperation, write to the LAN or contact the contacts on the site.
In order to justify the presence of Django in the list of tags, I note that this is our first public project on Django, even though the framework itself was previously used in internal development.
')
If you are interested in how you can connect SMS payments to your resource without writing a single line of code without registering on our website and getting all the money in advance, please read further.
The story about this project should start with a certain background. At one time, we offered the sms: safe service, whose task was to generate instructions for paying sms for amounts exceeding the maximum available tariff in a particular country (if it is unknown, the maximum amount of payment is extremely limited and differs in each country). So, if a partner wanted to get $ 5, then in the service settings he had the opportunity to choose in the drop-down menu the possibility of payment with sending several SMS, the total cost of which is closest to the desired total amount. For example, it was possible to choose 3 sms for $ 2 or 5 sms for $ 0.9. An important condition was that the cost of all SMS when paying remained the same. In fact, it was just a multiplication of the tariff by the number of SMS that must be sent.
The service was not popular for several reasons. This is a difficulty in understanding the scheme of work, and a nontrivial integration scheme, and the limitations of the scheme in fitting to the cost (it was impossible to make 2 sms for $ 2 and 1 sms for $ 0.9, to get the sum from the example above), or too many sms and A more accurate amount or a small SMS, but an amount that is far from desired. As a result, we came to the decision to freeze the service and not to offer it to partners.
Anyway, the demand remained, and although some of the partners could implement such logic on their side (thank God, we have all tariffs exported), many for one reason or another expected that we would provide them with such a solution. As you know, demand creates supply, and a year ago we invented and quickly implemented a new version of the service as a separate project.
This time we decided to go ahead and realize the “wet dream” of any seller: do nothing and get money for the goods ahead. For this we needed 2 simple things - the product and its value. For the goods, it was decided to take the vouchers provided by the seller for the service, or balance replenishment. These can be either PIN codes or login-password, or even activation links. This mechanism is widely used on file sharing services or social networks. Apple has such vouchers in iTunes and used to have Skype. In other words, vouchers are quite a popular way to spend money, which works on many popular services.
With the product and its price (which is determined by the seller), in general, determined. It remained to modify the technical part. For development chose Django, which was previously used. It is worth noting that for the developer of this project it was the first and generally successful experience (the project works and brings money). From a technical point of view, it was decided to use all the automation power provided by SmsCoin and instructions generated automatically by a function that considers the selected country and amount as parameters and outputs an array of data from which the instruction for the user is built. Unlike the original sms: safe service, different rates can be combined, but the main goal is to reduce the number of sent sms.
In order to distinguish one payment from another, a unique message text is generated for the user, and all SMS with this text are attached to its payment. To avoid cases of fraud, so common in the field of SMS payments, all SMS should be sent from the same country and in principle from the same number. In order for users to clearly know how much they have already paid and how much is left, upon receiving an SMS, the status in the instruction changes from “expected” to “received”. And in general, all the instructions are simple and clear. It was decided not to limit the time of the transaction, as there may be a situation in which the subscriber does not have enough funds to send all SMS at once, and he needs to replenish the balance. So that users can return to the open transaction or re-view the code obtained earlier, we decided to add the ability to search for a transaction.
The result was a very interesting project with the straightforward name smspay4.com . For end users, the interface is absolutely minimalistic: payment instructions, feedback form and transaction view form. There is simply no place to get lost, only one way - to successful payment.
For sellers, the project came out even more interesting. There is no need to register anywhere (in principle, and nowhere) - we are registering just on the seller’s website (or communicate by mail). The whole integration process is to add a link to the payment page, created specifically for the seller’s project. Financial calculations also mainly work on a prepaid basis, i.e. we first pay and buy vouchers, and when they are sold - our concern is already, and the seller has already received his money.
As a result, in principle, the trivial logic and clear implementation formed the basis of the project with a rather interesting sales scheme, which is perfectly suitable for the mass of services and does not require any actions from them. To understand everything written earlier, I’ll provide a link to the payment page of one of the projects we work with according to this scheme - smspay4.com/project/hotfile
The project came out simple (at least its part visible to the user), but fully meeting the specified requirements. As far as we know, none of the competitors have such a solution, which is also nice :-). All who are interested in cooperation, write to the LAN or contact the contacts on the site.
Source: https://habr.com/ru/post/126811/
All Articles