Bitcoin Forum
April 19, 2024, 09:07:37 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Quick Bitcoin - шлюз для приёма платежей  (Read 9412 times)
ArtemZ (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
May 12, 2011, 05:43:28 AM
 #1

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

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

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

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

Сайт проекта: http://qbitpay.com
1713560857
Hero Member
*
Offline Offline

Posts: 1713560857

View Profile Personal Message (Offline)

Ignore
1713560857
Reply with quote  #2

1713560857
Report to moderator
Whoever mines the block which ends up containing your transaction will get its fee.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
ArsenShnurkov
Legendary
*
Offline Offline

Activity: 1386
Merit: 1000



View Profile
May 12, 2011, 05:59:38 AM
 #2

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

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

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

Activity: 26
Merit: 0


View Profile
May 12, 2011, 06:15:08 AM
 #3

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

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

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

Activity: 171
Merit: 100



View Profile WWW
May 12, 2011, 07:48:52 PM
 #4

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

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

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

Like what am I doing? 1FzSgYpLG4fpy2Q9fKXQsuLxHN81m4P3dR
LZ
Legendary
*
Offline Offline

Activity: 1722
Merit: 1072


P2P Cryptocurrency


View Profile
May 12, 2011, 11:10:45 PM
 #5

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

My OpenPGP fingerprint: 5099EB8C0F2E68C63B4ECBB9A9D0993E04143362
ArtemZ (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
May 13, 2011, 02:46:28 AM
 #6

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

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

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

SSL будет
ArsenShnurkov
Legendary
*
Offline Offline

Activity: 1386
Merit: 1000



View Profile
May 13, 2011, 03:06:07 AM
 #7

Что если клиент вам подделает уведомление?

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

Activity: 1386
Merit: 1000



View Profile
May 13, 2011, 03:07:24 AM
 #8

Будет ли ваш сайт представлен в сети i2p ?
ArtemZ (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
May 13, 2011, 04:53:49 AM
 #9

Что если клиент вам подделает уведомление?

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

Activity: 26
Merit: 0


View Profile
May 13, 2011, 04:54:26 AM
 #10

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

Activity: 1386
Merit: 1000



View Profile
May 13, 2011, 06:16:41 AM
 #11

Вы вообще понимаете, для чего нужен SSL на сайте?

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

Activity: 26
Merit: 0


View Profile
May 13, 2011, 08:10:20 AM
 #12

Вы вообще понимаете, для чего нужен SSL на сайте?

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

Activity: 1386
Merit: 1000



View Profile
May 13, 2011, 08:54:27 AM
 #13

Вы вообще понимаете, для чего нужен SSL на сайте?

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


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

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

Activity: 26
Merit: 0


View Profile
May 13, 2011, 09:12:51 AM
 #14

Вы вообще понимаете, для чего нужен SSL на сайте?

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


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

На самом деле, там где-то должна быть процедура подписывания, а магазин должен ЭЦП проверять открытым ключем платежного шлюза.
Как вы рассчитаете хэш, если не знаете секретного ключа и он нигде не передаётся?
ArsenShnurkov
Legendary
*
Offline Offline

Activity: 1386
Merit: 1000



View Profile
May 13, 2011, 09:17:55 AM
 #15

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

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

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

пользуясь случаем, поздравляю себя с 500-м сообщением и пятой монетой
ArtemZ (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
May 13, 2011, 09:57:30 AM
 #16

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

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

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

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

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

Activity: 1386
Merit: 1000



View Profile
May 17, 2011, 03:23:04 AM
 #17

общие советы.

http://bitcointalk.org/index.php?topic=8315.msg122946#msg122946
ArtemZ (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
May 18, 2011, 04:33:34 AM
 #18

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

Activity: 1386
Merit: 1000



View Profile
May 21, 2011, 08:17:02 AM
 #19

уже полностью работособен

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

Activity: 1722
Merit: 1072


P2P Cryptocurrency


View Profile
May 21, 2011, 03:51:25 PM
 #20

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

My OpenPGP fingerprint: 5099EB8C0F2E68C63B4ECBB9A9D0993E04143362
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!