Обменялись, норм. Оперативно и без всяких проблем. Для теста разбил платеж на маленький кусочек + все остальное, все прошло ок. БЛ вполне располагает к обмену
Школьник все засейлит через фотоальбом вконтакте, или же через фри движок какого-нить шопа, найдя три копейки на платный хостинг. А бабушка - та не умеет даже смски набирать, какой тут ИМ
Но это ИМХО, и оно не обязано быть верным
Когда человек платит вам деньги то с точки зрения закона у вас перед ним появляется непогашенное обязательство. Гасится оно актом приемки-передачи, или уведомлением о получении посылки на почту с подписью получателя. Это к тому, что люди когда денег платят на Р/С часто задают вопросы "а что если я заплатил, а вы не прислали - что тогда?"
Это если вы бабки не гоняете на карточку, т.к. по определению пополнение карточки или прямой перевод не может быть связано с предпринимательской деятельностью и об этом есть много где куча примечаний
Что значит "сканов нету"? У вас документов нет? Или отсканировать тяжело? Кстати если у вас есть торговая точка - ксерокопии обязаны быть там в уголке покупателя
P.S. В Opera 12.17 у вас шрифты в меню не отображаются, лечите верстку через @font-face в css.
Ну вот про метод оплаты через приват я и говорил. Это незаконно, и оспорить в ментовке такую оплату сильно сложнее, чем оплату на Р/С в банке. Тем более сейчас, когда Украина коллапсирует и все парализовано.
Да и повесьте городской номер телефона, он с переадресацией на мобилу копейки стоит. Влияет на доверие
Если вы уверены, что "боятся" - сделайте чтобы не боялись. Выложите сканы правоустанавливающих документов, выложите банковские реквизиты для платежа, проведите ликбез про "непогашенное обязательство" и прочие нюансы. Помогает фотографирование оффлайн-точки (офиса или чего иного) так, чтобы в том числе и фасад здания был.
Вот в целом изучайте - http://www.nngroup.com/articles/about-us-information-on-websites/
Считаю, что как раз бесплатность - это вред. ИМ это бизнес. Если человек не научился преодолевать психологический порог "потратить немного денег в бизнес" - то либо у него все совсем плохо и бизнесом ему заниматься пока рано, или у него денег нет вобще (и бизнесом заниматься рано, надо на еду зарабатывать), или он по крайней мере не уверен в необходимости трат (то есть сильно плавает в вопросах "а это ваще дорого, дешево или как?").
Мускул бывает разный
1) версия (ага она влияет)
2) тип таблиц
3) структура таблиц (такого можно наваять...)
4) правильно расставленные ключи
5) запросы (опять же, есть любители JOIN запросов, их ИМХО нельзя использовать там, где не надо)
6) архитектура самого "кластера" (если вы выделяете под мускул сервер с достаточным кол-вом оперативы и правильно его настраиваете - все будет ок)
Поэтому как-то так. С одной стороны - есть пример, 150к хостов в сутки, каждый хост генерит 2-3-5 хитов, не очень много. 80% инсерт запросы, 20% селекты. Внутри замороченная архитектура, но все оптимизированно. Так вот, под БД выделен за $150 сервер с 16 гигами оперативы, поднарастили до 32 впоследствии. Все летает.
И альтернативный пример. Не знаю какой трафик, бд 160 гигов, и написана очень-очень криво. Так вот, там куплено что-то немеряно дорогое, но все равно каждый alter table - только с дауном на несколько часов и только по подписанной служебке.
Так что оно по разному бывает
Вы путаете позиционирование SaaS и элитного решения. Вашими устами бы да мед пить. Никто ничего в Saas`е под вас лично делать не будет. В лучшем случае там будет страничка с реквестированием функционала, и если будет много голосов - будет и допил.
http://www.insales.ru/signup
http://umi.ru/help/account/vyvod_sayta_iz_sistemy/ тут есть миграция из облака на хостинг
На http://premmerce.ru/ никакого упоминания про кастомизацию нет
У меня есть много опыта по проблемам по доработке когда команда продает по умолчанию кастомный продукт, из сферы банкинга. А вы вообще про облако говорите...
Выбор можете сделать только вы на основе имеющихся у вас в голове критериев. То есть фантазируете на тему "что должно быть обязательно в моем ИМ", потом сравниваете идеал с тем, что есть - и выбираете. Советовать вам здесь глупо, т.к. для кого-то важен какой-то один функционал, для вас - может быть совсем другой (под функционалом понимаю не только чисто возможности движка, но и дальнейшее развитие - как получать поддержку, как мигрировать на более свободные решения и т.д.)
Плюсами облачного сервиса (любого) являются его вылизанность (меньше глюков), явный период тестов, какая-то техподдержка, удобство "одной кассы".
Минусами - вероятная невозможность сменить решение (есть ли там экспорт товаров и т.д.?), вероятная невозможность забрать себе свой домен назад, негибкость в разработке фич (вам в облаке какой-то специфический функционал никто делать не будет, это облако), принципиальная зависимость от жизни сервиса (закроется через 5 лет - и вам трындец).
Плюсы стандалона (своего магазина, не важно платного или нет) - зеркало минусов облака. Вы можете допилить все что хотите, произвести любые изменения, какие хотите, зависите только от себя.
Минусы стандалона - или дороговизна покупки, или проблемы с поддержкой внешней командой вашего бесплатного решения, заморочки с доменами-хостингами (все надо самому, в одно окно как с облаком не получится)
По поводу негибкостей - сейчас вы можете реально не понимать о чем речь, вам может казаться, что "все и так в облаке есть". Навскидку что можно допиливать
- парсеры товаров из прайсов или для наполнения
- боты, которые автоматизируют создание объявлений на досках типа авито или в директе или вконтакте
- сложные фильтры-выборки для ваших товаров (например отображение аксессуаров только к данному типу кальянов и т.д.)
- дополнительные сервисы в магазине (статьи, темы форумов), напрямую интегрированные в магазин (хотя бы по логону)
- всевозможный функционал админки (учет склада, логистика курьера, хитрые отчеты по покупкам, интеграция со складскими программами которые не 1С и т.д.)
По поводу домена и прочего. Для SEO очень важен как домен, так и структура ссылок к каждой странице. Если вы смените движок и вместо ссылок site.ru/category/good у вас будут site.ru/?good_id=123 - все ваше SEO накроется медным тазом, и доставать его оттуда будет сложно и иногда невозможно. Что правильно смигрировать вам нужно
а) знать заранее формат или список ссылок
б) иметь возможность на том, куда вы мигрируете, воспроизвести этот формат ссылок
Т.к. я считаю, что в случае развившегося проекта до некоторых бюджетов вам при любом раскладе придется мигрировать - смотрите заранее на возможности миграции в том облаке, которым хотите пользоваться сейчас
При чем тут интернет-магазин? Это канал продаж. Продажу осуществляет определенное и одно лицо (юр или физ), и это лицо определяется
а) из реквизитов выданного чека
б) из реквизитов счета, куда вы платите деньги
При этом оно хоть через авито вам продает - авито тут при чем?
При этом однозначно на каждый товар должно быть понятно написано куда совершать рекламацию и т.д. Идеально - на каждой карточке товара иметь строчку "Гарантия - ** месяцев, подробнее - ссылка", а по ссылке детальная страница с точками, юрлицами и т.д. + из меню сводная страница, описывающая какой товар куда возвращается и т.д.
Я не знаю, как вы себе представляете функционирование скриптов, реально это выглядит так приблизительно - скрипт выполняет локальные операции, потом выполняет запрос в БД, потом его отрабатывает и выдает результат. Здесь два узких момента
1) инфраструктурные расходы на посетителя на веб-сервере (апач и т.д.)
2) расходы на запрос и обработку запроса к БД
Если у вас тяжелый в смысле вычислений код - то оторвать руки программисту, или нечастая задача, которая не является типичной для посетителя сайта. Поэтому тут влияет кол-во юзеров
Если у вас база маленькая и оптимизирована, но запрос кривой - то и 1 пользователь долго ждет. Избавляется от джоинов и все будет летать (то есть вопросы к оптимизации запросов к БД)
А вот если у вас все оптимизировано - втает проблема
1) размера базы
2) кол-ва юзеров, одновременно ее дергающих (то есть трафик)
Т.к. у типового ИМ база не может быть большой (большая база - это миллионы транзакций весом в десятки гигов, которые постоянно висят в оперативе в силу специфики формата БД, содержащие какие-то относительно длинные текстовые данные типа useg agent посетителя, referer и так далее) - то горлышко бутылки при прямых руках - именно трафик в смысле посещений
Хотите стойку купить - покупайте. Наверное, на битриксе сидите. Нормальные скрипты не предъявляют таких требований к железу на малых посещениях
Поэтому
