Topic: BitShop - cryptocurrency shopping cart script [PHP/MYSQL] (v1.1.2) - page 11. (Read 74905 times)

Hey I am having people complaining. I got 7 orders on my site but they are not confirmed etc. Is something wrong with the script?

Also I have no idea how to set up my coinbase with it. It only gives me a Coinbase key and secret key but I see no call back key or security string. You should make a documentation to help people.

Also when are you coming out with the option for users to put their address for shipping?

Yep it was web host issue causing the error..

I think im almost set.. Im trying to hack around one last thing and hoping somebody can point me in right direction..

I have manual email orders and prefer that the progress bar be completely gone and tat i just manually confirm my orders.

I did some testing and fiund that there are sess- files that get created in the dbs tmp folder which appear to drive the database inputs to turn status to confirmed.  The value it seems to generate is something like:
1addressxyzxyzxyz-confirms;i:1|

Starts at i:0 and then turns to i:1 after blockchain confirms.  If i could somehow make that value a static value that jives with the rest of the process updating STATUS, that would seem like it would be a workaround?

Anybody have any ideas as to how i might just tell one of the payment/status php pages to consider any value as confirmed?  Or some way that i could force the # 1 into the sess- files to trick it into thinking its confirmed?

I understand the risks associated with the confirmation skipping but this would work so much better for my needs and volume. 

This stackoverflow page answers your question:
The easiest solution is to try removing line 46 from the auto_load.php file. If that doesn't work you'll need to contact your host.

Unless you've done it, that's something your host has done. Contact them.

Hi, i tried to look at item and checkout but dont really see any supplemental / ship upgrade options.. Can u point me more specifically?

Also, is anybody getting error that says:
Warning set time limit has been disabled for security reasons in ecclib/auto_load.php on line 46

Not sure what i may have done wrong..

I haven't updated my store for a version or two so I don't know if physical ordering is included yet. However, even if it's not... simple modifications made to some pages makes it easy to do. See my site spend-ur-bits.com and view the checkout page of any item.

I really dont see it being too far away from this ability for those who want a one page checkout style store without user accounts etc. 

We use it for semi physical products (ticket sales for concerts/parties).

If i had a supplemental option that added a bit to price for certain ticket upgrades or rush processing (shipping in effect), itd be absolutely perfect because people dont want user accounts.  They input their address into the notes box upon checkout.

If u want full on physical shop with user accounts, credit card payments, etc then i think woocommerce and stuff like that is better option.

But certain situations, bitshop would be my choice.  I like its simplicity and the fact that no signup is needed.  Theres two last things i wish it had:
1. Ability to use list of payment wallets instead of the automated method ( or electrum mpk method would be really great)
2. Supplemental option for item pricing (shiping, delivery, processing options for additional costs)
3. A few simple action buttons that checked blockchain confirmations against wallet balances and orders, etc.  (i think i can actually manage this myself - well see)

I think u answered my main wuestion.. If i could have custom list of addresses for payments, i think this script is perfect for my needs at that point!

@Skyenet
Yes, BitShop is ready for that! :-)

I wished there was a way people can buy physical products and enter their address etc.

If it had this I would use this and make a giant shop and invest around $4-5k USD to make it a unique shop that only accepts bitcoins.

Yeah only for manual e-mail items would be good. Thanks.

I'm only talking about removing the loading bar for manual email items. Since the buyer doesn't get the product until the admin manually confirms their payment there's no need to make the buyer wait. But all other product types still require a loading bar, it simply isn't safe to accept 0-conf payments because the keys/files are available to the buyer instantly after the payment is confirmed.

Yes please get rid of loading bar in next update. It should complete instantly after detecting payment like Bitpay.

That is a valid point, but it's kind of tricky to process the payment without actually confirming it until the admin manually confirms it. I'll have to think about it.

I was made aware of a couple more bugs in v1.0.5 so I decided to release v1.0.6 even though I released v1.0.5 not too long ago. Version 1.0.6 of BitShop also includes a new menu option in the admin area which adds the ability to view backups and log files.

Planned for next release:

- better accounting for partial payments
- ability to use custom list of addresses
- RPC daemon support in payment gateway (yah!)

thanks for considering some of the changes.

I think i can learn to get comfortable with the SCI as I've tested it a lot and have yet to lose a key (tho id still love to be totally in control of the private keys and have no question as to which public keys are going to be used in future).

Has anybody ever "lost" any transaction where they couldn't get back the private keys (outside of that copy-paste error with the CIPHER ERROR that is a simple fix)? 

If theres 2 more customizations I could really use help, id be willing to pay for the time:
1. Shopping Cart Interface - would rather get rid of that progress bar for manual email sales.  Its the most troublesome screen for me and i can't see my customers appreciating the wait period.  Instead, having the order mgmt page recognize the confirmations, the current wallet balance and order total would be the preferred place to confirm new orders from a payment perspective.
** i understand the shopping cart interfaces are somewhat interchangeable - anybody else implemented something cool here?
2. Payment Wallets - would rather have 100% control and give up some automation.  Feeding a list of 1000 wallets via import or text box that would just be used one by one would be perfectly adequate and last for months.
- Cooler mpk options would be nice.

To give people a sense, we're going to setup a very simple shop to sell tickets to parties/shows (not huge but maybe 50 tickets a week leading up to a last minute manual email of show entrance info to the confirmed orders).  Probably a lil different than the normal use and the electronic file sale vision but the woo commerce type sites are just way too much for what were trying to do.

Im willing to pay a bounty if somebody can help me out here with customizing these two things.

I was recently informed of a non-critical bug in v1.0.5 so I've uploaded fixed copy of v1.0.5. I would recommend applying the fix even if you aren't experiencing problems because it may lead to problems in the future. More information is available in the client file area.

I'm liking it, I need more time to dig into the code it's been a long time since I used PHP and MySQL but this is something I would really like to set up.

@bitfreak!
Awesome good work. So, I'm gonna update it soon and share impressions. Thank you!

Just released BitShop v1.0.5. It includes several small bug fixes and support for the standard German language. The payment gateway now supports the use of testnet and a lot of it has been recoded for a smoother experience and should also improve integration with the coinbase API.

I would appreciate it if someone using the coinbase API could apply this update because I haven't done much testing with the coinbase API myself. However this update should make it work a bit better.

@SteamGamesBTC.com: this new version also contains the ability to change the product method between manual email and code list, included just for you so you will update from 0.9.9.

@jerry508: I will include some of your suggestions in the next release. I thought about including them in this release but I realized it would require a new field in the database (to keep track of actual address balances and determine partial payments). So I decided it would better to include those large changes in the next release because this update is already quite extensive.