Александр Мастеров

1. Открываешь ИП, к нему транзитный валютный счет. Рассчетный валютный счет можно открыть если желаешь сидеть в долларах.
2. Делаешь wire трансфер с Upwork, уплачивая 30$ за перевод.
3. После перевода деньги блокируются валютным контролем.
4. Дальше два варианта, либо выбить из поддержки договор (что почти нереально), либо отдать в ВК публичную оферту (User Agreement, на который соглашаемся при регистрации) в биллингве, на каждой странице публичной аферты поставить свою печать, "Копия верна" и подпись (после этих действий ВК охотней примет публичную аферту, нежели просто распечатанный биллингв).
5. На каждый денежный перевод нужен акт выполненных работ, тут два варианта. Либо предоставить в ВК скриншот трансфера из панели апворка (что филькина грамота, не каждый ВК примет это), либо запрашивать у поддержки "Act of acceptance", который будет подписан апворком и тобой, в нем будет указана сумма перевода. Act of acceptance выглядит внушительней, нежели скрин из панели.
6. Дальше при каждом переводе предоставляешь новый Act of acceptance.
7. Работаешь так до достижения лимита в 50000$, дальше нужно заключить паспорт сделки (что сложно, но реально, нужно трясти поддержку апворка). ЛИБО заключить новый "контракт" с Upwork, опять предоставив User Agreement в билингве (про схему с закрытием старой оферты и открытием новой вычитал на хабре, там чувак ставил номер контракта в шапке оферты, что позволяло "открыть" новый контракт, поменяв этот номер)
8. Ну и работаем дальше, либо по паспорту сделки, либо по вновь открытому контракту.

Забыл. Когда ВК подтверждает перевод, то тут 2 варианта. Либо эти даллары "продаются" с транзитного счета на рублевый счет ИП по курсу ЦБ на день продажи, либо переводятся на долларовый счет ИП. Но у нас есть налог на курсовую разницу, потому эти деньги лучше сразу вывести с долларового счета ИП на долларовый физика.

Есть два варианта хранения данных об авторизованном пользователе:
1) В куки (так по умолчанию используется в асп.нет): необходимые данные (claims) шифруются machineKey и отдаются пользователю в http-only куках, таким образом при каждом запросе на сервер они присылаются, расшифровываются и далее можно проверить в необходимых местах.
плюсы: полностью stateless, нет надобности обращаться к БД
минусы: при необходимости "выбить" сессию со стороны сервера нужно поднимать более сложную логику и хранить флаги в промежуточном хранилище (проверять что если для такого-то пользователя требуется завершить, то такие действия, иначе другие);
2) Ключ сессии: после успешной аутентификации авторизуем пользователя и claims храним на сервере в быстрой памяти или БД (key-value), где ключ - ключ сессии, значение - любые данные.
плюсы: есть полный контроль состоянием авторизации (как и возможность завершить сессию со стороны сервера, так и сменить пользователю роль(или другие параметры) "на лету")
минусы: организация доп. прослойки - кэша или хранение в БД (медленно), при перезапуске/падении сервиса сессии клиентам потребуется перелогиниться.

1
1.1 В куки писать или ключ сессии или шифрованные данные о пользователе, сессия - абстрактное понятие (это пара: ключ и данные), ключ должен быть защищенным, т.е. трудным к копированию (хотя бы зрительно трудно запомнить), уникальным (чтобы не возникло коллизий: двум разным пользователям выдался один и тот же ключ, т.е. это не должна быть хэш-функция от логина-пароля или IP или чего-то неуникального).
1.2 В асп.нет существуют атрибуты авторизации (в которых можно расставлять проверки на требование таковой, роль, конкретный пользователь), в общем смысле логика такова: поступил запрос на сервер, далее нужно посмотреть к какому ресурсу идёт обращение (защищенному или свободному), если ресурс защищен, то проверить куки (ключ сессии или шифрованные данные), расшифровать/получить данные о сессии из кэша и предпринять решение: пускаем или не пускаем (отдаём 401/403 или отдаем 200/404/...).
1.3 Завести на сервере (в кэше или БД) словарь , при алгоритме проверки сессии добавить условие проверки на наличие записи в словаре.
1.4 С нескольких - словаря не нужно.

