adunar

I was just shopping for a new unlocked candy bar feature phone that supports 3G at 1900 MHz. The best one I could find was the Nokia 301.2 for $130.

The Kyocera Rally is another 3G candy bar feature phone with more of a budget price ($20 from Amazon but locked to T-Mobile).

The card I used for Linode was used for fraudulent online purchases on May 13. However, I also used the credit card at many other places besides Linode, so I'm not certain that Linode was responsible.

Such umbrella organizations exist -- they're called fiscal sponsors (http://en.wikipedia.org/wiki/Fiscal_sponsorship)

I worked at a non-profit fiscally sponsored by the Trust for Conservation Innovation (http://trustforconservationinnovation.org/), which is focused on environmental projects and takes 8% of project revenue.

I definitely recommend non-profit startups consider starting with a fiscal sponsor instead of trying to register as an independent 501(c)(3). You can always spin off later if necessary.

Definitely not useless!

Using an Android app as an SMS gateway is convenient for personal texting, but it's even more valuable for organizations working in developing countries -- where SMS is even more important, but services like Twilio don't provide local phone numbers and getting a shortcode can cost thousands of dollars.

My start-up (http://telerivet.com) works with a bunch of organizations that pay us for a more advanced version of essentially the same basic concept. (For example, Kiva.org uses our system to communicate with their borrowers in Kenya via an Android SMS gateway.)

We can't really prove that the card isn't stolen. One of the frustrating things about the card-processing system is that there's no way for merchants to actually initiate a fraud check (where the bank calls the cardholder to verify a purchase), or even any way to warn the cardholder that their card may be stolen.

Our manual review process usually consists of looking at:

- When the customer first registers, we ask them an open-ended question, "How do you plan on using Telerivet?". Did they provide an answer that would indicate that they are a legitimate customer?

- Does the customer's verified email address look suspicious (e.g. a disposable email account, or something that seems randomly generated)? Actually now we automatically block accounts from known disposable email providers from registering for Telerivet in the first place, but that's a whole different story.

- Does the customer's name look suspicious (e.g. random letters/numbers)?

- Does the customer's use of our service so far look suspicious?

Potentially we may also follow up with the customer over email. People who seem suspicious typically don't respond.

Here are some of the things Telerivet looks at to detect suspicious payments:

- Credit cards that fail the address, zip, or CVC check. Stripe tells you whether these checks fail, but will still process the payment anyway.

- Unusually large payments. For some reason we often see suspicious credit card payments of exactly $100. Maybe they're just testing if a stolen credit card works?

- Payments for very new customers, or for customers that aren't actively using our service yet. Our service has a free plan for testing, so most real customers don't pay immediately.

- Same credit card used on multiple accounts. We store Stripe's card fingerprint for each account so we can easily search our database for duplicates.

- Multiple payments in a short amount of time.

When someone tries to submit a payment, we create a "customer" record on Stripe and test their credit card first without charging it. If the customer looks suspicious, our servers send us an email and save a record for the pending charge in our database. Then we can investigate further and either process the charge on Stripe or delete it. If the customer is legitimate after all, we'll mark their account as trusted so any future payments will be processed automatically.

We've been using Stripe to accept payments at http://telerivet.com for about 9 months now, and generally we have been very happy with their service.

One thing Stripe doesn't really mention up front is that it's actually your responsibility to make sure that your customers aren't using stolen credit cards. (I assume this is the same for other payment processors, not just Stripe.)

We received a few payments that seemed suspicious (probably stolen credit cards), which resulted in a couple of chargebacks ($15 fee each) that showed up 3 months later. Since refunding suspicious payments to avoid chargebacks still incurs Stripe's transaction fees, we ended up developing our own heuristics to require manual approval of suspicious payments before sending them to Stripe.

For those still using PHP 5.3, you can use https://github.com/youngj/httpserver (disclaimer: I wrote it) -- it's a standalone development HTTP server written in PHP that only depends on the php-cgi binary.

Even with PHP 5.4, I find it more useful for development than the built-in cli-server, since it gives me more flexibility to simulate the various directives in my nginx configuration files (e.g. gzip_static).

It looks like nyaruka's Android SMS relayer app isn't yet publicly available or open source, but in the meantime people can also check out EnvayaSMS (http://sms.envaya.org/). Notably, EnvayaSMS also relays incoming MMS and allows you to exceed Android's limit of 100 outgoing SMS messages per hour.