Slashdot Mirror

Actually, most pre-paid cards (Visa, AmEx, etc.) won't authorize things like gasoline purchases. There's a purchase code sent with every purchase explaining what kind of thing I'm buying, which means if I buy milk, toilet paper, and Loratadine at Rite-Aid and swipe my HSA card, the HSA card authorizes the Loratadine and rejects the remaining charge; then I swipe my credit union Visa for the balance.

You can't get a real credit card until you're 18. That card might actually buy gasoline--or booze. Hell, you could use the owner's birthdate (you have their identity) to determine if they're 21 and reject booze-coded purchases on that if you really wanted.

Authorize.net can even tell you the balance on the card, and BinDB can identify prepaid cards in general.

http://authorize.net/

You need to look at the PCI-DSS requirements because this is what dictates the security standards of your network if you are storing credit card information. Specifically PCI-DSS dictates (not your contract) that there needs to be multiple levels of firewalls. Ergo you will need a firewall in front of the web server. You will then need a separate firewall in front of the DB servers. And the preferred setup is a three or more tiered system. Web server with firewall connects to the Application (WCF / web service server) which also has a firewall, which connects to your database server which also has a firewall. Also note that I am referencing hardware firewalls such as a Cisco ASA or a Dell Sonicwall. The servers should also have their own software firewalls enabled whether it's Windows Firewall or Linux IPTables. With that said we are "supposed" to be PCI-DSS compliant and should be for the sake of liability (and doing it the right way). Unfortunately I know many vendors who don't want to spend money on proper setups and run very insecure systems. If you can avoid it don't work for these people and go find a client that has the budget to do things right. PCI-DSS: https://www.pcisecuritystandar... A better option for a cheap client is to not store any customer data and use a tokenized system. Authorize.Net will store all sensitive data for an extra $10/mo and allow you to skirt PCI-DSS regulations. You should still run a firewall though and be as close to PCI-DSS as possible though. http://www.authorize.net/solut...

I disagree https://support.authorize.net/... "When a brick and mortar merchant accepts a credit card, and the charge is authorized, and assuming the merchant conforms to regulation, the merchant will get paid, even if a stolen card is used." http://creditcardforum.com/blo... "Even if the millions of consumers burned in the most recent rash of breaches start clamoring for EMV cards, those cards will offer no extra defense unless retailers update their equipment. That will cost merchants money, but the card networks (Visa, MasterCard, AmEx and Discover) are giving both them and card-issuing banks an incentive to upgrade by October 2015. At that point, the networks will institute a “fraud liability shift.” That’s a fancy way of saying “adapt or pay.” If a consumer’s card is involved in fraud, whichever party involved in the transaction (the bank that issued the card or the merchant that accepted it) that didn’t upgrade to EMV will be held accountable." Linked from the previous link a white paper titled Card Payments Roadmap in the United States: How Will EMV Impact the Future Payments Infrastructure? http://www.smartcardalliance.o... "The contact interface requires the issuance of contact chip cards and the installation of contact chip readers at merchants and ATMs and is required if merchants wish to protect themselves from counterfeit magnetic stripe liability shift. " If merchants get protection from a liability shift if they convert to Chip and PIN then they must not currently have liability. Otherwise there is no shift.

http://www.authorize.net/solutions/merchantsolutions/pricing/ What ? you can't move $30 of product a month? Are you a business or a charity? http://www.merchantexpress.com/

Being a "former" employee of a credit card machine/POS company.. you might not have much luck creating this piece of software.

Mainly in part to a majority of POS software having a protocol that you pretty much have to pay for to use as code in your software. It's a standard created by MCard/Visa.. a basic way to how the transaction as carried out as a user going to a website on the net.

When you register a POS software, it needs to have hard-coded a TID/MID.. which is how the processor uses to identify a) the merchant of the account, and b) the actual device being used to do your transactions.

There might be another way around this. I am not too sure. Your best bet would be to contact a major processor/platform (Omaha, Nashville, Nova, etc..) This website ( http://www.authorize.net/solutions/resellersolutio ns/resellerprogram/processorlist/ ) should help for more info on that..
Otherwise than that (bullshit licensing, standards) you should be fine..

Good luck

All my clients use them, and I have heard them described several times in articles as the standard in e-commerce payment processing in the US.

Authorize.net

• Authorize.Net
  
• Verisign
  
• Intellipay
  
• WorldPay
  
• iTransact
  
• QuickCommerce
  
• or someone else?
  

I have done quite a bit of development work for a company using Authorize.Net. I'm not exactly sure of thier pricing scheme, but the company I've done the development work for is quite small, I would supect they have some sort of plan for smaller companies.