Quote from: nimnul on July 21, 2011, 07:24:12 PM

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.