[RESOLVED] How to process a payment through a php shopping cart?

[Paul_help_]

which of these payment processors is the best to use?

could you give me a brief introduction to each of them?

... and are they free to use?

[dalecosp]

I'd talk to your banking institution. And, despite the fact that we'd all like to think mankind is altruistic and basically good (my theology actually tells me otherwise), no one will touch your money for free. 😉

cardfellow.com wrote:

If you're looking for quick numbers, here you go: the average credit card processing cost for a retail business where cards are swiped is roughly 1.95% - 2%. The average cost for card-not-present businesses, such as online shops, is roughly 2.30% - 2.50%.

[sneakyimp]

Paul help!;11061957 wrote:

which of these payment processors is the best to use?

"Best?" What do you mean by that? As I pointed out, there are many considerations. You'll have to make your own assessments.

Paul help!;11061957 wrote:

could you give me a brief introduction to each of them?

No. I've only used Paypal and Authorize.net recently. Paypal's documentation sucks and it's often hard to get answers. That said, they have some service options that are good for beginners and low volume businesses. Authorize.net seems slightly better in terms of customer support. You'll need to do your own research and decide for yourself.

[Paul_help_]

thanks guys.

What is the difference between a 'payment service provider' and a 'payment gateway'?

And which one is more secure, and generally most preferred by people?

[sneakyimp]

Paul help!;11061965 wrote:

What is the difference between a 'payment service provider' and a 'payment gateway'?

I could be wrong, but those two terms seem to me to refer to roughly the same thing. You basically need some organization that offers a web API that you can integrate with your website in order to collect money from your customers and put them in your bank account. You would call this company the "payment service provider." The "payment gateway" might refer more specifically to their API and online system that you contact to process the payments.

Paul help!;11061965 wrote:

And which one is more secure, and generally most preferred by people?

Sadly, such broad questions are probably not going to yield an answer. As the great Bruce Schneier said, "security is not something you can buy; it is something you must get." It's important to realize that YOU are responsibly for making sure that your site is secure. You owe this to your customers. Any payment gateway you choose to use will have advice about how to make things secure, but you have to follow those steps. The PCI Compliance Standards are really just an effort by credit card companies and payment service providers to lay responsibility at the feet of those who use their services.

If you plan to do this yourself, you should educate yourself. It's a pain in the ass and there really aren't any shortcuts. If you get someone else to do it for you, choose wisely and also educate yourself.

[dalecosp]

sneakyimp;11061967 wrote:

I could be wrong, but those two terms seem to me to refer to roughly the same thing. You basically need some organization that offers a web API that you can integrate with your website in order to collect money from your customers and put them in your bank account. You would call this company the "payment service provider." The "payment gateway" might refer more specifically to their API and online system that you contact to process the payments.

He typed this so I wouldn't have to. Thanks also Sneaky for referring to Schneier ... we need more people to think responsibly about security. I'll have to give credit to Paul for at least asking questions ... even if he should possibly put a little more of his own research forward before asking here.

[cluelessPHP]

dalecosp;11061973 wrote:

He typed this so I wouldn't have to. Thanks also Sneaky for referring to Schneier ... we need more people to think responsibly about security. I'll have to give credit to Paul for at least asking questions ... even if he should possibly put a little more of his own research forward before asking here.

To be fair you guys have been doing work for a good few years, when first starting out it can be a rather daunting challenge.

[sneakyimp]

I apologize if I've been a bit gruff-sounding about these questions. They are in fact reasonable questions. If I sound frustrated, it is likely because payment gateways are pretty frustrating to work with. I've yet to see any really good php sdk's for a payment gateway, and the payment gateways themselves tend to be elaborate and their documentation is messy. This is partly because collecting money is complicated:
payments sometimes go through no problem
sometimes they fail with no good information about why they failed
sometimes payments later get refunded due to a charge dispute or other reasons
sometimes the payment gateway puts the payment on hold
payment gateways support both authorizations which just check if the money is available (e.g., if you were checking into a hotel) and also auth-and-capture where you check for the money and then take it from their account
payment gateways have their own complicated account settings: do we have to verify the billing address? do we have to collect the CVV code on the back of the card? etc.
* payment gateways can respond with dozens of possible response codes. Authorize.net's API returns something like 320 "response reason codes".

There's also the fact that the internet evolves rapidly. What is secure today probably won't be in five years. Payment gateways tend to make changes to improve security like the ones I was inquiring about here. Paypal has numerous "products" which tend to require different interactions with their API and they have different versions of their API which have different requirements and peculiarities. Just finding the right documentation on their sprawling website documentation is kind of a crapshoot.

If I were to suggest a broad approach to taking payments, I would first choose a few "major" providers (Amazon, Authorize.net, Google, Paypal) and try to compare their costs and prerequisites (like setup fees, you might need a particular kind of business bank account, you might need a securly hosted website, etc.) and then once you find one that looks suitable from a business standpoint, then try to find the latest SDK and start to figure out how to actually use the beast. In my experience, it's nearly impossible to get any reasonable customer support directly from any of those companies except Authorize.net.

