Перейти к содержимому


Фото
- - - - -

Подмена домена при заказе и его оплате


  • Чтобы отвечать, сперва войдите на форум
19 ответов в теме

#1 martinways

martinways
  • Пользователь
  • 88 сообщений

Опубликовано 24.08.2018 - 10:29

Может кто знает как решить такую задачу. У меня есть сайт с секс-шоп товарами и некоторые платежные системы такие товары не любят, например система QIWI, а также многие другие системы не хотят подключать магазин такой тематики. Также у меня есть интернет-магазин смартфонов, который платежные системы принимают к подключению. Вопрос  - как можно проще всего реализовать такую схему - покупатель оформляет заказ на сайте покупая товар "Для взрослых", но после оформления заказа при нажатии на кнопку "ПЕРЕЙТИ К ОПЛАТЕ" выбранного способа оплаты на странице заказа переход на сайт платежной системы осуществлялся как бы с магазина смартфонов? То есть чтобы в глазах платежной системы переход для оплаты происходил с сайта-обманки. Это вообще технически реализуемо или нет? Хотелось бы чтобы покупатель не перенаправлялся на сайт-обманку, или хотя бы он этого не замечал, просто у сайтов-то дизайн абсолютно разный. Разве что уже на сайте самой платежной системы будет написано, что оплата производится на домен сайта-обманки, но это не страшно. Готов оплатить такую доработку, пишите в личку цену.


Изменено: martinways, 24.08.2018 - 10:51


#2 vizes

vizes
  • Пользователь
  • 7 сообщений
  • Программирование, Верстка, Пользователь
  • Версия CMS:2.x
  • Откуда:Москва

Опубликовано 24.08.2018 - 12:09

Добрый день. При переходе к оплате платежке передаются данные. Как вариант, сделать на сайте смартфонов станицу, на которую будет переадресация. Страница будет или пустая, или под нужный дизайн. На ней можно ловить передаваемые данные и отправлять их в платежку. После оплаты ловить ответ опять на сайте смартфонов и перенаправлять на нужный сайт. 


Изменено: vizes, 24.08.2018 - 12:09


#3 phukortsin

phukortsin
  • Пользователь
  • 525 сообщений
  • Программирование, Пользователь
  • Версия CMS:2.x
  • Откуда:Львов

Опубликовано 24.08.2018 - 12:58

Может кто знает как решить такую задачу. У меня есть сайт с секс-шоп товарами и некоторые платежные системы такие товары не любят, например система QIWI, а также многие другие системы не хотят подключать магазин такой тематики. Также у меня есть интернет-магазин смартфонов, который платежные системы принимают к подключению. Вопрос  - как можно проще всего реализовать такую схему - покупатель оформляет заказ на сайте покупая товар "Для взрослых", но после оформления заказа при нажатии на кнопку "ПЕРЕЙТИ К ОПЛАТЕ" выбранного способа оплаты на странице заказа переход на сайт платежной системы осуществлялся как бы с магазина смартфонов? То есть чтобы в глазах платежной системы переход для оплаты происходил с сайта-обманки. Это вообще технически реализуемо или нет? Хотелось бы чтобы покупатель не перенаправлялся на сайт-обманку, или хотя бы он этого не замечал, просто у сайтов-то дизайн абсолютно разный. Разве что уже на сайте самой платежной системы будет написано, что оплата производится на домен сайта-обманки, но это не страшно. Готов оплатить такую доработку, пишите в личку цену.

 

Технически реализуемо и даже как-то приходилось делать подобное.

 

При заказа с основного сайта будет сразу открываться страница платежной системы (скрытым образом через обманку).

На той странице будет указан сайт-обманка, поэтому переход с этой страницы ОБРАТНО К ПРОДАВЦУ, естественно, произойдет  на обманку. Но можно тот переход редиректить на основной сайт, опять же, почти незаметно для покупателя.

 