2
2.1 Даже если пользователь входит через ВК всё равно нужно отдавать свои ключи сессий/шифрованные данные, а вот внутри данных уже хранить access_token от вк-шной сессии, так очень маленькая вероятность, что токен ВК утечет, а если утек ключ сессии, то действия будут ограничены только функционалом сайта.
2.2 После расшифровки куки или данных по ключу сессии делать доп запрос на сервер ВК с токеном, который сохранился при аутентификации (access_token), запрос простой, например получить имя пользователя, если ВК выдал что токен просрочен или ошибку, то сессию закрывать или куки с данными обнулять.

ИП не обязан открывать счет для юр.лица, такого в законодательстве нет.
Банки сами просят открывать ИП счет как юр.лицо, это их внутренние правила, что бы срубить денег.
Так что, открывайте обычный счет на физ.лицо и пользуйтесь.
Да, правильно говорили выше, открываете отдельный счет для перечислений и отдельный карточный счет Мастеркард, например. И все будет гуд.
Я сам ИП уже 4 года, пользуюсь ВТБ24 и Промсвязь, как физ.лицо. Эти же счета предоставлял в налоговую, у налоговой вопросов не возникло. По закону имущество ИП и физ.лица неделимы, то есть если ты продаешь квартиру как физ.лицо, то документы в налоговую ты предоставляешь как ИП. Так же и с деньгами, если вам перечислили денежку на счет, вы сразу можете покупать на нее хлеб в магазине без проблем, это уже деньги вас как физ.лица.

Если вдруг у банка возникают вопросы, просто уходите в другой банк. Хоть 800 руб/мес и не большие деньги, но зачем платить больше, если тот же функционал в ОнлайнБанкинге есть и у физ.лица.
А вообще, меня бесят некоторые банки с их наглостью, их внутренние правила граничат с законностью...

Проект не стандартный. Скрипт сопоставления цен чего только стоит. Я имел дело с подобными проектами. Заставить это все работать без багов, дело хлопотное. Что-то поменялось в прайсе стороннего магазина и все. Сомневаюсь, что данный проект может жить без постоянного программера.Главный вопрос - получение данных от других магазинов. У них api или прайсы в csv или xml? Или парсить надо?
В зависимости от ТЗ оценил бы проект от 50 до 150k. если идея сделать, что-то типа яндекс-маркета - то надо собирать команду на гитлабе и колбасить несколько месяцев.
То что движки для этого не пригодны - факт. Надо брать фреймворк (yii2, symfony, laravel) и делать.
Думаю автор не совсем понимает, насколько это трудоемко. И тот кто возьмется это сделать за 10 - тоже не понимает.

Вы с ума сошли что ли? Какие 7к? Верстка + программирование 7к? Допустим, что на каком-нибудь несчастном опенкарте это сделать, но какие магазины? Есть ли у них АПИ нормальное или тащить самим? От 50к и выше нормальная работа стоит.

Не стоит, постоянно будет голова болеть.

Вы наверное не знаете. Но у вас уже есть один идеальный и не привередливый заказчик, которого вы к сожалению выпускаете из виду и обделяете вниманием. Это ВЫ САМ.

Я когда-то был профи битрикса и скажу, что бОльшая часть компонентов сделана из говна и палок.

habrahabr.ru/post/247769

Крутые программисты сами себя делают, а не вузы их.

в умелых руках граббер/скраппер превратит любой сайт в "имеющий АПИ" )

• Фильтр Блума.
  
• Бор Ахо-Корасик.
  

Вам на фриласим за этим вопросом

Начнём с того, что MVC в классическом виде для PHP это не применимо, это для десктопных приложений придумали, а то, что называют MVC - то немного/совсем другое, если вы совсем начинающий, то отложите этот вопрос.

А вот ООП в целом штука хорошая. Вы делите ваше приложение на элементы, каждый элемент является объектом. У объектов есть свойства и методы, с помощью которых осуществляется взаимодействие с внешним миром, свойства для данных, методы для действий. Так же у объекта могут быть приватные свойства/методы, которые снаружи вызвать нельзя, но которые используются самим объектом для его нужд. Ничего сложного в этом нет. Ещё есть классы - это скелеты объектов, как шаблон, по подобию которого вы создаете столько объектов, сколько нужно. Объекты бывают похожими, тогда одни объекты могут наследовать свойства и методы других объектов.

Для затравки этого должно быть достаточно чтобы не потеряться.