If your site doesn't support HTTPS access, that's a major consideration because you'll need to redirect customers to your payment gateway's website to make the payment and then they redirect back to your website. You need to be careful collecting sensitive information. It should only be collected if the site is securely hosted (HTTPS) and you should never store this data unless you take extensive measures to protect it. Note that paypal has its own shopping cart approach where you can just put 'add to cart' buttons on your site and paypal maintains the shopping cart data. Authorize.net has Simple Checkout or something like that.

[Weedpacket]

And yet another complication on top of sneakyimp's - one that I've had to face more than once:

• Handling money has to be in compliance with laws that vary from territory to territory as well as from time to time.

Sometimes there just isn't enough incentive for gateways to keep every module for every territory up to date. Paypal for instance might completely rejig their API for some reason, but only in certain countries with others having to continue using the old one for some unspecified time, from which existing features are dropped as incompatible with the new system.

[dalecosp]

sneakyimp;11061977 wrote:

In my experience, it's nearly impossible to get any reasonable customer support directly from any of those companies except Authorize.net.

Because they're the only one of those named that's not a MEGAcorporation, and the Megas figured out when the first bubble burst that customer support is too costly to maintain.

If your site doesn't support HTTPS access, that's a major consideration because you'll need to redirect customers to your payment gateway's website to make the payment and then they redirect back to your website. You need to be careful collecting sensitive information. It should only be collected if the site is securely hosted (HTTPS) and you should never store this data unless you take extensive measures to protect it. Note that paypal has its own shopping cart approach where you can just put 'add to cart' buttons on your site and paypal maintains the shopping cart data. Authorize.net has Simple Checkout or something like that.

I'd suggest not even trying to do any transactions if your site's not HTTPS. The move is on to serve every page on the WWW secure ... not sure but it's a pipe dream, but expectations are rising ...

Thanks to LetsEncrypt, HTTPS is easier to afford; certs are free if you can learn to use their software ... the major cost is now that, in many environments, you need one IP address for each site that has a certificate; at most hosting companies this is a fairly trivial expense (there is some technology out there on the horizon that's supposed to allow multiple SSL hosts on one interface I seem to recall).

[Derokorian]

dalecosp;11061983 wrote:

Thanks to LetsEncrypt, HTTPS is easier to afford; certs are free if you can learn to use their software ... the major cost is now that, in many environments, you need one IP address for each site that has a certificate; at most hosting companies this is a fairly trivial expense (there is some technology out there on the horizon that's supposed to allow multiple SSL hosts on one interface I seem to recall).

You don't need one IP per site/cert. I have many sites all with certs on the same box with a single IP pointing to it. You just need the host to resolve to that box. It's actually pretty simple single command to get the cert to the box, and then you can install a cron that automatically renews it when it's near expiration.

Here is all it takes for me to get ssl working through my ansible scripts:

---
- name: install ssl dependencies
  yum: name={{item}} state=present
  with_items:
    - certbot

- name: stop httpd
  service:
    name: httpd
    state: stopped

- name: install certs
  command: certbot certonly --domains {{item}} -m [e-mail] --agree-tos -n --standalone
  with_items: "{{domains}}"

- name: install cerbot cron
  cron:
    job: "sleep ${RANDOM:0:2}m ; certbot renew --quiet"
    minute: 0
    hour: 2,14

- name: start httpd
  service:
    name: httpd
    state: started

domains is an array holding many different domains on the box (most sub-domains but still). To summarize: install certbot from yum, stop httpd, install certs, install a cron to keep them up to date, and start httpd. That's all there is to it! Free, and cost only the time it took to setup ansible once.

[Derokorian]

Oh, yeah then you need to set up your vhost config to work with ssl. Mine looks like:

<VirtualHost *:443>
    ServerAdmin webmaster@{{item}}
    ServerName {{item}}

DocumentRoot "/usr/local/apache2/htdocs/{{item}}"

LogLevel warn
ErrorLog "logs/{{item}}-error_log"
CustomLog "logs/{{item}}-access_log" common

<IfModule mod_headers.c>
    Header always unset ETag
    Header always set X-Frame-Options: deny
    Header always set X-XSS-Protection: "1; mode=block"
    Header always set X-Content-Type-Options: nosniff
    Header always set X-WebKit-CSP: "default-src 'self'"
    Header always set X-Permitted-Cross-Domain-Policies: "master-only"
</IfModule>

SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
SSLCertificateFile /etc/letsencrypt/live/{{item}}/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/{{item}}/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/{{item}}/fullchain.pem
</VirtualHost>

Where item is one of the domains in the same domain array. The SSL bits are all at the bottom, the other parts are the same for all my sites whether https or not.

[laserlight]

dalecosp wrote:

there is some technology out there on the horizon that's supposed to allow multiple SSL hosts on one interface I seem to recall

You're probably thinking of SNI, which has been around for over a decade.

[dalecosp]

laserlight;11061989 wrote:

You're probably thinking of SNI, which has been around for over a decade.

Thanks ... and yes, although "over a decade" doesn't ring true in practical terms. True that Firefox and IE added it 11 years ago, but Windows XP never supported it and people are still stuck on that OS; the PHP OpenSSL extension only added support in 2014.