Но самое главное - посетитель  на странице платежной системы будет видеть оплату на ДРУГОЙ сайт - это внимательного покупателя может озадачить и заставить задуматься. Если это не смущает, то технически все организовать можно.



#4 DaVinci

DaVinci
  • Фрилансер
  • 1 139 сообщений
  • Программирование, Верстка
  • Версия CMS:1.x, 2.x
  • Откуда:SimplaDev.ru

Опубликовано 24.08.2018 - 13:48

не стоит делать ни каких "Обманок", ничего хорошего из этого не получится 

 

достаточно завести 3-й сайт для приема платежей. вопрос только в том что заказы должны хранится в одной базе. и тут возникнет ряд сложных задач. проще организовать многосайтовость



#5 phukortsin

phukortsin
  • Пользователь
  • 525 сообщений
  • Программирование, Пользователь
  • Версия CMS:2.x
  • Откуда:Львов

Опубликовано 24.08.2018 - 13:52

не стоит делать ни каких "Обманок", ничего хорошего из этого не получится 

 

достаточно завести 3-й сайт для приема платежей. вопрос только в том что заказы должны хранится в одной базе. и тут возникнет ряд сложных задач. проще организовать многосайтовость

 

В данном случае термин "обманка" условный и  просто  означает ДРУГОЙ сайт. Так что использовать обманку (2-й сайт) или 3-й сайт для приема платежей - разницы почти никакой...



#6 DaVinci

DaVinci
  • Фрилансер
  • 1 139 сообщений
  • Программирование, Верстка
  • Версия CMS:1.x, 2.x
  • Откуда:SimplaDev.ru

Опубликовано 24.08.2018 - 13:59

В данном случае термин "обманка" условный и  просто  означает ДРУГОЙ сайт. Так что использовать обманку (2-й сайт) или 3-й сайт для приема платежей - разницы почти никакой...

 

разница есть. 



#7 martinways

martinways
  • Пользователь
  • 88 сообщений

Опубликовано 24.08.2018 - 14:48

разница есть. 

 

Так какой вариант лучше реализовать чтобы и покупателя не ввести в сомнения и платежная система не "спалила" подмену? Можете схематически пояснить принцип? 



#8 DaVinci

DaVinci
  • Фрилансер
  • 1 139 сообщений
  • Программирование, Верстка
  • Версия CMS:1.x, 2.x
  • Откуда:SimplaDev.ru

Опубликовано 24.08.2018 - 15:19

Так какой вариант лучше реализовать чтобы и покупателя не ввести в сомнения и платежная система не "спалила" подмену? Можете схематически пояснить принцип? 

 

2 варианта - многосайтовость или api. 3-й домен нужен, именно на нем можно указать список сайтов с которых принимаются платежи и прочу и информацию. 

 

в случае с многосайтовость есть много своих преимуществ но реализация трудозатрантная. Api попроще - запрашивает и устанавливает новый статус заказа по номеру который прилетает с платежной системы. достаточно расспарсить номер по какому нибудь признаку.



#9 martinways

martinways
  • Пользователь
  • 88 сообщений

Опубликовано 24.08.2018 - 15:36

2 варианта - многосайтовость или api. 3-й домен нужен, именно на нем можно указать список сайтов с которых принимаются платежи и прочу и информацию. 

 

в случае с многосайтовость есть много своих преимуществ но реализация трудозатрантная. Api попроще - запрашивает и устанавливает новый статус заказа по номеру который прилетает с платежной системы. достаточно расспарсить номер по какому нибудь признаку.

 

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



#10 shooroop

shooroop
  • Фрилансер
  • 740 сообщений
  • Дизайн, Программирование, Верстка
  • Версия CMS:2.x
  • Откуда:Antarktida

Опубликовано 24.08.2018 - 16:43

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

 

так в чем проблема.

 

