Pages:
Author

Topic: Quick Bitcoin - шлюз для приёма платежей (Read 9412 times)

newbie
Activity: 26
Merit: 0
У нас произошли значительные изменения. В основном это исправление огромного количества ошибок, но кроме этого:
1. Теперь сайт доступен только по SSL - https://qbitpay.com
2. Введена система отзывов и репутация для продавцов. Каждая транзакция и каждый положительный отзыв добавляет 0.05 поинтов к репутации. Негативный отзыв снижает репутацию на единицу.
3. Написан модуль для WHMCS для приёма платежей с помощью нашего шлюза. Модуль будет выложен на сайте в разделе Downloads в течение суток.
newbie
Activity: 48
Merit: 0
Секретный ключ нужен для того, чтобы валидировать уведомление об успешном платеже. Что если клиент вам подделает уведомление? Разьве в mybitcoin такого нет?
вообще то секретный ключ на то и секретный, что его в открытом виде не передают никуда ))
Им подписывают передаваемые данные обычно. А на принимающей стороне проверяют подпись.
А в открытом виде ключ по сети передавать - это нонсенс )
LZ
legendary
Activity: 1722
Merit: 1072
P2P Cryptocurrency
Молодые проекты не прилепляются, пока не получат достаточно уважения в сообществе.

Добавляйте полезные темы в Избранное вашего любимого браузера. Smiley
sr. member
Activity: 350
Merit: 250
Перенесено в Бизнес. А зачем прилеплять-то? Undecided

Человек же упаривается искать. Пожалейте человека.
(Прошу прощения, не удержался).
LZ
legendary
Activity: 1722
Merit: 1072
P2P Cryptocurrency
Перенесено в Бизнес. А зачем прилеплять-то? Undecided
legendary
Activity: 1386
Merit: 1000
уже полностью работособен

Прилепите эту тему к верху. Я упариваюсь ее искать каждый раз.
newbie
Activity: 26
Merit: 0
может быть в дальнейшем что-нибудь и изобретём по валютам. хотя на мой взгляд это достаточно беспреспективно для нас.
newbie
Activity: 26
Merit: 0
Как вы рассчитаете хэш, если не знаете секретного ключа и он нигде не передаётся?

Лично я сейчас не собираюсь за вас продумывать логику работы и писать подробные объяснения для Ваших пользователей.
Просто обратил Ваше внимание, что написано не очень понятно.

Если я не рассчитаю, то и магазин не рассчитает. Если магазин рассчитает, то и man in the middle рассчитает.

пользуясь случаем, поздравляю себя с 500-м сообщением и пятой монетой
Просто у вас действительно проблемы с пониманием. Я объясняю довольно понятно. Для непонятливых: шлюзом создаётся строка из нескольких переменных, в том числе секретного ключа. Строка хэшируется, чтобы создать такой же хэш нужно иметь все составляющие строки. Хэш и все переменные, кроме секретного ключа, отправляется магазину. Магазин берёт полученные переменные, выстраивает их в строку, добавляет к ней секретный ключ, который он знает заранее, и получает точно такой же хэш. Все.
Ключ не передаётся между шлюзом и магазином. Поэтому man in the middle НИКАК не сможет составить такой же хэш, так как у него не будет всех составляющих строки, из которой нужно составлять хэш. Поэтому как он будет составлять хэш для подделки уведомления - для нормальных людей загадка.
Всё, что будет будет у man in the middle - переменные с информацией о платеже и готовый хэш. Ни получить новый такой же хэш, ни рассчитать из имеющихся данных (при хоть сколько нибудь серьёзном механизме хэширования) секретный ключ - почти невозможно.

Логику никто придумывать вас не просил. Всё уже давно придумано.  Максимум, что нам нужно - тестеры и общие советы.
legendary
Activity: 1386
Merit: 1000
Как вы рассчитаете хэш, если не знаете секретного ключа и он нигде не передаётся?

Лично я сейчас не собираюсь за вас продумывать логику работы и писать подробные объяснения для Ваших пользователей.
Просто обратил Ваше внимание, что написано не очень понятно.

Если я не рассчитаю, то и магазин не рассчитает. Если магазин рассчитает, то и man in the middle рассчитает.

пользуясь случаем, поздравляю себя с 500-м сообщением и пятой монетой
newbie
Activity: 26
Merit: 0
Вы вообще понимаете, для чего нужен SSL на сайте?

Да, я был неправ.
Но надежнее было бы все равно заставить магазин переспросить состояние запроса через GET.
а то еще бывают Man in the middle и тогда надо как-то этот POST подписывать, чтобы быть уверенным, что он не изменен в пути.
В дальнейшем будем делать так, как делает вебмани: передавать хэш cтроки, состоящей из объединённых данных по платежу (номер счёта, сумма) + секретный ключ. Сам секретный ключ в чистом виде передаваться не будет, а не зная его хэш невозможно будет расшифровать. Продавец тоже ничего не расшифровывает, просто делает хэш из присланных данных и секретного ключа и сравненивает этот хэш с присланным. Если хэши совпадают - значит уведомление не подделано. Man in the middle тут будет бесполезен.


Описано плохо - опишите еще раз. Если читать дословно - то Man in the middle как раз будет очень полезен,
потмоу что если продавец принимает решение о продаже только по присылаемым данным, то можно прислать другие даные и рассчитать новый хеш.

