Each time for over about a year now that I've paid my mobile phone service I've grumbled about knowing that my phone bill was higher than it needed to be because my mobile provider (T-mobile) was giving part of my payment (perhaps 2% or so) to the credit card issuer. Every time I vowed that if such a service wasn't coming soon I'ld be tempted to see one launched myself (even inquired with GPA as to what would be involved http://www.gpa.net/products/virtual_terminal.cfm
Well, fortunately BTCBuy.info just came out providing exactly what I need.
My first purchase went fairly smoothly!
1.) The menu option on the site says "calling cards". I consider these to be mobile wireless prepaid cards, so calling cards doesn't seem to be the right category. I'm not looking for minutes for long distance phone calls.
2.) When I was to choose which card, I wasn't sure if I needed "refill" or "plan". I have a Pay as you Go (1500 minutes talk, text and web). Since that is a monthly price, I ended up choosing "plan" and it ended up working. Can anything there give help as to which T-mobile plans take which payment reload options?
3.) When I was asked for my e-mail address, I was wondering if that was required. If I wish for that to be private, I suppose I could use a throwaway e-mail address but was just curious if that was simply for customer service issues should something come up. (and, of course, the e-mail is necessary for getting the delivery of the e-card, I later learned.)
4.) After ordering, I was shown the bitcoin address that I was to send my payment to. After I sent it though, I didn't know what to do next? Should I refresh the page? Should I check my e-mail? What? And how many confirms will it take?
The answer was ... wait two confirmations and check my e-mail -- I will get a confirmation of payment received, and then I will get another message with the purchased e-card.
5.) Which brings me to the last, but nowhere near the least important piece of feedback,
The e-mail sent to me had the T-mobile card's 14-digit "PIN" code that I use to reload the funds to the balance for my mobile account. That code sent to me is a negotiable bearer instrument. Whomever has access to that code can use it (with any user that has t-mobile phone service, for this specific card item that I ordered). As we've learned with Mt. Gox redeemable codes, Instawallet URLs, and Coinapult claim tickets, ... protection of that code is of the utmost importance.
SMTP, which is the protocol that e-mail is transferred using, is not a secure form of communications. That t-mobile code in my e-mail was visible from the mail server wherever BTCBuy's mail service is hosted, and visible in all the dozen or so routes the message took between BTCBuy and my mail server. A network sysadmin willing to commit fraud or a contract tech support person from another country even could have at any point sniffed the network traffic specifically looking for the pattern: "from: *.BTCBuy.com". With those results the bad actor gets first dibs on all mobile phone prepaid card codes purchased from BTCBuy before the buyer ever sees them.
So, please reconsider the approach . BitInstant is planning on making a change after recently considering how Coinapult delivers bitcoins through e-mail as CoinaPult's approach is exposed to the same risk (code stolen by someone sniffing the raw SMTP traffic).
BitInstant's solution (that it is currently in the process of implementing) is to give the user a 4 to 6 digit PIN# at the time of purchase. This special code is then necessary before the purchased e-card's code is revealed. Here's BitInstant's description:
Ideally, there is a flow that doesn't go through e-mail. After sending the bitcoin payment I was hoping for a link that would be for a page that shows me the status of my transaction. When BTCBuy considers my payment as having been completed (2 confirmations) I should then be given the code right there in the browser. [Update: Though this should only be served via SSL if the page contains sensitive information.] Thus e-mail would only be necessary as a backup if I lost the URL.
Also, is 2 confirmations enough? These codes are almost close enough to being hard money, where if there were an opportunity for double spending on two confirmations, this would be among the first services to be hit. If the fulfillment is online, the purchase can be made anonymously, and the goods sold cannot be easily recovered if there is fraud detected then the transaction is not one that is suitable for 0/unconfirmed payments. With this category specifically, even waiting for two confirmations might be insufficient.
At the same time, 2 confirmations is too long. I wanted that code ASAP because I waited until my plan expired and am unable to make a call until I refill funds into my t-mobile account. Optionally accepting a green address for instant credit might be something you could consider? Or , ... perhaps you could accept also a redeemable BTC code from an exchange as that would be another way to give credit and complete the transaction instantly?
To conclude ... .AWESOME SERVICE! I am so happy to see this come along!