у вас есть сайт xxx.ru (эротика)  заливаете туда товары смартфоны и тему под смартфоны. посылаете заявку  ждете одобрения. вам одобрили. меняете товары и дизайн на эротику.



#11 martinways

martinways
  • Пользователь
  • 88 сообщений

Опубликовано 24.08.2018 - 17:17

так в чем проблема.

 

у вас есть сайт xxx.ru (эротика)  заливаете туда товары смартфоны и тему под смартфоны. посылаете заявку  ждете одобрения. вам одобрили. меняете товары и дизайн на эротику.

 

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


Изменено: martinways, 24.08.2018 - 17:18


#12 shooroop

shooroop
  • Фрилансер
  • 740 сообщений
  • Дизайн, Программирование, Верстка
  • Версия CMS:2.x
  • Откуда:Antarktida

Опубликовано 24.08.2018 - 17:24

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

 

яндекс касса вам в помощь



#13 martinways

martinways
  • Пользователь
  • 88 сообщений

Опубликовано 24.08.2018 - 17:45

яндекс касса вам в помощь

 

Нет российской регистрации частного предпринимателя. 

 

Ну так что, господа, кто-то возьмется за реализацию? Не бесплатно же.



#14 ps-simpla

ps-simpla

    Модератор в запасе :)

  • Модератор
  • 1 003 сообщений
  • Дизайн, Программирование, Верстка
  • Версия CMS:2.x
  • Откуда:Пермский край

Опубликовано 25.08.2018 - 13:34

хм, а если вариант 
1. сайт сексшоп
2. сайт смартфоны
----
БД одно но префиксы разные
1. sex_
2. s_ 

 

НО таблица заказов одна на оба сайта

т.е. делаем заказа на сексшопе, заказ падает на сексшоп и на смартфоны, после чего при наджатии на оплату происходит перенаправления на сайт смартфоны для оплаты там и оплачиваем

но как пользователь поведет себя? когда его с сайта на сайт кидает?

как то так



#15 phukortsin

phukortsin
  • Пользователь
  • 525 сообщений
  • Программирование, Пользователь
  • Версия CMS:2.x
  • Откуда:Львов

Опубликовано 25.08.2018 - 13:53

хм, а если вариант 
1. сайт сексшоп
2. сайт смартфоны
----
БД одно но префиксы разные
1. sex_
2. s_ 

 

НО таблица заказов одна на оба сайта

т.е. делаем заказа на сексшопе, заказ падает на сексшоп и на смартфоны, после чего при наджатии на оплату происходит перенаправления на сайт смартфоны для оплаты там и оплачиваем

но как пользователь поведет себя? когда его с сайта на сайт кидает?

как то так

 

"НО таблица заказов одна на оба сайта" - некоторая морока будет.

А вообще чем это лучше предлагавшегося ранее перенаправления? По-моему, примерно то же самое, но в усложненном виде. Если это для того, чтобы номера заказов на сайтах не совпадали, то это можно сделать куда проще - например, на одном сайте ID заказов сделать четные, на другом нечетные.


Изменено: phukortsin, 25.08.2018 - 14:50


#16 vizes

vizes
  • Пользователь
  • 7 сообщений
  • Программирование, Верстка, Пользователь
  • Версия CMS:2.x
  • Откуда:Москва

Опубликовано 25.08.2018 - 13:59

Готов помочь за минимальное вознаграждение или за спасибо) Обращайтесь в Скайп.



#17 martinways

martinways
  • Пользователь
  • 88 сообщений

Опубликовано 25.08.2018 - 15:12

