Bitcoin Forum

Хочу представить свой проект, предоставляющий автоматизиваронный интерфейс для приёма bitcoin платежей - Quick Bitcoin.
Quick Bitcoin представляет собой платёжный шлюз для приёма платежей по стандартной схеме большинства платёжных систем: отправка формы запроса платежа с сайта магазина, редирект пользователя на интерфейс платёжной системы, оплата, автоматическое уведомление магазина об успешном платеже.
Таким образом, магазинам больше не нужно держать запущенный bitcoin клиент для обработки платежей, достаточно подключить Quick Bitcoin, что не будет отличаться по сложности от подключения любой другой платёжной системы, например webmoney или paypal (а по факту это будет даже проще). Также, это не только проще, но и безопасней в том случае, если ваш магазин размещается на публичном хостинге, так как при работе с платёжным шлюзом не нужно выкладывать на публичный сервер wallet.dat, который может быть от туда запросто украден.

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

Также, в ближайшее время будет доступно проведение платежей для магазинов, находящихся в I2P.

Quick Bitcoin в настоящий момент находится в стадии бета разработки, но уже полностью работособен. Хотелось бы услышать предложения и замечания по проекту.

Сайт проекта: http://qbitpay.com

Это очень хорошо!

Как определяется текущий курс - на момент формирования страницы в магазине, раз в сутки или еще как.
Откуда курс берется - по воле шлюза, по воле магазина, с биржи (с какой)

На каких технологиях может быть магазин? Если магазин на ASP .MONO - как туда интегрировать интерфейс со шлюзом ?

Курс формирует магазин. По сути мерчант (продавец) генерирует для каждого товара/услуги простую html форму, в полях которой указано сколько биткоинов должен заплатить покупатель и внутренний номер счёта в магазине. Форма отправляется нам, на http://qbitpay.com/invoice/merchant, где покупателю будет предложено произвести перевод. Как только покупатель проводит оплату - мы отправляем магазину POST запрос, в котором будет указана оплаченная сумма, номер счёта и секретный ключ. Магазин сверяет номер счёта и полученную сумму и секретный ключ. Если всё правильно - отпускает товар клиенту или зачисляет деньги на его счёт. Мы, в свою очередь, зачисляем деньги на счёт продавца.
Магазин может быть вообще на любой технологии, главное, чтобы он мог сгенерировать HTML форму запроса платежа и принять POST запрос об успешной оплате. Все.
Чуть позже будут доступны примеры и готовые модули для WHMCS, Quick Cart, Magento и других магазинов (т.е тем, кто использует данные программы вообще ничего кодить не придётся, остальным - самый минмум, но будут примеры и пояснения. В данный момент на сайте доступена документация по API на английском языке)

Полный аналог оплаты на mybitcoin.com. Хотелось бы видеть русский язык, красивый дизайн, примеры использования на php. И покажите нам пример формы. А пока что предпочту mybitcoin.

Отзывы редко пишут, когда всё работает как и должно :) Пока только прикручиваю всё к своему сервису, при тестах проблем не было.

Кратко составляем специальную ссылку, с количеством для оплаты, страницей для перехода после успешной и отменённой оплаты и переходим на неё из нашего магазина.
А зачем секретный ключ и насколько он секретный?

Меня пока смущает отсутствие доступа по https. :-\

Пока что мы работаем в тестовом режиме и вы правильно делаете, что используете mybitcoin. Примеры, готовые модули, русский язык - будет.
Секретный ключ нужен для того, чтобы валидировать уведомление об успешном платеже. Что если клиент вам подделает уведомление? Разьве в mybitcoin такого нет?

SSL будет

Вот для этого нужен сертификат сервера в SSL. Его клиент не подделает. Поэтому в mybitcoin лишних глупостей нет.

Будет ли ваш сайт представлен в сети i2p ?

Ну что за феерический бред. Вы вообще понимаете, для чего нужен SSL на сайте? Чтобы КЛИЕНТ был уверен, что не подделан САЙТ и чтобы данные шифровались. Как ssl может остановить клиента от отправки POST запроса на ваш сайт - я не понимаю.

Будет

Да, я был неправ.
Но надежнее было бы все равно заставить магазин переспросить состояние запроса через GET.
а то еще бывают Man in the middle и тогда надо как-то этот POST подписывать, чтобы быть уверенным, что он не изменен в пути.

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

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

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

Как вы рассчитаете хэш, если не знаете секретного ключа и он нигде не передаётся?

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

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

пользуясь случаем, поздравляю себя с 500-м сообщением и пятой монетой

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

Логику никто придумывать вас не просил. Всё уже давно придумано.  Максимум, что нам нужно - тестеры и общие советы.

http://bitcointalk.org/index.php?topic=8315.msg122946#msg122946

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

Прилепите эту тему к верху. Я упариваюсь ее искать каждый раз.

Перенесено в Бизнес. А зачем прилеплять-то? :-\

Человек же упаривается искать. Пожалейте человека.
(Прошу прощения, не удержался).

Молодые проекты не прилепляются, пока не получат достаточно уважения в сообществе.

Добавляйте полезные темы в Избранное вашего любимого браузера. :)

вообще то секретный ключ на то и секретный, что его в открытом виде не передают никуда ))
Им подписывают передаваемые данные обычно. А на принимающей стороне проверяют подпись.
А в открытом виде ключ по сети передавать - это нонсенс )

У нас произошли значительные изменения. В основном это исправление огромного количества ошибок, но кроме этого:
1. Теперь сайт доступен только по SSL - https://qbitpay.com
2. Введена система отзывов и репутация для продавцов. Каждая транзакция и каждый положительный отзыв добавляет 0.05 поинтов к репутации. Негативный отзыв снижает репутацию на единицу.
3. Написан модуль для WHMCS для приёма платежей с помощью нашего шлюза. Модуль будет выложен на сайте в разделе Downloads в течение суток.