Reply
Highlighted
Contributor
Posts: 11
Registered: ‎12-28-2019

Re: Converting from Simple Checkout to Accept Hosted in Wordpress

@ElaineM Thanks for the explanation. If our app and Simple Checkout stops working later this year, I think we'll have to seek out another processor that continues to offer a simple method of processing our website checkouts. Woo Commerce is not an option for us as it is a complex shopping cart system. All we need are easy checkout buttons like Simple Checkout for our clients to make purchases/donations.

 

@Renaissance I realize that the app we are using is not Simple Checkout. I was using Simple Checkout buttons (see my OP) on our website until Trent at Customer Service warned me that Simple Checkout would be going away.  I found the app and switched our website payments from Simple Checkout to the app.  I posted the app code here in the hopes that someone could tell me if it uses the correct API.  Then @ElaineM pointed out that the app uses AIM API, which is also going to go away. From what you posted earlier, converting to Authorize.net API is just too complex for me to figure out. The only solution I can come up with seems to be to switch to Square or Stripe as our processor, both of whom offer checkout processing similar to Simple Checkout. 

Highlighted
Contributor
Posts: 11
Registered: ‎12-28-2019

Re: Converting from Simple Checkout to Accept Hosted in Wordpress

@Renaissance Thanks for looking at the code. I'm not sure what you mean by the app is "posting raw cc data on our server". The app captures the cc info on a webform and immediately posts it to the Authorize.net server. The cc info is not stored in a database on our website. Are you saying that this method is not secure? Should I go back to just using Simple Checkout until we can convert to another processor?

Highlighted
All Star
Posts: 727
Registered: ‎11-05-2018

Re: Converting from Simple Checkout to Accept Hosted in Wordpress

[ Edited ]
@pokerxanadu

This code

// Decide which URL to post to
$environment_url = ( "FALSE" == $environment )
? 'https://secure.authorize.net/gateway/transact.dll'
: 'https://test.authorize.net/gateway/transact.dll';

if(isset($_POST['wpspf_authorizenet_card-number']) && $_POST['wpspf_authorizenet_card-number']!=''){
$wpspf_card_number = sanitize_text_field(str_replace( array(' ', '-' ), '', $_POST['wpspf_authorizenet_card-number'] ));
}else{ $wpspf_card_number =''; }

if(isset($_POST['wpspf_authorizenet_card-cvc']) && $_POST['wpspf_authorizenet_card-cvc']!=''){
$wpspf_cvc = intval($_POST['wpspf_authorizenet_card-cvc']);
}else{ $wpspf_cvc =''; }

if(isset($_POST['wpspf_authorizenet_card-expiry'])){
$x_exp_date = str_replace( array( '/', ' '), '', sanitize_text_field($_POST['wpspf_authorizenet_card-expiry'] ));
}else{
$x_exp_date='';
}


Your web app is sending http post requests with CC data. It doesn’t matter if you store it in a db for PCI purposes. You will get fined less if you fail an audit, probably, but you do not fall under SAQ A or SAQ A-EP, which means you by default are SAQ D and subject to all of the requirements of that scope.

You May have a different idea of what posting data means. I mean http post requests. Your PHP code has $_POST[‘authorize_card_number’], etc. That post variable is used to intercept data that is being posted to your website. Some other page on your app (or maybe the same page) is posting that data to the page in question.

This is the mechanics of how what you are doing is accomplished behind the scenes. There may be no significant difference in the front end user experience than whatever else you were using or had in mind. Also note that even if you directly post data to auth.net, the fact that the payment page is on your server and the cc data isn’t tokenized means you are SAQ D. The two ways to decrease your compliance scope are to a) have any cc data entered on your site tokenized in the browser or b) have your payment page completely outsourced to the payment gateway. That is how you get to A-EP and A, respectively.

As for what to do, I’m sticking with my original answer- nothing. Just keep using your same process. I was unaware that simple checkout uses the same form format as SIM. For your purposes this is a non issue. You do not make an API call to get your form for simple checkout. You post data to that url in the html form from your first post. When they update the SIM type form on your simple checkout, it won’t make a difference. Your app will still work. The customer will just see a different page. The only thing that will break your app is if the url to post to changes, which it probably will not, and if it does all you do is copy and paste a block of HTML.
Highlighted
Solution
Accepted by topic author pokerxanadu
‎01-07-2020 03:42 AM
All Star
Posts: 727
Registered: ‎11-05-2018

Re: Converting from Simple Checkout to Accept Hosted in Wordpress

“are you saying this is not secure”

No web application is secure. Security is measured in degrees. There are more secure and less secure apps, but there is no such thing as an app that is secure.

Where this comes into play in ecommerce is you have the PCI DSS (stands for Payment Card Industry Data Security Standards). They expect you to follow a security protocol they see as appropriate for the level of risk your app poses to cardholder data if compromised. The requirements for an outsourced payment are not hard to fulfill and are of a small number. The cardholder data never touches your app.

The protocol for apps where the cardholder data is entered on a webpage served from the merchants server is intensive and expensive. This is something to dodge unless you have a lot of revenue.

If you’re amazon . com and you do hundreds of billions in gross revenue, the added security costs are a nonissue because the benefit of having your own payment form that you completely customize, storing cc data for one click orders, etc only has to bump up your sales a tiny percentage to cover the cost and then some. I have no idea what their compliance costs are but I’m sure they’re massive.

For merchants who are smaller, I’ve roughed out about $16 k a year to implement a good, compliant protocol. I know developers who have clients on SAQ D scope integrations who do it for about 1/4th of that. The issue is that for small merchants on SAQ D they are not audited unless someone complains. They simply audit themselves, so no real way to say what they are doing is sufficient. Doing it my way I’d say $16k is a good benchmark.

What you probably don’t realize is that there are endless attempts to hack your website. I have clients who get 300 visitors a month, small businesses, and there will sometimes be dozens or scores of attempts to hack the site in a single day. People will sit there and try 50 times in a row. And those are only the attempts that are capable of being tracked. Most of these attacks are crude and have no prayer, but still it shows you what you’re up against as even a tiny merchant or business. I am sure you become a bigger target when people find out you’ve got your own payment form.

IMO there is no point in any merchant doing less than $200k net income doing anything other than a hosted payment form. For what you are doing, simple checkout is perfect.
Highlighted
Contributor
Posts: 11
Registered: ‎12-28-2019

Re: Converting from Simple Checkout to Accept Hosted in Wordpress

[ Edited ]

@Renaissance Thank you so much! I really appreciate that time you took to explain everything in terms I could understand.