На самом деле, там где-то должна быть процедура подписывания, а магазин должен ЭЦП проверять открытым ключем платежного шлюза.
Как вы рассчитаете хэш, если не знаете секретного ключа и он нигде не передаётся?
legendary
Activity: 1386
Merit: 1000
Вы вообще понимаете, для чего нужен SSL на сайте?

Да, я был неправ.
Но надежнее было бы все равно заставить магазин переспросить состояние запроса через GET.
а то еще бывают Man in the middle и тогда надо как-то этот POST подписывать, чтобы быть уверенным, что он не изменен в пути.
В дальнейшем будем делать так, как делает вебмани: передавать хэш cтроки, состоящей из объединённых данных по платежу (номер счёта, сумма) + секретный ключ. Сам секретный ключ в чистом виде передаваться не будет, а не зная его хэш невозможно будет расшифровать. Продавец тоже ничего не расшифровывает, просто делает хэш из присланных данных и секретного ключа и сравненивает этот хэш с присланным. Если хэши совпадают - значит уведомление не подделано. Man in the middle тут будет бесполезен.


Описано плохо - опишите еще раз. Если читать дословно - то Man in the middle как раз будет очень полезен,
потмоу что если продавец принимает решение о продаже только по присылаемым данным, то можно прислать другие даные и рассчитать новый хеш.

На самом деле, там где-то должна быть процедура подписывания, а магазин должен ЭЦП проверять открытым ключем платежного шлюза.
newbie
Activity: 26
Merit: 0
Вы вообще понимаете, для чего нужен SSL на сайте?

Да, я был неправ.
Но надежнее было бы все равно заставить магазин переспросить состояние запроса через GET.
а то еще бывают Man in the middle и тогда надо как-то этот POST подписывать, чтобы быть уверенным, что он не изменен в пути.
В дальнейшем будем делать так, как делает вебмани: передавать хэш cтроки, состоящей из объединённых данных по платежу (номер счёта, сумма) + секретный ключ. Сам секретный ключ в чистом виде передаваться не будет, а не зная его хэш невозможно будет расшифровать. Продавец тоже ничего не расшифровывает, просто делает хэш из присланных данных и секретного ключа и сравненивает этот хэш с присланным. Если хэши совпадают - значит уведомление не подделано. Man in the middle тут будет бесполезен.
legendary
Activity: 1386
Merit: 1000
Вы вообще понимаете, для чего нужен SSL на сайте?

Да, я был неправ.
Но надежнее было бы все равно заставить магазин переспросить состояние запроса через GET.
а то еще бывают Man in the middle и тогда надо как-то этот POST подписывать, чтобы быть уверенным, что он не изменен в пути.
newbie
Activity: 26
Merit: 0
Будет ли ваш сайт представлен в сети i2p ?
Будет
newbie
Activity: 26
Merit: 0
Что если клиент вам подделает уведомление?

Вот для этого нужен сертификат сервера в SSL. Его клиент не подделает. Поэтому в mybitcoin лишних глупостей нет.
Ну что за феерический бред. Вы вообще понимаете, для чего нужен SSL на сайте? Чтобы КЛИЕНТ был уверен, что не подделан САЙТ и чтобы данные шифровались. Как ssl может остановить клиента от отправки POST запроса на ваш сайт - я не понимаю.
legendary
Activity: 1386
Merit: 1000
Будет ли ваш сайт представлен в сети i2p ?
legendary
Activity: 1386
Merit: 1000
Что если клиент вам подделает уведомление?

Вот для этого нужен сертификат сервера в SSL. Его клиент не подделает. Поэтому в mybitcoin лишних глупостей нет.
newbie
Activity: 26
Merit: 0
Полный аналог оплаты на mybitcoin.com. Хотелось бы видеть русский язык, красивый дизайн, примеры использования на php. И покажите нам пример формы. А пока что предпочту mybitcoin.

Насколько мне известно, сейчас существует "редиректор платежей" mybitcoin, выполняющий примерно ту же функцию, что и Quick Bitcoin, но судя по отзывам он не отличается ни стабильностью работы, ни быстрым процессингом платежей. Мы постараемся вывести обработку платежей на новый уровень по скорости, безопасности и функциональности.
Отзывы редко пишут, когда всё работает как и должно Smiley Пока только прикручиваю всё к своему сервису, при тестах проблем не было.

На каких технологиях может быть магазин? Если магазин на ASP .MONO - как туда интегрировать интерфейс со шлюзом ?
Кратко составляем специальную ссылку, с количеством для оплаты, страницей для перехода после успешной и отменённой оплаты и переходим на неё из нашего магазина.
Как только покупатель проводит оплату - мы отправляем магазину POST запрос, в котором будет указана оплаченная сумма, номер счёта и секретный ключ. Магазин сверяет номер счёта и полученную сумму и секретный ключ.
А зачем секретный ключ и насколько он секретный?
Пока что мы работаем в тестовом режиме и вы правильно делаете, что используете mybitcoin. Примеры, готовые модули, русский язык - будет.
Секретный ключ нужен для того, чтобы валидировать уведомление об успешном платеже. Что если клиент вам подделает уведомление? Разьве в mybitcoin такого нет?

SSL будет
LZ
legendary
Activity: 1722
Merit: 1072
P2P Cryptocurrency
Меня пока смущает отсутствие доступа по https. Undecided
Pages:
Jump to: