I plan on using a service such as Authorize.net to process user's credit cards. Which brings two questions.
Will I need SSL on the payment page even though I will be letting the third part handle most of the processing?
Will I need to get the user's address? And if so, will an apartment number be required? (If they have an apartment, of course)
Yes. The processing will most likely be done through some API that you will call. So getting the information from your users from the browser to your server will require encryption (SSL)
That depends on your set up and what Authorize.net will require.
You DO need to use SSL for your portion of the transaction - you are not PCI-DSS compliant if you do not.
If you are asking about apartment number because you intend to pass it to A.net for AVS anti-fraud checking, AVS only checks the part of the address line before the first space eg: 123 Maple St - only the 123 is checked. The zip is the only other part of the address checked, so there is no reason to worry about apt number. Collect it for your own complete records of course, but it will not affect and AVS check which is the only reeason to give it to A.net in the auth transaction.
It depends on which API you use. If you use any of the hosted APIs (SIM, hosted CIM) you will not need an SSL certificate as you will never be handling any sensitive information on your website.
If you use AIM, ARB, CIM, or DPM you will need an SSL certificate as you will be collecting sensitive information which is covered by the PCI DSS standard.
Yes and no. You are not required to collect it as it is not needed to process a credit card. However, without it you cannot perform Address Verification (AVS) which is a good tool for helping to reduce fraud. It also means your transactions will be processed at a higher rate which is not a good thing.
Related
I am working on web application where I will have to receive credit card details but only so that I can pass those details to configured payment processor and receive the card id/token which will be stored.
Usually this is done in front-end via JS request directly to the payment processor that will return nonce and then the backend does its job. But this is not my case.
Even though I will not be storing the CC data I will be technically processing them(the CC data enters the server and my code) so I need PCI certification.
But I am not a large company that can afford that so I want to avoid it, at least for now.
So I am wondering if it would be ok from security and PCI DSS point of view to create a Google Cloud function that would receive the CC data, call the application for validation and payment processor configuration, send the CC data to selected payment processor, post the token back into the application to perform what needs to be performed, and return the result from the application back to the client.
Technically, the CC data only enters the Google Cloud function instance which is certified and the CC data is only safely submitted into the payment processor which is also PCI certified. And I think in this case the Self-Assessment Questionnaire D – Service Providers should be enough without the need for certification.
Is my assumption correct?
If you are a service provider, then you need SAQ D for service providers, no matter the setup you're using. Basically if the money that is collected from the credit card goes into someone elses merchant account, then you're a service provider.
SAQ D is the hardest of the SAQs, the difference with 'certification' (there is no certification as such), or RoC, is basically that a trusted body verifies that you've done the SAQ properly. You only need the RoC, which can be in the order of $25K a year, if you process over a certain number of transactions per year.
Yes you should be able to use GCP cloud functions, and that will help with your PCI compliance, but in reality it won't make that much difference regarding the overall effort required to become PCI compliant. You still need to have all the policies and procedures in place, code reviews, SDLC, penetration testing etc etc. It's 139 pages of requirements.
The good news is you don't technically need to be PCI compliant, it's up to the merchant to use PCI compliant providers, and they do that through a contract with you stating their PCI needs. Obviously not the best approach though.
Have a talk with a QSA, it's probably worth a few hundred dollars consulting fees to see if there's anyway around it. If you're doing this as a one off for a single client, it might not be considered service provider for example.
Good luck, and it'd be great to hear what you end up doing.
(Not sure if this is the right place to ask. Please point out other forums if that's not the case).
I'm based in Europe, and I've set up an invoicing system for a client of ours which uses a tokenization system provided by his bank, as part of the bank's secure payment services. (In other words, this is not any of the big american services like Paypal, Braintree, Stripe...).
The problem is that, in order to input a credit card into the system, this
bank needs to charge an initial amount of 0.01 € to it... and when it does that, the credit card owner gets a text message code to approve that charge, without which the card number cannot be introduced. This is not practical for my client, for a variety of reasons. We have asked the bank, and they say that this is all dependant on the card issuing bank, and they can't do anything about it.
My question is...: what do we do to avoid this? From what I remember, other tokenization system I've used also had an initial 0.01 cent charge, and yet I never received any text messages from them (this was a few years ago, admittedly, before 2FA became widespread). How do the big payment processors (Authorize.net, Stripe, etc.) manage to store credit cards without making an initial charge and triggering two-factor authentication in the process?
Thanks.
The reason behind performing an authorisation (not a charge) is to ensure the card is valid before it is stored.
However, the $0.01 authorisation is now considered 'the old way' of doing this. Most card acquirers now allow an authorisation value of $0.00 to be used solely to check the card is valid. This shouldn't trigger any 2FA where it is supported.
Obviously though, this is payment processor dependant on whether they support this 'new' functionality. A small number are still stuck in their ways
The other alternative is just to process the full transaction value. It shouldn't be necessary to submit the card for tokenisation before using it, though admittedly this depends on your business use case.
My Passbook-related app was recently rejected based on guideline 23.3:
23.3: Passes must be signed by the entity that will be distributing the pass under its own name, trademark, or brand or the app will be rejected and Passbook credentials may be revoked
I had a few questions and got on the phone with someone at Apple. They told me that to remedy my problem I could create a sign-up form in my application. This sign-up form could then be used to create a certificate and pass type ID for the user based on their credentials. However, I've been combing through the documentation and I've not found anything that allows people to create Pass Type IDs or Certificates without at paid developer membership. Is this correct, would my users need a paid developer membership to create their own Pass Type IDs?
If they don't, is it even possible to create a PassType ID at runtime? For example, using the information in the sign-up form I might make an API request with PassKit / some kind of Passbook server to create a Pass Type ID:
PassID *ID = [PassKit createIDWithName:#"USER_INFO"];
Is there anything like that or was the Apple technician talking about something else?
would my users need a paid developer membership to create their own
Pass Type IDs
As crazy as this sounds - yes! The only way of fully satisfying this guideline is to pay the Apple Tax and sign up as a Developer. There are several long threads in the Apple Developer Forums talking about the reasoning and implications of this. While it is not popular, the majority of us concede there are very good reasons for this, that in the long term, will protect the integrity of the platform (as well as keep the Apple lawyers happy in the short term).
The main reasoning is because in most jurisdictions; coupons, tickets, travel documents and other typical Passbook content create a binding obligation upon the issuer. Legally, in the event of non-fulfilment, the pass issuer is liable to the consumer. In order to protect themselves, Apple needs to ensure that under no circumstances, could they be deemed as the issuer of any Passbook pass.
The Apple Developer programme registration validates the identity of any individual or corporation who is accepted. It also forces Developers to sign the terms of the Developer Agreement which has an entire attachment dedicated to what you can and cannot do with Passbook and with your PassID certificate. This provides Apple with enough legal protection against any claims for unfulfilled goods or services relating to any Passbook pass.
While there has been a lot of pushback and calls for a faster, less US centric process (you would not believe how difficult it is to get a DUNS number for an small entity outside of the US), I don't expect this to change any time soon.
As for auto provisioning. Myself and the creators of the other major Passbook platforms have been calling for this since before iOS6 was launched. I have an open radar dated 7th August requesting a simple API to issue and revoke Pass Type ID certificates. I'm intrigued as to what your Apple Technician was referring to since as far as I am aware, there is no such service.
// rant
What is frustrating about this is that there are a number of approved Apps that allow full pass customisation but issue the passes under the App developer's certificate.
Apple also seem to turning a blind eye to certain services that issue passes under their own certificate that bear the logo and trademark of major brands (and then have the audacity to call on these brands to 'claim their passes').
Even Passtools (now Urban Airship) claim to offer a 'Unique Apple Developer Certificate from PassTools', which technically would be in violation of the Apple Developer Agreement.
So the bottom line is that on this occasion, you may have just been unlucky.
// end rant
I'm not sure what the technician was talking about, but 23.3 refers to a server (likely yours) going through a signing process with the pass before sending the pkpass file to a device.
For high level information, review the "signing and compressing the pass" section of the passbook programming guide.
Should I use SSL to secure my custom made CMS? I will be trying to accept Credit card info through a form, after my clients' login. It sounds good to me, but what does everyone else think?
I'd strongly suggest reading up on PCI and PA-DSS if you're intending to collect credit card data. At the very least, you need to ensure:
All transactions are conducted encrypted, so yes SSL is a necessity.
You either encrypt or not store the card numbers.
But definitely, read up on the above because you leave yourself very wide open legally if your system gets compromised.
PCI Security Standards Council has a lot of documentation available.
I think there may well be legal issues if you don't use SSL while handling credit card data. See the PCI data security standard for details.
Personally I wouldn't submit my credit card details through an unsecured page.
A large (and increasing) proportion of web users expect to see SSL ("the padlock") when submitting sensitive details over the web.
Not to mention the fact that you're almost certainly breaking the credit card companies' PCI rules by not using SSL.
Um.. If you're collecting any personal data you should be using SSL.
My opinion at least.
Of course if the backend isn't secured at all, it doesn't help much.
Have you thought of using a 3rd party merchant?
They are often as secure as possible and trusted by users.
Like #RichieHindle mentioned, it is required to use SSL while collecting credit card info. At least Visa and MasterCard requires it.
Also, from the perspective of users, it will show that you take care of the security of their data.
If I am setting up a site how would I go about ensuring that the person who gives me a credit card number (for instance) is the person who is authorized to use it? Maybe more generally how would I go about reducing the opportunity for fraud and stolen ID usage whether it be for a purchase or system access.
I don't work in this field (online purchases) but I would think that authentication of a user has to be a very hard/tricky endeavor.
I would say just stick with the industry standard methods.
Someone is assumed to have posession of the card if they can supply information which verifies with the card payment gateway. As part of that, for example is the Mastercard/VISA 3D auth scheme which adds a passphrase to online payments.
You could try and go further than this 2-factor authentication with fraud prevention, but the credit card companies have more of a vested interest in it so just follow their lead.
Another common method is the address verification system, used by lots of online vendors.