Virtual Credit Card Software

[nigeldude]

Re: Virtual Credit Card Software

Thanks Cheryl,
sounds like you did quite a bit of work there for me. I appreciate it all.

Many many Thanks again.

Nigel

[Steve Wood]

Re: Virtual Credit Card Software

You can find dozens or hundreds of companies that provide this service. Search on Virtual VISA or Virtual MasterCard. That's what they are, prepaid credit cards, without the plastic. They are accepted online because they are real [prepaid] credit cards, issued by and verified -- at transaction time -- by a credit card provider.

The approach you were looking at; "intercepting" the transaction is impossible, illegal if you could do it. If you have a hungry market there, I'd visit Visa or some official agency that issues these cards (not the hundreds of middle men outfits) and offer the service in your local area. You'd make commissions I am sure. But you can't do the intercept thing, no way.

[ken doucet]

Re: Virtual Credit Card Software

Just saw this and thought you might be interested.

Ken


http://gizmodo.com/336294/kenyans-ca...rds-wirelessly

Kenyans Can Now Max Out Their Credit Cards Wirelessly [Subprime Enabler]
By Charlie White on Subprime Enabler

Those poor Africans. When they want to use their credit cards to go on a spending spree at Bloomingdale's, they just can't do it because there aren't enough phone lines to handle all those credit card transactions. That's where this Siemens BiasharaPhone MTT 1581 might bring African countries, specifically Kenya, into the 21st century.

It not only lets the few dozen people in that country who have credit cards swipe them in this device, but it also prints out a receipt and sends the charge data via the cell network to the mothership. Kidding aside, this might actually make life safer in Africa, eliminating the need to transport cash, a dangerous proposition since not that much cash is around anyway.

But what about the dearth of credit card holders on that continent? Given the nature of the subprime credit card companies here in the States, we're thinking there might be a rush to blanket Africa with credit cards now. [Swift Global, via bb Gadgets]

[nigeldude]

Re: Virtual Credit Card Software

Hey guys, I just wanna update you all on this topic.

Following Steve's suggestion of going straight to the source, I contacted Visa through their website.
They took over a month to respond, but in the end, I received a phone call from Mr. Mario Vassallo of the Business Development Department for the Central America Region.
We spent a 1/2 hour on the phone during which he explained that they can provide cards only to banks or other forms of financial agencies that are governed by the Central Bank.

I explained to him my concept of the web software that we've been discussing here (specifically because everyone here kept saying its illegal) and he said that�s a good idea. And if what he's about to suggest doesn�t work out, then I could complete the software and proceed with it.

He explained that my local banks have the capabilities to provide me the backend service that I need to offer the prepaid cards. They call it Co-Branding. He gave me the name of the person to go speak with at my preferred bank. He even informed that person that I would be going there to see him. However, I ran into a brick wall at the bank. The gentleman there explained to me why it�s a service that they "the bank" have no intentions of offering despite the fact that it's something that has been requested by a number of their customers. And why they would do the Co-Branding only with institutions of extremely high financial status (That�s not me).

I walked away from that meeting with confirmation that I have a market if I can get this going and I have no competitions in the race of who will launch it first.

Now my options are:
1) One of the middle men outfits, as Steve call them.
2) My own created software which I prefer. Reason is these cards are already priced so high, like for example �True Cards� that Cheryl suggested. Their rates are so high I�m doubtful that I can add any significant markup. Plus with my own I can create my own rewards programs and promotional giveaways and so fort.

I�ll let you guys know what happens though.

[Steve Wood]

Re: Virtual Credit Card Software

The part I said was illegal is the "intercepting the payment" part. The financial institutions and the payment process are owned by the website owner, not the person using the website. If you "intercept" the payment that means when they click the Submit button they have to go through YOUR transaction, not the one intended by the website owner. That's called Phishing, even if the intentions are good and the payment is processed. Its illegal because, I, as the owner of the website, have the sole descression on how I process payments and what financial institution(s) I go through or allow. If you augment that I'm coming after you. And the fact is, you cannot do it technically. You can get away with traditional Phishing where you just capture MY credit card information for your own use, but you cannot "complete the transaction" per the rules of my website. That's because my web application is expecting something back from that transaction in order to update my database. You aren't going to have any idea what I expect back and so the user's record is not going to reflect that they properly purchased anything. So, even if you could do the initial part, you will take the users money and the website owner will not record the transaction as successful and the user won't get the product.

[TomtheTillMan]

Re: Virtual Credit Card Software

Hi Nigel,
I just ran across this thread because of the recent posts, and I must say I appreciate your ambition. This would be a great feat if you ever get it working. In fact I predict the entire operation would be bought outright and you would be rich beyond any imagination (even mine;)).

I'm a reseller of Credit Card Processing for several different 'middle men' as you call them. I also own a POS (Point of Sale) company selling systems and software all over the world. We have written several Credit Card Interfaces to the largest Processors in the US and while I need to be a bit vague because of the NDA's they've made me sign, I can give you this input...

