Bitcoin Forum
May 21, 2024, 12:07:33 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Advice for Bitcoin payment integration  (Read 794 times)
azcoppen (OP)
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
March 10, 2014, 11:05:52 PM
 #1

Greetings - have looked through the boards to find the best place to post, and this seems like it, but apologies if it's off-topic. Currently doing technical research into Bitcoin best practice, and how to most effectively and securely implement payment integration.

We have 5 clients who run shopping cart systems, across multiple countries and currencies: they are interested in supporting Bitcoin payments. However, they are not too keen on managing their own wallets, and would like us to do that for them (for the time being with all payments traded out daily in USD). Some of them use APIs, others use callbacks from their payment processor's page. Some run Magento, others Kentico etc.

Client 1: 1500 products.
Client 2: 70 products
Client 3: 4575 products, and so on.

2 others are also very interested in taking in-game and in-app micro-payments equivalent to $0.50 and $1.00 a time. These need to be near-instant.

We're obviously concerned about the security management, so will almost certainly be outsourcing the actual transaction handling to a more-equipped provider, e.g. Coinbase. Our PHP5/Cloud-based set up is derived from LAMP: Varnish, Nginx, PHP-FPM, RabbitMQ, NoSQL (Mongo), and runs through different CDNs.

Important notes: we...

 - want the "hybrid" approach, where we do as much as we can in the client browser (with JS), reducing customer security exposure. In fact, we'd like people to pay directly from the wallets on their phone or computer, rather than us doing anything at all.
 - want to store as little as possible on the server, or in the DB (obviously encrypted).
 - do not want to generate or manage wallets for end user customers, if at all possible.
 - want to build our own automated management system for multiple clients, not roll out custom site by site installs.
 - prefer asynchronous infrastructure/order processing, where possible.

Because we have to manage multiple customers' processing needs, our current thinking is that the best approach a 3-stage lifecycle:

1) Customer views product, and hits "pay with Bitcoin" (and such) - containing form POST fields (product/order ref # etc);
2) Customer sees our intermediary payment processor screen, with QR code and wallet details for the vendor with payment request (that we manage via 3rd party);
 -- customer pays to BTC address with external phone/computer program wallet, details sent to 3rd party, e.g Coinbase.---
3) (Callback/refresh) Payment is received, customer sees "thanks" page, client inventory/ordering is completed in the background.
--- potential server-side callback to vendor, and/or hard redirect to their "payment received" page. ---

So the question is: what is the best way to accomplish the steps after 2)?

Specifically:

 - How do we associate the vendor's product # (also, order ref) they've selected with the anon-sender Bitcoin wallet address they are using, in order to confirm that the person has paid for that item? Is there any way to include a ref # with their transaction in the QR code that we can get in the callback?

 - Is it practical/efficient to create a wallet for each product in the inventory, create a wallet each time for each individual transaction, or just have 1 single vendor wallet in which they receive payments?

 - Assuming they scan the QR on the screen into their smartphone, and pay externally from their Android wallet (for example), how do we check in the background to see if it's been received - and how do we do that to make it as "instant" as possible in their individual client browser, without saying "please refresh this page" for up to 10mins while validation occurs?

- What's the best way to instruct them to "refresh" their screen once we've received background confirmation? We need to be able to say that payment has failed or is missing, rather than generating a transaction each time someone attempts payment, i.e. we can't get them to click a button and then each time get to a "thanks, we'll email you when your order is complete" screen. We need to be in control of when the process is genuinely underway or times out. We are looking at auto-refresh (sessions), WebSockets, and AJAX polling.

Thanks hugely in advance for any assistance. Love the coin, and we're investing a lot of time and energy into supporting its roll-out wherever we can. Just trying to get everyone's head around it.
domains4
Member
**
Offline Offline

Activity: 186
Merit: 10


View Profile
March 12, 2014, 12:19:02 AM
 #2

if your business not setteld in Seychelles, hire a army of lawyers and accountants to escape from tax office.
Pages: [1]
  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!