итак, 2 главных правила:
1. приватные ключи адресов, выдаваемых пользователям НЕ ДОЛЖНЫ храниться на веб-сервере, мало того, так как вы не выдаете монеты, храните их лично на своем (владельца сервиса) аппаратном кошельке
2. bitcoind с ключом -prune 512 после прогрузки блокчейна будет занимать на диске примерно 6 гигабайт и через api будет полноценно работать с wallet.dat и адресами в нем в режиме просмотра и проверки прихода депозитов, запускать так же на сервере рядом с веб, на текущий момент этот демон может работать даже на малинке (файловую систему лучше использовать по сети на быстром файловом сервере, ибо у малинки только ОЧЕНЬ медленный usb), правда первичную загрузку лучше проводить на быстрой машине.
Вам достаточно генерировать на своей локальной машине и импортировать на веб сервер большими пакетами адреса для приема платежей (по уму это не так обязательно делать постоянно, но настоятельно рекомендуется один платеж - новый адрес) и все, больше ваш кошелек не потребуется. Чтобы защититься от ddos опустошения адресов приема, подсовывайте клиентам старые адреса без входящих переводов.
Существуют иные библиотеки, занимающие меньше ресурсов (подключаются напрямую к сети и не проводят никаких проверок кроме наличия подтверждения от майнеров, этого более чем достаточно), но формально они 'не официальные' (хотя это философский вопрос что есть официальное в децентрализованной криптовалюте, но если что то реализует, ломающее совместимость, то в первую очередь в bitcoind).
Это самый правильный и простой способ организации приема платежей.
p.s. ждите релиза lightning network, скоро это станет стандартом де факто для приема платежей
p.p.s. Если у вас есть задача переводов от вас, то реализуйте ее на отдельном сервере, коммуникация между веб-сервером и этим платежным сервером должна проводиться через специальный модуль безопасности (и разработанный для этого api), перепроверяющий все что только можно, в идеале разработанный разработчиками, отличными от тех кто делал веб-сервер.
Простой
