Hosted Bitcoin Payment Gateway - Web-Service API, Accept and Track Bitcoins

[BitcoinPorn]

we soft launched about 2 weeks ago. our goal is to help bitcoin be the currency it should be, rather than a commodity that it has been.

Found here http://www.reddit.com/r/Bitcoin/comments/iomlx/hosted_bitcoin_payment_gateway/

Never seen it mentioned on the official forums here and a search turned up nothing as well.

[1713550665]

1713550665

[1713550665]

1713550665

[1713550665]

1713550665

[1713550665]

1713550665

[Maxim Gladkov]

I'm currently using it on www.wesellrigs.com and I am amazed, how good it works. So thank you to developers!

[BitcoinPorn]

I'm currently using it on www.wesellrigs.com and I am amazed, how good it works. So thank you to developers!

"thank Maxim for his kind words(I wasnt able to reply on that section of bitcoin forum, so i put it here)"

Ah the Newbies restrictions, sometimes they do suck, lol

[brandon@sourcewerks]

I have added this API to my resume as well if anyone needs help implementing on their site.

Nice work guys!

[xDragonZ]

nice work.. gonna try it now.. 

[Maxim Gladkov]

I think, I will make a Ruby on Rails gem to work with such Gateways easy. I think, it could be a great improvement in current situation with setting bitcoin payments on your websites...

[nimnul]

I will make a node.js npm package for the API one day if the API proves useful.

So far I have a few bug reports/feature requests:

1) Stop violating HTTP/1.1. http://tools.ietf.org/html/rfc2616#section-14.1 says:

   If no Accept header field is present, then it is assumed that the
   client accepts all media types. If an Accept header field is present,
   and if the server cannot send a response which is acceptable
   according to the combined Accept field value, then the server SHOULD
   send a 406 (not acceptable) response.

Your server (not necessarily the code you wrote but maybe web server or Ruby stuff you are using) sends 406 if no accept: header is present. This is clearly a violation as it contradicts "If no Accept header field is present, then it is assumed that the client accepts all media types."

As a quick and dirty solution, you can say in your documentation that accept: */* header must be present because of a bug in such and such software you use.

2) Enhance your documentation. Your API expects HTTP requests with content-type 'application/x-www-form-urlencoded' and responds with application/json. But from your documentation it seems that API expects JSON passed in POST body, which is a different thing. I only could figure out by looking at your Ruby example.

3) Document your existing or planned private key recycling policy. You must either destroy, reuse or send your outdated private keys to API users. Otherwise you are going to end with verifying transactions for millions of keys.

Usecase:

0. US Govt makes bitcoin a legal tender.
1. Google Checkout and Paypal start to accept bitcoins using your API
2. Zillions of users request a bitcoin address to pay for a service but never pay and even don't record the generated addresses
3. Zillions of addresses (and corresponding private keys!) become stranded
4. Your service keeps storing zillions of key pairs generated 10 years ago and keeps looking for a transaction for any of them.

So I suggest:

a) to document default expiration time for addresses
b) to reuse expired addresses so your wallet.dat grows slower over time
c) to implement order cancellation API to allow manual expiration

[jostmey]

This is great! I've heard of several people looking for something like this that is clean and well documented.

You've definitely given me something to think about.

- J

[jirhak]

I think, I will make a Ruby on Rails gem to work with such Gateways easy. I think, it could be a great improvement in current situation with setting bitcoin payments on your websites...

That's great Maxim. This is one of the things people are asking for. Keep me updated!
 

[jirhak]

Thanks nimnul, good suggestions.

I will make a node.js npm package for the API one day if the API proves useful.

So far I have a few bug reports/feature requests:

1) Stop violating HTTP/1.1. http://tools.ietf.org/html/rfc2616#section-14.1 says:

   If no Accept header field is present, then it is assumed that the
   client accepts all media types. If an Accept header field is present,
   and if the server cannot send a response which is acceptable
   according to the combined Accept field value, then the server SHOULD
   send a 406 (not acceptable) response.

Your server (not necessarily the code you wrote but maybe web server or Ruby stuff you are using) sends 406 if no accept: header is present. This is clearly a violation as it contradicts "If no Accept header field is present, then it is assumed that the client accepts all media types."

As a quick and dirty solution, you can say in your documentation that accept: */* header must be present because of a bug in such and such software you use.

