I have tried calling PayPal themselves, and the rep on the phone didn't even know Payflow Link could work this way, so I don't trust his advice. All my searching has encountered mixed answers.
I am building an ecommerce site using Payflow Link, where the CC processing is handled on Paypal hosted pages. However, I am consider implementing the advanced integration method, whereby customers input all the CC info on a form hosted by my server, but the form gets POST'ed over SSL directly to Paypal's servers. Using this method, I can maintain the branding of my site except for the required Paypal reciept page.
The CC information, using this method, should never touch my servers. Are they required to be PCI compliant? From a technical standpoint, I can't see why it should, but from a legal standpoint, I get lost in the jargon of the PCI-DSS documents. The site does roughly 1000 transactions a year.
I'm exploring the same issue. From talking to our PCI compliance vendor, it sounds like MikeH is incorrect. Because we're hosting the form on our web site, the server itself needs to be PCI compliant. That's because the form could be hacked if the server is not secure.
I see two options:
Keep the form on our site. Make the server secure (our web host does not currently pass the PCI scan, they are working on it). Fill in the much longer and detailed SAQ Validation Type 5 (Questionnaire D).
Use Payflow Link's credit card capture form. Won't need to worry about the server, can then use the much shorter SAQ Validation Type 1 (Questionnaire A). But, we lose branding and may lose sales because the Payflow Link pages look so different.
The SAQ D is ugly :-(
Using the model you are proposing, you do indeed have to be PCI-compliant, but at a much less restrictive level than you would if the data touched your server.
For details, goto https://www.pcisecuritystandards.org/saq/instructions_dss.shtml and click on the link for SAQ Validation Type 1 (Questionnaire A). This will tell you exactly what parts of the PCI DSS you must implement as a merchant with all cardholder functions outsourced.
Hope this helps!
If you accept credit card payments through your website you have to be PCI compliant. How far you need to go will vary depending on your implementation. If you're hosting the form that the users are using to make payments you need to use an SSL certificate so that page is encrypted (even if only to make sure the lock icon appears in the user's browser. Without it you won't be doing 1000 transactions per year anymore).
Related
I'm trying to implement Google pay on the web by this example: https://developers.google.com/pay/api/web/guides/paymentrequest/tutorial.
When I remove "PAN_ONLY" from the example code, the button becomes invisible on my PC and on smartphone.
Under what conditions with the authentication method "CRYPTOGRAM_3DS" payment will be available?
I'm using the latest version of Google Chrome.
Tokenized cards are only available from your Android device today, where there are the means to securely authenticate the transaction and store sensitive information related to your forms of payment.
There are initiatives in the industry aiming at adding means of security and second factors to the web. These are expected to help the utilization of tokenization on the Web too.
I am checking feasibility of our application with Sage Pay
Our application is a thick Desktop based software having no Web-Page or integration to website.
All of following 4 options on Sage Pay website
Form integration
Server integration
Serve Inframe integration
Direct integration
are seems to be working around web-pages
Here I am only looking if SagePay solution is feasible or not because we do not have any website to take payments.
We need to facilitate payments to be taken into our desktop software
thanks in advance
Avtar
Sage Pay Direct doesn't rely on pages; it can be used in a smart client application. You just need to make sure you set the transaction type as MOTO (Mail Order Telephone Order), I think M, so that the 3D secure dialogs aren't shown.
You're right in that all the other mechanisms will require a browser.
Remember, with Sage Pay Direct you fall directly in the net of PCI DSS compliance, so you'll probably want to make sure that you remain on the right side of that.
Suppose I have an online shopping system and many users are registered to it. I want a feature that when I add a new product or there's a promotion for a particular product, my Google plus page gets updated in the sense that the details of the product are published there automatically. It will only be used for back-office purpose.
The problem is that I cannot share on the Business Page, it gets posted on my user profile.
How can I achieve posting on google plus page via a web application?
Currently, you would need to use a third party social media management tool to achieve this in an automated manner. I've tried Hootsuite and it appears to work with a standard account.
If the number of products that you add is not high in volume, you could manually share by using the https://plus.google.com site and switching to use your page as the poster.
Set the page free as a standalone account
Apparently Pages may now (since when I don't know) have their umbilical cords severed, and set free to stand on their own two feet.
The process involves setting a password for the Page (via the Page's settings) that allows it to be signed into and out of rather than simply managed.
This should allow Shares to be made (and other G+ actions such as +1ing) from around the web as the Page instead of as the profile that created it.
See an article on plusyourbusiness.com from Oct 2014 for some details, and an article on blogger-hints-and-tips.blogspot.de from Mar 2014 (cited by the former) for some more.
P.S. The "apparently" and "should" are due to my not having walked through the process myself yet.
P.P.S. (done it now) Easy and works.
I've seen different documentation on various forums and site on different ways of using Paypal api, here is a pretty useful link: https://cms.paypal.com/us/cgi-bin?cmd=_render-content&content_ID=developer/e_howto_api_ECOnMobileDevices&bn_r=o/, My question is a little different i do not want to use any of the Paypal libraries offered to us in my app, this is the link to libraries:https://www.x.com/developers/paypal/documentation-tools/sdk , I also do not want to gather any personal information, I want Paypal to take care of everything. So in other words I want to be able to open up a UIWebview to the Paypal's mobile site if possible (or if not the regular site will work) have to user log in with his credential or he can use the express checkout option and get back the transaction ID, or receipt what ever is available. I'm a little new to iOS and any help is appreciated.
If you don't want to use any libraries or API's, Express Checkout won't work for you.
Which does make it somewhat easier, as you can just use PayPal Website Payments Standard in a UIWebView instead.
For example; just open https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=your#email.tld&amount=1.99¤cy_code=GBP
This will start a 1.99 GBP payment to email#here.tld via PayPal, and automatically use a mobile layout.
If you subsequently want to receive transaction information; set up PayPal IPN on your account and use that to receive transaction-related events. This can be handled outside your app, and thus take away precious processing power to the server.
For an overview on getting started with PayPal IPN, have a look at https://www.paypal.com/ipn/
I would strongly suggest against trying to do transactions through paypal. If you look at the App Store Review Guidelines it states that
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected
This question (or variations of this question) has been asked before, but as Apple's export compliance rules change relatively frequently, and no one seems to ever get a straight answer, I thought I would ask.
I write an iPhone application that uses version 0.2 of the Dropbox API.
I have emailed Apple concerning use of this specific API, and I will be sure to update this question as I learn more and hear back from Apple. In the meantime, if any developer is using the Dropbox API in their iPhone application, did you mark your application as using encryption?
Edit: Upon closer inspection, it looks like the file data is also transferred using SSL. Since their API is using the NSMutableURLRequest class over HTTPS though, I still can't determine whether or not this API "uses encryption." If in the App Store submission page I mark that it does include encryption, Apple then asks if I'm using greater than a 64-bit symmetric encryption key.
If your app uses SSL (HTTPS), then yes it does include encryption. The export compliance rules changed last year though, so you will need an Encryption Registration Number instead of a CCATS number. See this blog post for details.
As it happens I'm working on this right now on a related project.
The Apple position is clarified in the FAQ in iTunesConnect; (my bold)
If your App contains, uses or
accesses standard cryptography for purposes other than those listed in
questions 2-4, you need to submit for
an ERN authorization. Examples of
standard encryption are: AES, SSL,
https.
This authorization requires that you
submit an annual report to two U.S.
Government agencies with information
about your App every January.
It's a pain in the neck, but that is the law if you want to be fully compliant. I'd love to hear that I'm wrong though!
PS. You could always ask for a direct opinion from the Government department concerned here;
http://www.bis.doc.gov/forms/rpdform.html
You can also call the Bureau of Industry and Security help desk at 202-482-0707 or read the web site at http://www.bis.doc.gov/encryption for more information.
Discussing your question with a live person is probably going to be better than filling out the online form and waiting for a response.