Topic: Q: design (not implementation) of BTC shopping cart (Read 687 times)
"very quickly" is not quick enough. There still is a gap, so the customer can change the contents of a shopping cart and resubmit.
Why do you say there is such a long time gap? Obviously it might be a while before it gets in a block, but you'll see the pending unconfirmed transaction very quickly.
If you don't think seeing the pending transaction is reliable, you could have a button where the user could click 'payment sent' which would mark the cart as 'payment pending' anyway, to prevent double-pays. Obviously you would still wait for confirmations before sending the goods.
The way this "should" work in the future is that when the user goes to check out a cart, they get a payment protocol message with the payment details, which their wallet will hold for them until they decide to pay it. That cart is immediately marked as 'payment pending' and you wouldn't accept further payments for those items.
If you don't think seeing the pending transaction is reliable, you could have a button where the user could click 'payment sent' which would mark the cart as 'payment pending' anyway, to prevent double-pays. Obviously you would still wait for confirmations before sending the goods.
The way this "should" work in the future is that when the user goes to check out a cart, they get a payment protocol message with the payment details, which their wallet will hold for them until they decide to pay it. That cart is immediately marked as 'payment pending' and you wouldn't accept further payments for those items.
Hi,
at snowcron.com, I have, some time ago, implemented a simple BTC "Paypal but better" engine.
Now it is time to move from selling single items to shopping carts.
Which suddenly is a problem.
See, if the customer selects couple of items from your online store, and clicks "check out", he is presented with "please send XXX BTC to the following address". He sends, I detect it, and send him whatever it is I am selling.
So far - so good.
However, after he is presented with "please send" screen, he can go back to a shopping cart, and select extra items, or deselect, whatever. And click "check out" again.
And I do not know if he have paid the first time or not.
Now, I have to present him with "please send (different amount) to the same address".
Here is a problem: if he does the entire routine fast enough, I have no way of knowing, if he paid the first time. I know a reasonable person should not. But...
Imagine, he selects item A, clicks "check out", sends bitcoins, goes back, selects item B and deselects A, sends bitcoins... What a mess, especially considering that I don't have control over those bitcoins, so I cannot do a refund.
Question therefore is: how should bitcoin cart work? The difference between it and a credit card based cart is, that I cannot track the moment when the customer transfer money, there is a time gap, and it can be long.
One possible solution is, of course, to assign a new address every time he clicks "checkout", so he has 100 carts, and then 99 of them expire, as payment never arrives.
The problem with this approach is obvious, too. Say, the customer selects item A, clicks "check out", PAYS, goes back, selects item B, and, as a cart is a new one, he sees the item A is not selected anymore, so he selects it again...
Another approach is to keep a simgle cart per user (cookies), and to send items (we are talking about sending electronically, like emailing geg. codes or something) as money arrive.
But if the user selects A, pays, deselects A and selects B... We have a mess again.
Once again, the problem is, the confirmation is not instant, so the customer can do "things" while we wait for money...
Any suggestions on how it SHOULD work? The point is to have a solution, that does not involve exchanging e.mails and refunds.
at snowcron.com, I have, some time ago, implemented a simple BTC "Paypal but better" engine.
Now it is time to move from selling single items to shopping carts.
Which suddenly is a problem.
See, if the customer selects couple of items from your online store, and clicks "check out", he is presented with "please send XXX BTC to the following address". He sends, I detect it, and send him whatever it is I am selling.
So far - so good.
However, after he is presented with "please send" screen, he can go back to a shopping cart, and select extra items, or deselect, whatever. And click "check out" again.
And I do not know if he have paid the first time or not.
Now, I have to present him with "please send (different amount) to the same address".
Here is a problem: if he does the entire routine fast enough, I have no way of knowing, if he paid the first time. I know a reasonable person should not. But...
Imagine, he selects item A, clicks "check out", sends bitcoins, goes back, selects item B and deselects A, sends bitcoins... What a mess, especially considering that I don't have control over those bitcoins, so I cannot do a refund.
Question therefore is: how should bitcoin cart work? The difference between it and a credit card based cart is, that I cannot track the moment when the customer transfer money, there is a time gap, and it can be long.
One possible solution is, of course, to assign a new address every time he clicks "checkout", so he has 100 carts, and then 99 of them expire, as payment never arrives.
The problem with this approach is obvious, too. Say, the customer selects item A, clicks "check out", PAYS, goes back, selects item B, and, as a cart is a new one, he sees the item A is not selected anymore, so he selects it again...
Another approach is to keep a simgle cart per user (cookies), and to send items (we are talking about sending electronically, like emailing geg. codes or something) as money arrive.
But if the user selects A, pays, deselects A and selects B... We have a mess again.
Once again, the problem is, the confirmation is not instant, so the customer can do "things" while we wait for money...
Any suggestions on how it SHOULD work? The point is to have a solution, that does not involve exchanging e.mails and refunds.
Jump to: