According to what scheme do payment system aggregators work and how to implement such a scheme for personal use?

Question

PHP

Hello!
There are several sites, all of them are connected to different payment systems and several aggregators.
Today I thought about what if you connect your sites to your simple aggregator, the topic is interesting for the sake of practice.
I present it like this:

1. There is a website where a person chooses a product and a payment method, something like an invoice is formed, a secret line. The person presses the "Pay" button.
   
2. Next, the person is transferred to the aggregator's website, where, depending on his choice, a ready-made form for payment is formed. At this stage, as I understand it, you need to check the domain where the transition came from with the white list and check the data by comparing them with the secret string (the salt value should probably be stored on the store website and on the aggregator website)
   
3. A person pays the required amount through the form and, in theory, he should be returned to the store’s website, while the
   success or error status should be transmitted, depending on the result of the payment ... well, the account ID that was paid ... probably the result is also better to encrypt and include the actual amount of payment in it so that you can verify this data on the store's website?
   

PS: Regarding extensibility (connecting left stores) - there is no such task, I would like to implement this for personal use, but on the other hand, it would be convenient to connect each new project to this scheme, thereby eliminating the routine fuss with a bunch of payments and third-party aggregators when opening new site. So the only thing that comes to mind is to store a trusted list of domains and a unique salt for each store on the aggregator side ... what else?
Am I thinking right? Who can suggest / add something, especially regarding protection and the logic itself? What is the best method to use for data exchange?
Probably many have tried to implement this and it works great for someone, share your practice, what am I missing in the logic? What to read?
Looking forward to your comments, thanks for your interest!

Answer 1

Advantages of such a solution - a third party (third-party aggregator) your confidential data + no need to pay them a commission, cons - judging by the questions you are unlikely to ensure their security + if you do not use aggregators at all, you will have to connect each payment system yourself, for example, to receive the maximum certificate for webmoney\poison, which is not so easy.
Regarding the implementation: take a description of any popular aggregator - it contains answers to most of the questions that have arisen - just do it by analogy.

Answer 2

I see your question as two tasks:
- get rid of other people's aggregators and learn how to work with different payment systems directly
- teach my one payment point to work with several of my points of sale.
If everything is correct, then the first question is implemented very simply. It is enough to study the heels of api of different payments. I can share my version (server part) (now I am reshaping it from the experience of using https://toster.ru/q/327212).
I suggest you think about the second part again. Is it necessary? If you have a universal code / module / plugin for payment, then what prevents you from spreading it on different sites? Most payment systems support "one contract/account and many stores".
By introducing additional "forwarding/encryption/etc." you add unnecessary links, increase the chance of vulnerability, reduce the reliability of the system as a whole.