Дмитрий Энтелис

1) Вопрос использовать ли вообще ООП или нет - он очень условен.
Без ООП не работает любой современный фреймворк.
Поскольку MVC таки использовать надо - соответственно ооп у вас будет автоматом)

2) По поводу Symfony - абсолютно без разницы на каком именно фреймворке Вы пишите свой код.
Symfony мне кажется более сложен для начинающего, попробуйте Yii2 или Laravel.
Опять же повторюсь, это не принципиально. Можно взять любой микрофреймворк - это будет даже полезней с точки зрения развития начинающего разработчика.

3) API это по сути обычный набор скриптов, отличающийся от обычных страниц тем, что в web страницах вы отдаете html - а в API вы отдаете JSON/XML/что_то_ещё (я лично советую использовать JSON по целому ряду причин, но вопрос в целом холиварен)
REST API (опять же дефакто массовый стандарт) - это договоренность о некоторых базовых принципах, по сути о форматах запроса, ответа, об отсутствии состояний (stateless)
Возвращаясь к пункту 2 - многие фреймворки дают автоматизацию в построении rest api, например вот свежая статья с примерами по Yii2 habrahabr.ru/post/240149

Если у Вас какой то ужатый функционал приложения, можно не заморачиваться с реализацией всех методов, а реализовать только нужные.
В случаях сложных больших экранов в приложении, может быть выгоднее сделать специальный метод для какого то экрана, реализующий все одним куском (впрочем это обычно уже на стадии рефакторинга делают)

4) В любом случае - начните с написания документации для самого себя:
Какие у вас есть сущности(ресурсы в терминологии rest), опишите их.
Какие действия над ними может производить клиент.
По каким условиям клиент может запрашивать фильтрацию каких сущностей.
Есть ли у вас необходимость передавать сущности не целиком (тоже холиварный вопрос)
итд

Прошу прощения если получилось сумбурно, писал одновременно с утренним кофе :)

Если у Вас база обновляется редко, целиком и уже есть инструменты для этого - то можно и файлик на сервер заливать.

Но классическое решение - сделать REST api, которое будет отдавать контент в мобильное приложение. Заодно в рамках api можно сделать версионность, и отдавать не все данные, а только то что изменилось.

Поскольку в общем случае верстку и натягивание на cms делают разные люди - то верстальщик делает html макет в котором какие то тестовые данные забиты статикой, а тот кто натягивает уже нарезает это на кусочки, вставляет вывод из базы итд.

Вопрос с кучей придуманных ограничений.
1. Почитайте про MVC. И код понятнее станет и читабельнее, и упоминаний страниц не будет.
2. Если Вы хотите без перезагрузок - вам нужно написать js код, который при изменении формы будет слать ajax запрос и соответственно рендерить его на страницу.
api.jquery.com/jquery.ajax в самом конце примеры

1. Скрипт на крон - однозначно плохая идея. Более правильная история - постоянно работающий скрипт который из очереди получает очередную задачу. Отличный вариант для организации очереди rabbitmq

2. Слабая связанность компонент это хорошо. В вашем случае однозначно api (не очень правда понимаю метания от php к java но дело Ваше. пишите на том, что лучше знаете) + расширяемые апи для внешних интеграций + интерфейсы цепляемые к апи.

По поводу синхронности/асинхронности - это вполне можно уместить в одном апи. Какие методы делать синхронными, какие нет - целиком зависит от вашей бизнес логики.
На мой взгляд получение баланса например вполне можно сделать синхронным.

3. С точки зрения быстродействия - Вы достаточно быстро упретесь в базу. Соответственно надо сразу думать о шардировании данных, о том как система будет себя вести в случае выхода из строя одной из задействованных в транзакции нод итд.

4. Вам важна data consistency. Сразу думайте про железо. Любые сервера горят. Брендовые сервера горят точно так же как и не брендовые. С учетом п3 - я бы делал полностью независимые друг от друга ноды, с физическим дублированием внутри ноды, и привязывал каждый счет к одной ноде.

5 [философский] Поймите важный момент - без ОЧЕНЬ серьезных инвестиций в маркетинг, проекты не взлетают. Если бы эти инвестиции были - Вы бы тут не писали (не в обиду). Соответственно вероятность того что к Вам внезапно придет огромный поток транзакций - стремится к нулю. К тому моменту когда Вы раскрутитесь - Вы успеете 5 раз сменить архитектуру проекта. Нельзя иметь одну архитектуру у стартапа собранного одним человеком, и у проекта с высокими HL/HA.
Пишите на чем нравится, у Вас будет куча времени что бы переписать узкие места например на C.

6 [юридический] Вы в курсе что Вам нужна пачка лицензий на осуществление деятельности в качестве оператора электронных денег и денежных переводов без открытия банковского счёта? :)

PS Я хочу верить что Ваш вопрос - это задачка для саморазвития. Иначе я не представляю себе что это за система платежная, которую делает один человек, спрашивающий совета как делать такие штуки (опять же не в обиду Вам ) :)

Нет никаких русских доменов. На самом деле это xn--e1aybc.xn--p1ai
Попробуйте указать info@xn--e1aybc.xn--p1ai в качестве адреса отправителя.
Далее читать про punycode

PS и да, отправить почту на info@тест.рф скорее всего ни у кого не получится.

stackoverflow.com/questions/7179216/php-problem-wi...
The solution was to simply reboot the server

1)

<input type="text" placeholder="поиск" name="searchword" method="$_GET">

Правильно пишется method="GET"

2)

RewriteRule ^search/ /search.php?%{QUERY_STRING} [L]

лучше писать
RewriteRule ^search/? /search.php?%{QUERY_STRING} [L]

3)

RewriteRule ^search/([A-Za-z0-9-]+)$ /search.php?page=$1&searchword=$2 [L]

У вас в регулярке стоит только 1 выражение - а мачится два.
Не очень понял что вы хотите получить, но могу предположить что правильно будет

RewriteRule ^search/([A-Za-z0-9-]+)/?$ /search.php?page=$1 [QSA,L]

Вот курсы https://developer.paypal.com/docs/classic/training/
Вот примеры кода https://developer.paypal.com/docs/classic/lifecycl...
Что именно там не понятно?

на выбор:

php.ini

post_max_size=200M
upload_max_filesize=200M

или

.htaccess

php_value post_max_size 200M
php_value upload_max_filesize 200M

На дешевых shared хостингах может не работать.

Как правильно написали @voiddancer и @nazarpc абсолютно не важно где у вас лежит файл на диске. Это html. Он разбирается браузером на стороне клиента. Он знает url по которому запросили страницу и больше не знает ничего.

Ссылки с "/" в начале загружаются от имени домена.
Ссылки без - от текущего пути.
Т.е если у Вас url страницы mysite.ru/partners
то "/css/all.css" будет искаться mysite.ru/css/all.css
а "css/all.css" - mysite.ru/partners/css/all.css
Собственно это все можно легко посмотреть в консоли браузера.

Если у Вас есть точное понимание что сайт всегда будет жить на отдельном домене - пишите ссылки вида "/css/all.css".
Если такого понимания нет - заведите переменную $basepath = 'http://mysite.ru' в конфиге сайта и в php генерите абсолютные ссылки: $basepath . '/css/all.css'

Использовать тег base я бы не рекомендовал, т.к во первых мне кажется неправильным правка html макетов при смене домена, а во вторых я многократно сталкивался с его странным поведением в различных браузерах.