The advice Steve Wood gave you is right on target. You will never (OK I hope you could never - because if you could, then the millions of 'others' trying to do it might also) intercept the payment string from any of the websites you mentioned on it's way to either the 'middle man' or from there on to the Processor Back End of which there are many. These are companies like FDR (First Data - still the biggest I believe), VITAL (Owned by VISA) and GlobalPayments (Started by Mastercard) and the one thing they all have in common is an obsession with security. Every day there are millions of attempts of phishing like Steve mentioned, as well as attempts to crack into the data streams from and to the 'middle men' like PC Charge, ICVerify or any of the many other Shopping Cart solutions you see online today.

As Steve said...

And the fact is, you cannot do it technically. You can get away with traditional Phishing where you just capture MY credit card information for your own use, but you cannot "complete the transaction" per the rules of my website. That's because my web application is expecting something back from that transaction in order to update my database.

.

Each website is expecting specific responses back from the 'middle man', and each of the 'middle men' are likewise expecting specific responses back from their host processor. The level of complexity for Credit Card Processing is just too great to expect this approach to work. This does not mean however, that the need can not be filled.

I imagine you could find someone who would take your money and promise to deliver this solution to you where they intercept the payment packet and redirect , (which is why I just wrote 5 paragraphs explaining why you should not try that approach), but you should reconsider selling your customers credit to Your Own Online Shopping Solution. In this case, your customer would be required to visit your site first (perhaps check their balance) and then make a request to shop at SONY.COM. Your host server could then initiate the online sales process and pass all dialogs back and forth between your customer and the online retailer. This could be done with your idea of the iFrames or some other method a good HTML / Java / Alpha programmer might suggest. I'm NOT that programmer, but some of these guys probably are :)