2) Enhance your documentation. Your API expects HTTP requests with content-type 'application/x-www-form-urlencoded' and responds with application/json. But from your documentation it seems that API expects JSON passed in POST body, which is a different thing. I only could figure out by looking at your Ruby example.

3) Document your existing or planned private key recycling policy. You must either destroy, reuse or send your outdated private keys to API users. Otherwise you are going to end with verifying transactions for millions of keys.

Usecase:

0. US Govt makes bitcoin a legal tender.
1. Google Checkout and Paypal start to accept bitcoins using your API
2. Zillions of users request a bitcoin address to pay for a service but never pay and even don't record the generated addresses
3. Zillions of addresses (and corresponding private keys!) become stranded
4. Your service keeps storing zillions of key pairs generated 10 years ago and keeps looking for a transaction for any of them.

So I suggest:

a) to document default expiration time for addresses
b) to reuse expired addresses so your wallet.dat grows slower over time
c) to implement order cancellation API to allow manual expiration

[nimnul]

It kind of works, but it needs to be more robust and documented.

1) implement API and transactions log - so I can see what API calls you sent and received. It will be helpful in debugging and disputes.
2) implement test API endpoint - it's not a problem to send real transactions during tests, but they take an hour to get confirmed so my development is slowed down
3) document when and how often you try to call back. What happens if my server does not respond or DNS resolution fails? Are HTTP redirects followed? Is HTTPS supported? etc
4) document foreign_order_id, custom_field and transaction_timestamp, order_status
5) What happens if I want to use one address per customer, as opposed to one address per order? It seems subsequent transactions to an address still fire the callback. Is total_amount in POST /order necessary at all? What happens if customer sends less or more than total_amount?
6) Think about better/more standard cryptography. A homemade HMAC and plaintext authtoken are not good ideas, they are just temporary quick-and-dirty solutions.

[jirhak]

It kind of works, but it needs to be more robust and documented.

1) implement API and transactions log - so I can see what API calls you sent and received. It will be helpful in debugging and disputes.
2) implement test API endpoint - it's not a problem to send real transactions during tests, but they take an hour to get confirmed so my development is slowed down
3) document when and how often you try to call back. What happens if my server does not respond or DNS resolution fails? Are HTTP redirects followed? Is HTTPS supported? etc
4) document foreign_order_id, custom_field and transaction_timestamp, order_status
5) What happens if I want to use one address per customer, as opposed to one address per order? It seems subsequent transactions to an address still fire the callback. Is total_amount in POST /order necessary at all? What happens if customer sends less or more than total_amount?
6) Think about better/more standard cryptography. A homemade HMAC and plaintext authtoken are not good ideas, they are just temporary quick-and-dirty solutions.

hi nimnul,

thanks for the feedback. they are great suggestions. Some i have andrews for, others I dont.
1. I agree. Transaction log or just a way showing users activities will be very useful in disputes. It is planned feature but not in high priority. For now, I manually query and verify any disputes.

2. http://www.bitcoinpayflow.com/test_pn sends a test ipn to your url, this allows user to implement their code without waiting for a payment notification

3. currently the system does not retry payment notification if it fails. I am working on that right now. We do have https.

4. I will update the doc. thanks.
 
5. can you give me a use case why you will want this?

6. I am open for any suggestions on this

again thanks for these feedback. Let me know if you have more.
 

[nimnul]

