VISA Api: The Power of Visa Network Delivered as an API
developer.visa.com
developer.visa.com
Checkout:
> "Depending on your configuration, you will process the actual payment through your own system, a payment processor, or an e-commerce partner as you normally do."
( https://developer.visa.com/products/visa_checkout/guides )
CyberSource:
> Before moving to production and running real transactions, you must have a merchant account from an acquiring (merchant) bank that can process the credit card payments.
( https://developer.visa.com/products/cybersource/thingstoknow )
Visa Direct APIs:
> However, in order to use the Visa Direct APIs in production, the Originator must either be a Visa client financial institution (issuer or acquirer), a third-party Originator that has been granted a Visa acquirer POS license (geographical restrictions apply), or a third-party Originator that has established an acquiring relationship for that purpose with a Visa client financial institution.
( https://developer.visa.com/products/visa_direct/thingstoknow )
The token and transaction services are very interesting and it's cool to see Visa jumping into decent modern payment UX, but I don't think they're gunning for Stripe just yet...
You will still need a merchant account and a processor. A processor is the party that actually handles authorization/settlements between the issuing bank and acquiring banks.
Their intention is to likely attract really large merchants/platforms, one way or another.
I guess it will depend on this "on-boarding process" and their ability to make it as seamless as possible.
https://developer.visa.com/products/cybersource/reference#cy...
Ugh. Using this means that your application is in scope for PCI controls, since card data will be transmitted across your network into your application.
One of the reasons that Braintree and Stripe, for example, are so popular is because of the tokenization that they do prior to sending the card data to your systems, thereby putting your application out of scope for PCI.
If Visa added that one detail, this would be a fantastic solution.
If your server gets hacked you don't have any customer info stored on it. All you have is a stripe token.
ONE: You don't use stripe and save all you customer info locally and procces it some other way
TWO: You use stripe and never store any CC info on your server.
THEN: Your server is hacked. In ONE, you lose customer CC info because it is stored on your server. In TWO, you do NOT. Sure they can redirect you to a fake payment page, but that will get noticed quickly and damage will be limited to "phished" users not your entire user base.
While not over the network, the user enters his credit card into the form ON YOUR WEBSITE that POSTs it on to stripe. This means your site has full access to the credit card info, choosing whether or not to store is up to you (or in case you get hacked, up to the hacker).
The attacker can replace the iframe with his own and proxy it, or perhaps simply display an error and ask the user to re-insert his payment info into the actual stripe form.
Flow 1: User visits shop.com, selects some items, hits checkout, enters his credit card details into a form on shop.com, hits submit, gets emailed a receipt.
Flow 2: User visits shop.com, selects some items, hits checkout, is redirected to a form on processor.com, enters his card details, hits submit, gets email a receipt.
Now flow 1 and flow 2 could be the same internally if the form in flow 1 was actually from processor.com, just embedded into an iframe displayed on shop.com. But the key is that the user has no idea if it is or not.
The form in frame 1 could be in an iframe from anywhere, or it might actually be embedded directly into the page and posting, again, to anywhere. You just have to take it on faith that shop.com hasn't been compromised, and isn't now sending your details to malware.com.
In flow 2, you only enter your details into a form on processor.com; you no longer need to worry if shop.com has been compromised, you just need to verify that you're actually at processor.com, and not proccesor.com or whatever.
I'm not a big believer in the usefulness of schemes like PCI DSS anyway, but to the extent that they might be useful, it's as a checklist of good practices to follow when things are working properly. In that case, clearly there is a significant distinction between sending sensitive data over your own network to be stored on your own servers and sending sensitive data only to a trusted service provider that is better equipped to deal with it securely.
Maybe I am understanding this incorrectly, but isn't that one detail the main value proposition. It almost sounds analogous to a Dropbox competitor offering a cloud storage API but the developer is responsible for handling syncing.
I am not saying it is totally worthless, maybe it has some value to big companies, but I am really failing to understand how this could be broadly useful.
For one, it is a huge step forward from existing payment processor communication. Most card acquirer software is vintage 1997, either by sending large amounts of unstructured text over the wire, or parsing through XML, or dealing with error codes that mean nothing from acquirer to acquirer. Switching banks, for example, is such a massive pain in the ass because you essentially have to rewrite your entire card processing code from scratch. Having this easy-to-use API will encourage competitors to play catch up, and it is a pretty good selling point for using Cybersource.
Second, and you can make an argument about monopolies or whatever, but PCI is essentially controlled by Visa and Mastercard. It is entirely possible for Visa to strongarm mom-and-pop-acquirer to play by this API, and then (hopefully) add the public tokenization later. For e-commerce, storing and transmitting only tokens is huge, and goes a long long way towards mitigating the severity of these massive retail breaches.
I am aware that credit card processing is quite poorly implemented, so it seems like they are:
* making it less bad
* further exercising their monopoly
* adding more security at the transmission level
so, like who would use this? Basically this is for something like square where you would actual take physical cards and process them? It seems like if a user has a debit card you can process a fee for like 5 basis points. So, Visa is offering a way for merchants and payment processors to improve the security of their (credit card companies) own product so feasibly, they could lower their fees in the future, because they wouldn't have to pass along the massive amount of costs fraud creates due to the systems insecurity.
So, like, who uses this? Just payment processors and companies big enough to have their own point of sale? It seems like a big bet to expend engineering resources on.
What is the upside? Security is priced in to the processing fee, right? So, basically there is no gain for someone who already has a working gateway unless they force them to use this. If you do that engineering spend and get it to work, it is a big bet that users will continue to use a fairly unsecured payment method and carry it around with them, and that mobile payments won't become normalized in the next few years.
Agree that it's an important detail to add, but it's certainly not trivial. My understanding is that tokenization support varies from bank to bank.
For a company like Visa, this should be a trivial feature.
Wonder if VISAs exposes the BIN #.
BrainTree exposes the BIN number. Built this at a hackathon last year.
http://www.reversecreditscore.com.
You can reverse engineer the BIN Number offered by BrainTree's API to calculate the species of a credit card, thus the minimum credit score.
I have a payments entrepreneur group on facebook. It has about 50 folks in it. if you want in and have built payments stuff message me.
> BrainTree's API to calculate the species of a credit
> card, thus the minimum credit score.
I have multiple credit cards. I only use one of them for online purchases. It happens to be my oldest card, the one I got when I was 18 years old. Therefore it qualifies as an "introductory" card available with little/no credit history. Would you assume anyone paying with their oldest card has a low credit score?
There are so many factors that go into a credit score that it seems asinine to base an estimate of it on the specific card used for a particular purchase.
Sure you can get the "tier" of a card and know that the issuer only grants that card to someone meeting a minimum credit score. But you know nothing else. Some people have a 750 credit score but have never applied for a second card. You don't know how the age of the credit line, its utilization, its size, its payment history...
This "reverse credit score" estimate seems like complete snake oil. If credit checks are actually an important part of your business, factor them into your costs and just pay the $50.
With the introductory card you can't eliminate a high score, and with a premium card you can't eliminate a low score, but you can assume that at some point in time they had a high score with a premium card.
An Amex may also indicate that at one point I had good credit. I could have a 600 now.
It's a creative product but I second the notion that it hardly seems credible. It might be able to drive incremental ROI but I'd have to see it to believe it.
It is a minor leak of information, which theoretically means it has value. The challenge is extracting that value.
She's only 21, has almost no credit history, and very low annual income. She does have an auto loan from her credit union for a couple thousand dollars and just very recently got her own first credit card -- a store card (Victoria's Secret) with a $500 credit limit.
In an effort to try to help "jumpstart" her credit score a little bit, though, I added her as an authorized user on one of my American Express credit cards (five-figure limit, very low utilization, and paid in full every month).
This product would very likely peg her credit score as much, much higher than what it really is (suffice it to say, she's on the lower end of the range).
For example if there's 8M cards, we're able to get sample size data like this:
Card Species 1
400-500 - 25%
500-600 - 50%
600-700 - 12%
700-800 - 13%
Credit Karma has some of this data.
Myriad higher tier cards offer many rewards that you're actually paying for anyway on marked up costs of items merchants have to charge to pay card processing fees. So I would say, yes, you deserve a low credit rating.
"Visa" is a name, so it should have title caps (I know their branding calls for "VISA" but such is often ignored in non-corporate reporting), and "API" is an abbreviation so it should be all-caps.
I know, I should go back to work.
Some of their example code: https://github.com/VisaDeveloperProgram/SampleCode/blob/mast...
Docs are incoherent in just so many ways - and their quick start drops you right into like a 9 page guide for generating two-way ssl docs. Not exactly a quick dev onboarding path.
Request docs list attributes as required that aren't in their examples or runnable sidebar thing (the only cool part). Returns an error body with no error messages, codes, or info. You use some "correlation-id" (called "correlationId" in other places) to apparently get your error messages for a failed request.
Final rating: 1/7, would not play with again.
Don't think you're gonna be able to write a script to move money from your credit card to your friend. This is still a tightly controlled network of banks. If you're looking to innovate in the payments space, take a look at Bitcoin and other digital currencies.
This API is designed for business payments. Companies that process tens, if not hundreds of thousands of payments on a monthly basis. Think about the companies that sit behind businesses like Etsy or Uber - they need to take a lot of payments from customers and pay the supplier.
Many of those payment companies are financial institutions themselves who probably already have some kind of connection to programs like Visa.
It's not useless if you have a merchant account.
Please stop spreading this idiotic nonsense. Bitcoin, for all its faults, can handle refunds just fine. It just requires a different model than CCs do. You might as well say "cash can't handle refunds"...
Taking a look at the first service I found [1], the fees, the friction and the short period you can claim a refund within, make it seem like quite an inferior experience to using a credit card.
It's free because it's built around agreements with a central authority that can delegate the power to police and reverse transactions. The whole point of Bitcoin is there's no central authority. So you have to layer on top of that much more expensive protection services, as you would with cash transactions.
Additionally the oft-repeated claim that credit card fees lead to higher prices has two problems:
1. When Australia regulated away CC fees, prices did not decline.
2. In the U.S., which has higher interchange rates, most of that is refunded back to the consumer via reward programs (1-2% cashback).
Again, multisig escrow isn't new or innovative, and payments have evolved since then. Houses and shipping containers are as good at refunds as Bitcoin because they also use escrow - except their physical nature makes it harder to do infernational scams than with Bitcoin.
Credit cards, much like HTML, were a good idea built on a preceding ideas looking at the problem they were solving. So while credit cards have evolved, the now appear most similar to the Diner's club implementation popularized in the mid 50s[0]
KAZ NEJATIAN did an interesting interview in a YC podcast about his company Kash. He talks about how credit cards work on an antiquated system that, in 90% of transactions (his words) don't use anymore than the expiration date and numbers to process and compares defending processing to building a really strong door without walls.
He is neccessarily biased of course, but his explanation of the routing and auth system credit card companies used seems insane, and they aren't even value stores like banks.
Point is, things evolve in different ways and in fact, bitcoins lack of refunds (which may or may not even be true), could in fact be a massive innovation. Especially if it could deal with fraud which one could make a case for being the only valid reason for a refund. Not meeting a future obligation, could in fact be settled in the future by escrow or an insurance product one could create. E.g. I buy a laptop with a 5 year warranty and it breaks in year 4. In this contrived example, an issuer could run a system scan and verify this independently and objectively and release a predetermined payment amount, or go to a 3rd party arbitrator who would verify and release the funds.
[0]http://www.creditcards.com/credit-card-news/credit-cards-his...
Still going well. I really think they want it to be as open as possible.
Cost: Stripe's 2.9% + 30 cents per transaction, if you do enough transactions per month, is very high. How much better you can do depends on some variables like average transaction size, debit/credit mix, etc. You can easily shave it down to around 1.9% in most cases, or better. Again, at a certain scale, giving up 1% or more of your incoming revenue just isn't smart.
Control: Lots of areas here. Removing "STRIPE" from the charge listing on the customer's credit card statement. Direct control of chargebacks. Routing to different payment gateways based on card type. Better integration of card-present and online transactions.
You do, of course, lose the advantages that Stripe provides, so your scale would have to be such that replicating that functionality is justified. There are solutions in the middle. Authorize.net, for example, will let you use your own merchant account and pay just for the gateway services. They provide some of benefits/features that you would lose doing it from scratch.
Why would anyone invest any nontrivial amount of resources on developing something for which they don't know what the cost of running it is going to be?
What is lacking is a clear business overview of what their product is, its costs and benefits.
Speaking of which, VISA should just buy Stripe.
Because the executive committee has no understanding of why they need a "good" API, and no appetite for the difficult journey they need to embark on to create one, but they just have to do "something", and they're happy with "anything". That's my bet.
The largest player in the market just entered the API arms race, years late and with pockets deeper than any of their rivals. Yet two brothers from Ireland are still the best game in town.
They've had hackathons, and they have a few sample ideas. My favorite is checking local restaurants and the zip codes of users. This gives you a listing of places that are popular with locals.
"Once you’re ready to move forward and submit your app for approval, contact developer@visa.com and work with our team to complete risk reviews, contracts, system configurations, pricing, and billing arrangements."
This is kind of Visa's whole business model - assessing and pricing credit risk. There isn't too much point in learning the rates they offer somebody else.
This is not targeted at your average merchant.
An beta version should be ready pretty soon.
Just as the VISA API, this requires you to be a "verified partner" or be sponsored when going to production.
"Visa Checkout currently supports Visa, MasterCard, American Express, and Discover"
So it seems like they're trying to position themselves as a sort of Square competitor?
[1] https://developer.visa.com/products/visa_checkout/thingstokn...
why would you ever capitalize those words that way goddammit there's no way this wasn't deliberate
In term of programing, I much prefer dealing with Braintree but Cybersource is not too bad (not the worse gateway I've dealt with, less issues tha Authorize.net)
sadly all the cool fraud api stuff can only be used by issuers (e.g., banks) in production :(
If they really felt threatened by Bitcoin, they would have changed any one of those things. Bitcoin doesn't even have an HTTP API, so adding one doesn't help you compete.