The difference would be that your online purchase would be legitimate because your server started the process. Your US Credit Card would be used to complete any sales (and you would then be the 'owner' as covered previously by Marcel. My guess is that this would be a monster project and not cheap, but it could have huge rewards. I think what most Americans have the biggest problem is that for the last 15-20 years or so, every Debit Card from our Banks and Credit Unions have also been Visa Check or MasterCard Debit Cards. So the idea of a market w/o these devices is foreign to us. I happen to know of many markets that have this same situation where the Banks have a greater monopoly over the monetary markets that they don't want to share with VISA/MC. Which is also why they don't want to Co-Brand a solution for you (They will be your competion - You will get people to make deposits into your company instead of their bank! - They will not like that one bit). If they can't stop you somehow, they will have no choice but to buy you out:)

Good Luck, I hope you find the right developer.

Best Regards,
Tom Wright

[nigeldude]

Re: Virtual Credit Card Software

Thanks Tom, between Steve's last post and yours I got a private message from another member, who indirectly made me realized (through the suggestions that he made as to how I could pull it off) that despite all the many times I've explained how i plan to do it, I still failed to effectivly explain it, which obviously wasn't the case on the phone with the Visa rep. Maybe its the way i write.

But his suggestion was exactly what I originally planned to do, and yours Tom isnt that much off. In fact its not off at all, it's just not detailed. maybe the word "interception" is what caused all the confusion. When I make a glance over the previous responses all the doubts seems to be stemming off that one word, because it gives the impression that I'll be tampering with peoples website from the backend, medling with their source codes and all that. But that's not the plan. Not at all.

In my last attempt to explain it, I'll put it like this:
I have a quadrillion sites that I visit daily that require logging in, some are forums that allow me to save my user name and password others I have to type and retype continuously. sometimes I'm just filling out forms with the same data repeatedly, like my contact info for example. after a while it gets tedious, I hate doing repititions in anything. My solution to all this is the "Google Toolbar." After i install it and set the data in it once, it continually checks all web pages i go to and highlight all fields that it can fill in for me by turning it yellow. Even credit card information feilds. All I have to do is click on the "AutoFill" button on the toolbar and all feilds are filled in for me, ofcourse to fill in the credit card feilds i still have to enter a password. But I much rather fill in a 6 character password than all the info required to fill in: Name On Card, Card Number, Address, CVV and so fort.

Now the google toolbar doesnt need to tamper with sony.com source code in order to fill in info on their page; Credit card info included. Its true that this info that it filled in is comming from directly off my computer, but would it have made a difference it it came from somwhere else?

In order to understand how this will work, dont think that there will be any tampering of anyones website, its just a matter of filling in the info into the appropriate feilds in a manner that dont expose certain feilds to the shopper.

If your still thinking its illegal, then that means that you haven't yet got it. and if you dont then I'll send you a an invitation to test run it when its opperational. and hopefully tom's predictions will come through:) and I'll be laughing all the way to the bank.

Hey Tom, I might have a few questions for you when i get over my work load and resume this project, I hope you wont mind. I appreciate your post.

[Steve Wood]

Re: Virtual Credit Card Software

So I finally understand, you will process the transaction as the merchant expects, using a legitimate credit card with an expiration date, and everything exactly as the merchant expects.

As long as it is a legitimate credit card that the merchant accepts, then what's so special about this? I keep thinking you are trying to fool someone about the transaction (buyer or merchant or cc company), but this may be incorrect. The merchant probably does not care if the credit card is really in the possession of the buyer, just that it is legitimate and the transaction will be completed.

I think somewhere here we discussed methods that legitimate credit card companies will issue virtual credit cards with no physical plastic. If you resell those to your users, then I assume they can use that number wherever a credit card is required. The fact that you want to auto-fill the numbers into the merchant form is irrelevant; its the same as the user manually typing in the values.

[nigeldude]

Re: Virtual Credit Card Software

Ok steve, you've made me feel good.

Now you've got a part of it. the part you're still missing is the fact that this system cannot allow the user to fill in the actual credt card info, I cannot expose my base card to the end users. All they can know is the info I give them that they will use to authenticate the transaction to my software, when my software is satisfied that this is a legit user making a ligit purchase and their credit is enough to fasilitate the purchase plus give me my fees; then it will fill in the required info from my credit card into the feilds of the merchant's page.

[Steve Wood]

Re: Virtual Credit Card Software

OK, then the rest of it is: you are purchasing the item FOR the user using your credit card. And then the user pays you, either immediately through your process, or later through a billing process. It's the same as having my neighbor come over and type her credit card info in to a waiting web form on my computer, with the shipping address as my house, but not letting me see the card number. Or reverse that, she can open the online store on her computer, use her credit card and still make my house the shipping address.

In either case, in addition to the cc# and exp date, she has to put in HER name and address AND take liability for the transaction. She has to, if they even offer this option, enter MY address as the Ship To. She won't have any place to put in MY name anywhere unless by some unlikely fluke, they offer a field for a Ship To Name.

If I have that part right, then you're still not going to be able to do it. All credit card fields on all shopping web forms are clear text, the user can see whatever is typed or auto-filled in that spot and the user has to physically click a Send button, sometimes twice to confirm. But you will say you are going to drop some value in that field other than the legitimate credit card number that then 'translates' to a real credit card on your system. Not going to work - only the value that is typed into that field, or auto-filled into that field, clearly visiable to the user, is going to be transmitted to the merchant gateway. If you think you can place 12345 in that cc field and then somehow supplant and transmit a real credit card number at the moment the transaction is made, that is impossible per what was said before.

[TomtheTillMan]

Re: Virtual Credit Card Software

Hi guys,
Steve is right again -that is if the customer is connected from his own browser directly to a page from an online merchant-which would then involve "Intercepting" the data mid-stream. Nigel you're right, most everyone thinks your idea involves this illegal/impossible step of "Intercepting the data". I don't think it does and we should do everything we can to put this to rest. The actual purchase must come from Nigels' own browser session from his project server or perhaps a dedicated client running from his project server. Nigels' customer will first need to access his server and log-in so that Nigels' program can verify funds have been deposited. Only then the customer can request to shop at SONY.COM. At this point Nigels' software makes a request to SONY.COM and when Sony's opening page comes back to his software, it (the software) must forward this back to the customer who had previously logged in. Each request must be passed back and forth until the payment is made. Then it gets a little more difficult. Things like this are done everyday. Look at GoToMyPC or PCAnywhere. Nigels customer would be remotely operating his (Nigels) browser right up until the payment process. This way Steve's concern about the Credit Card fields can be satisfied.

This is where I'll get specific for you Nigel, but remember I'm NOT this good a programmer so check this out with someone else first. In my mind you would give your customers unique 16 digit Account Numbers. For example 1122334455667788 could be one. Your software would need to scan every HTML page it receives from the customer side before it passed it along to the online retailer. Once it finds a match for 1122334455667788 then presumably you have the payment screen.

At this point you would need to block visibility of the account fields from the customer and replace your CC info into this form. This would be a great feat since every form could theoretically be different. There is more than one field you would need to replace. CC number, Exp date, 3 digit security number, billing address, zip code and card holder name are all currently used to verify CC purchases these days. At least most shopping cart programs have a ship to address so you could put your address as the card holders and the customers name & address as the ship to address, but will all retailers ship to Belize? Will the shipping cost be so high that makes the available credit of your customer insufficient for the transaction? -Since you might not know how much shipping will be until the end of transaction and after you've already verified your customers funds. I can also see hundreds of possible exceptions that could occur that a human might need to intercede for. Like I said earlier - a monster project (not cheap) with huge possible rewards.

On second thought, maybe I could pull this off. I only see about a dozen traps I could fall into along the way that would derail the whole thing. It's not the unknowns that I can see that would worry me though - it's the UNK UNK's (Unknown Unknown's) that will certainly pop up in a project like this.

I'll be happy to help in any way I can Nigel

[Jberry]

Re: Virtual Credit Card Software

Nigel, whatever was the outcome of this project?

-John