2. http://www.bitcoinpayflow.com/test_pn sends a test ipn to your url, this allows user to implement their code without waiting for a payment notification

Does it? It seems it doesn't send any notifications but just displays a notification body so I can debug my signature verification algorithm. Can you double check that it actually fires an HTTP request?

3. currently the system does not retry payment notification if it fails. I am working on that right now. We do have https.

How it is supposed to work? I get one callback per transaction with seemingly random confirmations count. Will it fire after every confirmation or just once after 6 confirmations?

5. can you give me a use case why you will want this?

Any case of repeated transactions. E.g. a casino - for a user its convenient to have an address in his bitcoin address book and use it every time when he buys more chips. E.g. a web hosting service - for a user it is much easier just to pay 1 BTC to a fixed address every 1st day of the month than to log in to his account and request a new address every time. In general, there are cases where only total transferred amount is important but there's no need to differentiate individual transactions. At least btcex.com and bitcoin-central.net use this model for adding bitcoins to trading accounts.

6. I am open for any suggestions on this

One possible solution is just use your certificate as a client HTTPS certificate to authenticate you. 

[jirhak]

. The test link should work now. Give it another try. It should ping you back in 10 seconds or less.

. We just pushed retry feature out. the system will retry up to 9 times over 3 days period if not http 200. However, number of confirmation will always be number of confirmation in initial payment notification.

. A workaround to the use case you are talking about will be to create an order with large amount. The system will send you payment notification every time a buyer pays to that address.

[Herbert]

I am trying to integrate this solution in a django app. Maybe I am missing something, but i don't understand the format of the payment notification.

When requesting a test notification i get the following (raw post data):

Code:

Payment%20Notification[category]=receive&Payment%20Notification[transaction_timestamp]=1307671121&Payment%20Notification[signature]=d9823704c0753f652fa4b09535826d2622da0ff19552ffde68879e9a2c40ce53&Payment%20Notification[amount]=2.21&Payment%20Notification[foreign_order_id]=51&Payment%20Notification[number_of_confirmations]=1&Payment%20Notification[order_status]=open&Payment%20Notification[transaction_fee]=0.0&Payment%20Notification[bitcoin_address]=1AFZ6Cv8q96rFaS9T8fR1y2j2CjNDcTIVD

This does not look like a valid json string. Also django seems not to be able to figure the structure out. It puts the post data into a query dict, but the keys are somehow mixed up:

Code:

QueryDict: {
    u'Payment Notification[foreign_order_id]': [u'51'], 
    u'Payment Notification[transaction_timestamp]': [u'1307671121'], 
    u'Payment Notification[number_of_confirmations]': [u'1'],
    u'Payment Notification[amount]': [u'2.21'],
    u'Payment Notification[category]': [u'receive'],
    u'Payment Notification[signature]': [u'd9823704c0753f652fa4b09535826d2622da0ff19552ffde68879e9a2c40ce53'],
    u'Payment Notification[bitcoin_address]': [u'1AFZ6Cv8q96rFaS9T8fR1y2j2CjNDcTIVD'],
    u'Payment Notification[order_status]': [u'open'], 
    u'Payment Notification[transaction_fee]': [u'0.0']
}

So i can access the actual data by using e.g.

Code:

response.POST[u'Payment Notification[foreign_order_id]']

to get the number of confirmations.

But i think you intended to provide this as proper json string, e.g.

Code:

{
  "Payment Notification" : 
  {
    "foreign_order_id" : "A1234", 
    "amount" : "2.20", 
    "transaction_fee" : 0.0,
    "bitcoin_address" : "1AFZ6Cv8q96rFaS9T8fR1y2j2CjNDcTIVD", 
    "number_of_confirmations" : 1, 
    "transaction_timestamp" : 1307671121, 
    "category" : "send", 
    "order_status" : "satisfied",  
    "signature" : "unique signature for this request"
   }
}

At least this is also what the documentation says.

Any idea?