Accepting Credit Cards

[wfitg]

I want to take credit cards on my site. However, I have no experience with any of the gateway providers.

Some of them seem quite expensive. Other not expensive at all. I have seen "Stripe" mentioned here.

Can anyone suggest the best ones to look at?

I need one that is:

1) affordable, since I am just starting this business

2) secure

3) reliable

I'm also not sure how the storage works. I would rather *not store credit card information, but still want the data available so customers do not have to enter it each time they pay. Is that possible?

[flangefrog]

I don't think any current gateway implementations can allow credit card reuse without storing the data yourself (tokenised storage).

 

You should do some research into the PCI-DSS standard - if you transmit or store credit card data you will be required to fill out a PCI-DSS SAQ D form. Even if you are only redirecting to a third party like PayPal which accepts the credit card details you are still supposed to fill out an SAQ A-EP form but I think most gateways won't require that. Have a read of this document: https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf

 

This is a good checklist with all the details of each requirement: https://www.pcisecuritystandards.org/documents/Prioritized_Approach_v3.xlsx

[Michael]

Stripe is secure, safe and amazing.

[wfitg]

Thanks. Stripe does look good and i am leaning toward that one. But, every time I go to their website it does not fully load.

[Michael]

Thanks. Stripe does look good and i am leaning toward that one. But, every time I go to their website it does not fully load.

 

No trouble on my end :s

[Paul]

If you are in the US, you might look at e-onlinedata. We're actually partnered with them, see http://e-onlinedata.com/blesta/ for details and costs.

[Max]

You should do some research into the PCI-DSS standard - if you transmit or store credit card data you will be required to fill out a PCI-DSS SAQ D form.

 

Only need C if you transmit but do not store.

 

If you want to store card holder data, you do need D, and note that it has all kinds of extra requirements the typical Blesta user does not meet.

Like that your database server must be on a private network, and that the software should only access the database through stored procedures and not be allowed to perform direct queries.

[wfitg]

If you are in the US, you might look at e-onlinedata. We're actually partnered with them, see http://e-onlinedata.com/blesta/ for details and costs.

I bookmarked this one. Read up on the parent company in Germanny too. It looks good. thanks

[wfitg]

Only need C if you transmit but do not store.

 

If you want to store card holder data, you do need D, and note that it has all kinds of extra requirements the typical Blesta user does not meet.

Like that your database server must be on a private network, and that the software should only access the database through stored procedures and not be allowed to perform direct queries.

[wfitg]

Only need C if you transmit but do not store.

 

If you want to store card holder data, you do need D, and note that it has all kinds of extra requirements the typical Blesta user does not meet.

Like that your database server must be on a private network, and that the software should only access the database through stored procedures and not be allowed to perform direct queries.

I read through "D". Much to do.

[wfitg]

I don't think any current gateway implementations can allow credit card reuse without storing the data yourself (tokenised storage).

 

You should do some research into the PCI-DSS standard - if you transmit or store credit card data you will be required to fill out a PCI-DSS SAQ D form. Even if you are only redirecting to a third party like PayPal which accepts the credit card details you are still supposed to fill out an SAQ A-EP form but I think most gateways won't require that. Have a read of this document: https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf

 

This is a good checklist with all the details of each requirement: https://www.pcisecuritystandards.org/documents/Prioritized_Approach_v3.xlsx

Thanks FF

I'll read through this too.

[flangefrog]

Only need C if you transmit but do not store.

 

If you want to store card holder data, you do need D, and note that it has all kinds of extra requirements the typical Blesta user does not meet.

Like that your database server must be on a private network, and that the software should only access the database through stored procedures and not be allowed to perform direct queries.

 

Max, I think that is correct for PCI DSS v2.0, but is it still the case for PCI DSS v3.0? This document says that SAQ C is not applicable to e-commerce channels.

 

Edit: maybe SAQ A-EP actually covers what SAQ C used to:

If any element of a payment page delivered to consumers’ browsers originates from the merchant’s 

website, SAQ A does not apply; however, SAQ A-EP may be applicable. Examples of e-commerce 

implementations addressed by SAQ A-EP include:

• Merchant website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as “Direct Post”).
• Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.

This does seem to contradict what the document says earlier though

SAQ A-EP:

E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Applicable only to e-commerce channels.

Edit 2: I think the above quote about "Direct Post" is just talking about posting customer and cart data, but the credit card is entered on the gateway's site. So it still looks to me like SAQ D is the one for merchants transmitting card data.

[Max]

 

Max, I think that is correct for PCI DSS v2.0, but is it still the case for PCI DSS v3.0? This document says that SAQ C is not applicable to e-commerce channels. 

 

Ah, wasn't aware of that.

Didn't look into it, as we do not have to comply with 3.0 yet.

 

Your "this document" link doesn't work.

It used to be the case that SAQ C was essentially SAQ D missing all the questions about storage and databases.

Wonder how that works out in 3.0 then, and if they expect us to implement all the security for a database that doesn't contain card holder data.

[Max]

 

Edit: maybe SAQ A-EP actually covers what SAQ C used to:

This does seem to contradict what the document says earlier though

Edit 2: I think the above quote about "Direct Post" is just talking about posting customer and cart data, but the credit card is entered on the gateway's site. So it still looks to me like SAQ D is the one for merchants transmitting card data.

 

Yeah, think you are right.

SAQ A-EP is only for direct POST and stripe.js like integrations.

Most people using those didn't bother to comply with any PCI requirement, and might be in for a shock once they have to comply with 3.0.

 

From a quick look, some of the requirements include:

 

- Everyone needs separate webserver, database server and DNS servers(!)

- SSL for everything

- Two-factor authentication for VPN access to your management network

 

Also has some requirements I think are stupid, like locking accounts after 6 failed attempts.

So if somebody tries to log in 6 times on my account, which they wouldn't succeed in thanks to strong password, I shouldn't be able to login as well?

 

 

 

==

Is only one primary function implemented per

server, to prevent functions that require different

security levels from co-existing on the same server?

For example, web servers, database servers, and

DNS should be implemented on separate servers

==

==

Is administrator access to web-based management interfaces encrypted with strong cryptography?

==

==

For SSL/TLS implementations, is SSL/TLS enabled whenever cardholder data is transmitted or received?

For example, for browser-based implementations:

“HTTPS” appears as the browser Universal Record

Locator (URL) protocol, and

Cardholder data is only requested if “HTTPS”

appears as part of the URL.

==

==

8.1.6

Are repeated access attempts limited by locking out

the user ID after no more than six attempts?

8.1.7

Once a user account is locked out, is the lockout

duration set to a minimum of 30 minutes or until an

administrator enables the user ID?

==

==

8.3

Is two-factor authentication incorporated for remote

network access originating from outside the network by

personnel (including users and administrators) and all

third parties (including vendor access for support or

maintenance)?

Note:

Two-factor authentication requires that two of

the three authentication methods (see PCI DSS

Requirement 8.2 for descriptions of authentication

methods) be used for authentication. Using one factor

twice (for example, using two separate passwords) is

not considered two-factor authentication.

Examples of two-factor technologies include remote

authentication and dial-in service (RADIUS) with

tokens; terminal access controller access control

system (TACACS) with tokens; and other technologies

that facilitate two-factor authentication.

==

[domaingood]

Down from my end:D

If you are in the US, you might look at e-onlinedata. We're actually partnered with them, see http://e-onlinedata.com/blesta/ for details and costs.

[astroroxy]

+1 for stripe

[Blesta Addons]

Down from my end:D

 

also the same here .