Creating a system of sales "within the system" - remote connection stores and payment of funds

Most PAYSTO solutions are not available on the market. This does not mean that we are doing “nobody needs” - it’s just that “not everyone” needs it, and in some cases a universal solution is created for a specific task. Today I will tell just about this decision ...


To make everything clear, I will start from the very beginning ...
Somewhere 2 years ago the owner of one project addressed us with the following task:
A system is launched that will provide its users with services for interacting with other users. The functionality of the system will be paid and the acceptance of recurrent payments is necessary (automatic payment after a certain period). An additional service for users of the system will be the ability to sell their own digital goods (for example, articles) to other users on the Internet. At the same time, everything should work within a single system - without going to other sites, i.e. "Without leaving the system." Here is a good association - the appStore in the iPhone, when users can create applications and sell them to other users - all the processes of ordering, payment and delivery of goods are carried out in one place. Do not forget that in this case we still need to pay the funds to users when selling their goods.
It is impossible to find a ready-made solution for this, and it will take not only a lot of time, but also resources to create your own infrastructure. In addition, according to calculations, the planned income will not be able to cover the support of such infrastructure. It remains to seek solutions in outsourcing payment processing services, and to optimize financial flows, all tasks should be solved in one place:

1. Acceptance of payments for the main system, including recurrent payments;
2. Accepting payments for the store (selling users' goods);
3. Payment of funds to users (sellers) in various ways - to a bank account, card or payment systems.

The first problem was solved using upBalance .
For the other two, it was planned to use onlineMerchant and paymentGate , but another problem arose - the legal formalization of the main system’s relations with merchant users, since It was impossible to legally unite everything into one, since by that time the main system had already received venture financing and the use of “gray” schemes was unacceptable. It took more than a year to realize this “deadlock”. In early September, I met with the owner of the system and we began to look for another solution ...
The idea proposed by the client looked like “personalization of the store connection processes”, i.e. design of all processes in the style of the client system: creating a user, connecting a store and paying out money. Of course, it could be done this way, but in fact for us it became the creation of a clone PAYSTO, which was not part of our development plans, since would require considerable development time. For simplicity, I suggested using a solution similar to “Log in using..Facebook, Google, Twitter, etc.”, and the user account data in the client system would be used as the login / password. This approach is implemented fairly quickly. We stopped at this and decided to find out the technical capabilities of each on our side.

Having met with our developers, a different solution was proposed - we will implement a special API for the required processes:

1. Creating a new user in the PAYSTO system;
2. Add and manage user details PAYSTO;
3. Creating and connecting the store in onlineMerchant;
4. Creation and control of withdrawal requests from PAYSTO;

From the point of view of security, there will be no changes - user registration and withdrawal of funds are also carried out using the confirmation code sent to the owner’s e-mail, but they are already entered in the client system.
')
In fact, this functionality allows you to organize sales in any external system. On the client side, you can use a CMS to manage the store, with a slight refinement and adaptation of the design. Given that we have ready-made modules for all common CMS , the implementation of such a task will not take long.

Description of the new API can be found here .

Now about the conditions of cooperation ...
Our interest in “this” is absolutely standard - we do not charge any additional fees for new functionality. All services are provided according to the selected tariff for accepting payments , an average of 5% of the payment amount.
Monetizing these services on the client side is possible through payment within the client system, for example, as an additional service. However, this option may not be convenient for several reasons, so the client involved in the implementation of this decision has set a condition that when selling goods through such a store, the user should be credited with the amount = 30%. This rate is due to the fact that the client provides advertising for the user's goods. For “transparency” of relations, the difference of 25% is credited to the partner account of the client within PAYSTO and is displayed on his current account under a cooperation agreement.