Только что меня осенила такая идея, вроде должно получиться. Есть например 2 сайта на одном хостинге  xxx.com и mobi.com,  создаем поддомен  order.mobi.com  и заливаем на него копию файлов сайта xxx.com вместе с подключением к базе xxx.com, потом на этом же поддомене шаблон переделываем таким образом, чтобы осталась только страница заказа и возможность выбора способа оплаты, дизайн оформляем в виде промежуточной платежной страницы. В htaccess этого же поддомена устанавливаем условие - если вход по адресу order.mobi.com, то переадресация на mobi.com , а если вход по ссылке заказа order.mobi.com/order/(token) , то переадресацию не делать. В итоге получается - покупатель оформляет заказ на xxx.com , после оформления появляется кнопка "Выбрать способ оплаты", которая направит на страницу выбора способа оплаты этого же заказа, но по адресу order.mobi.com/order/(token) , так как поддомен подключен к базе xxx.com, пользователь совершает оплату, в глазах платежной системы оплата будет проведена с поддомена одобренного mobi.com и все красиво и даже если проверяющий работник ПС будет переходить на поддомен order.mobi.com, то его перекинет на mobi.com. Единственный момент - да, покупатель будет видеть в адресной строке браузера изменение ссылки на order.mobi.com, но мне кажется все привыкли к промежуточным страницам типа INTERKASSA и т.д. В общем, сейчас буду пробовать, по идее все четко и не нужно колхозить с префиксами и т.д. Сайт-обманка mobi.com остается при этом полностью независимым и полноценным.


Изменено: martinways, 25.08.2018 - 15:16


#18 phukortsin

phukortsin
  • Пользователь
  • 525 сообщений
  • Программирование, Пользователь
  • Версия CMS:2.x
  • Откуда:Львов

Опубликовано 25.08.2018 - 15:45

После реализации этого, если проверяющий хоть чуть соображает, то он откроет order.mobi.com, его перекинет на mobi.com, он там для теста быстренько сделает заказ, попробует сделать оплату и увидит, что она идет не с того сайта, с какого множество ранее сделанных заказов. Что подозрительно...

 

Кроме того, на том и другом сайте посетители могут захотеть оплатить через ту платежную систему  заказ N 78  на первом сайте и  заказ N 78 на втором сайте. Что-то мне кажется, не сработает как следует...



#19 martinways

martinways
  • Пользователь
  • 88 сообщений

Опубликовано 25.08.2018 - 15:52

После реализации этого, если проверяющий хоть чуть соображает, то он откроет order.mobi.com, его перекинет на mobi.com, он там для теста быстренько сделает заказ, попробует сделать оплату и увидит, что она идет не с того сайта, с какого множество ранее сделанных заказов. Что подозрительно...

 

Кроме того, на том и другом сайте посетители могут захотеть оплатить через ту платежную систему  заказ N 78  на первом сайте и  заказ N 78 на втором сайте. Что-то мне кажется, не сработает как следует...

 

Испытал мой метод - все работает, осталось допилить дизайн и т.д. А насчет проверки с оплатой - ну не знаю, сомнительно, что прямо настолько будут докапываться, хотя все может быть конечно. У Вас есть какой-то лучший вариант, чтобы не курочить полностью движки и базы данных обоих сайтов? Напишите Ваш вариант, или если не хотите на всеобщее обозрение, то тогда в личку.


Изменено: martinways, 25.08.2018 - 15:53


#20 pudohom

pudohom
  • Пользователь
  • 67 сообщений
  • Пользователь
  • Версия CMS:2.x
  • Откуда:Пермь

Опубликовано 26.08.2018 - 13:54

После реализации этого, если проверяющий хоть чуть соображает, то он откроет order.mobi.com, его перекинет на mobi.com, он там для теста быстренько сделает заказ, попробует сделать оплату и увидит, что она идет не с того сайта, с какого множество ранее сделанных заказов. Что подозрительно...

 

Кроме того, на том и другом сайте посетители могут захотеть оплатить через ту платежную систему  заказ N 78  на первом сайте и  заказ N 78 на втором сайте. Что-то мне кажется, не сработает как следует...

Добавьте префикс к номеру заказа на одном из сайтов и проблема с номерами заказов будет решена.






0 пользователей читают эту тему

0 пользователей, 0 гостей, 0 скрытых