cancel
Showing results for 
Search instead for 
Did you mean: 

Converting from Simple Checkout to Accept Hosted in Wordpress

I have read through all the documentation at Authorize.net to implement Accept Hosted, and all the related threads I could find in this community. Being a novice as a programmer, I'm quite confused and still don't know how to convert my payment buttons in WordPress from Simple Checkout to Accept Hosted.

 

I have three payment buttons on my web page: https://pokerdawgs.net/upcoming-events/#registertampa

Two are for fixed amounts ($65 and $85), and one is for a variable donation amount as selected by the donor (to Special Olympics Florida). 

 

I don't need to capture any customer/donor information into a database. All I need is an email notification of the payment from Authorize.net with name and amount, like what I get currently with Simple Checkout.

 

Here is the coding I currently have in my WordPress page for one of the fixed amount buttons (added to the WordPress page through WordPress Code Editor):

<form action="https://Simplecheckout.authorize.net/payment/CatalogPayment.aspx" method="post" name="PrePage"><span style="color: #ff0000; font-size: medium;"> <input name="LinkId" type="hidden" value="*****"> <input alt="Register for Tampa Bay Charity Tournament w/add-on" height="75" name="I1" src="http://pokerdawgs.net/wp-content/uploads/registerhere85.jpg" type="image" width="150"> <strong>&nbsp; </strong></span><span style="color: #ff0000; font-size: medium;"><strong>$65.00 Entry + $20.00 Charity Add-on, for 10,000 units.</strong>
<strong>(Add-on funds donated to charities.)</strong>
</span></form>


The other two payment buttons are simliar, just different 'value' to correspond to my Simple Checkout settings in Authorize.net.

 

If someone could give me an exact example of the code I need to replace my existing code in the WordPress page for the buttons, and any additional steps I need to do to convert to Accept Hosted, it would be GREATLY appreciated. Please be simple and explicit in the explanation and assume that I know nothing about coding, file locations, etc.

pokerxanadu
Contributor
24 REPLIES 24

@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. 

@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?

@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']) &amp;&amp; $_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']) &amp;&amp; $_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.

“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.

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