topic Re: SIM questions in Integration and Testing

SIM questions

dadamssg — Mon, 18 Jul 2011 21:31:03 GMT

Can you set a different type of transaction using SIM? i.e. "auth_only"

Can you get a response somehow using SIM? i.e. amount of transaction, customer name, transaction id

Re: SIM questions

WHeisenberg — Tue, 19 Jul 2011 01:25:36 GMT

SIM allows for you to send AUTH_ONLY or AUTH_CAPTURE transactions (get validation only, or get validation and charge the card)

You can see this information on the SIM Implementation guide at http://developer.authorize.net/guides/SIM/ under the "Requesting the Secure Hosted Payment Form" topic in Section 3.

As far as returned values, there are a bunch of them. You can see those under the "Fields in the Payment Gateway Response" topic in Section 6 of the same page/document.

Returned values include response codes, transaction ID's, invoice numbers, payment amounts and a bunch of other stuff.

Just remember that no matter which API you use (SIM, AIM, CIM, etc..) none of those will ever return the full credit card number or expiration date. (Just threw that in there because it very often comes up as a question later on).

Enjoy :)

WHeis

Re: SIM questions

dadamssg — Tue, 19 Jul 2011 02:13:01 GMT

WHeisenberg you are really helping me out! : )

I'm wondering if the response ("relay") information makes me need to be PCI compliant? Ideally, i'd like to store some of that info into a database to track numbers and display receipts. I don't want to do it if that requires me to be PCI compliant though.

I don't know if storing the transaction id, customer name, and amount is PCI compliant sensitive.

Re: SIM questions

WHeisenberg — Tue, 19 Jul 2011 03:14:55 GMT

I don't think that information has anything that the PCI cops would even raise an eyebrow at.

What they DONT want you to do is pass/store full credit card numbers (which AuthNet wont send back to you anyway) or card expiration dates in combination with a full credit card number (again, which AuthNet wont send back anyway) without the appropriate security in place.

You have to have a transaction ID.. that's obvious. Customer name.. yep.. Date, amount, what they bought.. all of that can be stored locally without worrying about PCI issues so long as you dont store their credit card number in your database or pass the full credit card number TO authorizenet through a form.

If you don't store full credit card numbers on your database AT ALL, even if some hacker managed to scam your data off your site, there would be nothing there that would be useful to them.

If your customer is using a form on the AuthorizeNet site to input their information, and not on your site, then the actual 'full credit card number' is never going to pass between your site and Authnet because the customer is already AT the authnet site when they input that card number.

PCI is mostly interested in whether your site/database is secure if you actually store credit card numbers on your server, and that your site itself is capable of sending data securely (SSL) if you pass the actual credit card number from your site to your processor (AuthNet).

If you don't do either of those things, PCI isn't interested in you.

WHeis

Re: SIM questions

dadamssg — Tue, 19 Jul 2011 03:51:00 GMT

WHeisenberg...i...i love you.

haha, seriously though, thanks so much for all the information. HUGE help and EXTREMELY inspiring now that i know the tricks to avoid having to become PCI compliant.

THANKS A TON :)

Re: SIM questions

dadamssg — Tue, 19 Jul 2011 14:54:24 GMT

so i posted this same question here before we talked. As you can see, John Conde, a well known authorize.net developer, is saying that i need to be PCI compliant to use the freaking relay response now. How in the world do you code something to do a certain thing based on the success of the transaction if you can't see the response!?!

*frustrated*

Re: SIM questions

WHeisenberg — Tue, 19 Jul 2011 15:24:55 GMT

Hehe.. he scared you :P

In his reply it says, "If you handle or store any data covered by PCI DSS standard.."

You are trying to get the customer name, a transaction ID, maybe an invoice/order number, and how much the customer paid.

Those are 'safe' to pass through the relay response URL string.

So long as you dont pass or store the actual FULL credit card number you're going to be fine. Since you are using the form on AuthNet for your customers to enter that card number, they are not on your site doing it, so you are not transmitting the card number anywhere. Since AuthNet doesn't pass back the full credit card number anyway, there is no possible way (if you are using the AuthNet-server payment form) that you can even get the full card number.

When it comes to transactions, there are just a couple things to understand about what would require the strict PCI Compliance stuff:

1. If you store the full credit card number (4111-1234-2344-3838) in any way, shape or form within your own site - you must be PCI Compliant

2. If you transmit a full credit card number, either through a form on your site (to be passed to AuthNet for processing) - or if the full credit card is passed back to your own site from an outside source (which AuthNet wont do anyway), you must be PCI Compliant.

If you're not storing the full credit card number AND a full credit card number is never passed to/from any page on your site - you are pretty much safe from the PCI monster.

There are running debates on whether or not the expiration date of a card counts as something requiring PCI compliance as well. According to the PCI standards, a merchant can store and pass an expiration date for a credit card so long as they are not also storing/passing the full credit card number as well.

AuthNet seems to disagree on that issue. They say that their understanding of the standard is that an expiration date is just as much 'secure' information by itself as a full credit card number - even if it is not being stored/passed with a full credit card number.. which is an incorrect assumption.. but since they seem to be solidified in their resolve on that issue, I doubt we'll be seeing anything but 'XXXX' being passed back through any of the API's for quite awhile /grin.

But that's a separate issue.

From what you've said previously, you are setting up your e-commerce so that your site never requests, uses, passes, gets or stores a full credit card number from a customer. It is all going to be done on AuthNet's system. So you're good to go :)

WHeis

Re: SIM questions

dadamssg — Tue, 19 Jul 2011 15:37:56 GMT

thanks wheisenburg! $10K+ fines scare the crap out of me so i'm trying to be absolutely sure i'm safe from them.

You said the customer name, transaction id, and invoice number are safe to pass through the relay response url...you make it sound like you can choose which information gets POSTed to the url. Is that true? I assumed it was an all or nothing type deal.

I've been looking over the api documentation and i can't find anything about that or even what items even get POSTed to a specified url.

Re: SIM questions

WHeisenberg — Tue, 19 Jul 2011 15:53:41 GMT

http://developer.authorize.net/guides/SIM/

Section Six : Fields in the Payment Gateway Response

I think you'll be happy with the amount of data that is available there. It all gets passed back to you and you can just pick and choose what you need from it.

Lets say you tell AuthNet that you want the x_relay_url to be http: // www.whatever.com/myreturnpage.php

When the transaction concludes at AuthNet's end, they will return the customer to that page - along with all of the fields and values that are listed in the section of the document I listed above.

They are going to POST that information to your page through a form - so the actual variables and values wont show up in the URL bar of the customers browser.

You can then treat that posted data the same way you would treat any form that you may have created that passes information between pages on your own site.

If you need the transaction ID of the purchase, that would be x_trans_id.

In php I'm pretty sure you'd get the value of that by using $_POST["x_trans_id"]

In ColdFusion we simply use #x_trans_id#

You'll probably want to start out by finding the value of the actual x_response_code that gets passed to the page you set up using the x_relay_url. If it's a '1' then the transaction is a success and you can go on from there with whatever you need your site to do with the order. If it isn't a '1' then the transaction either failed, or is 'on hold' for some reason, and you'll have to have your site respond to that accordingly.

Have Fun :)

WHeis

Re: SIM questions

dadamssg — Tue, 19 Jul 2011 16:16:07 GMT

i can't seem to get the relay url to work. It won't return me back to my site.

in the Response/Receipt URLs section in my settings i have

http://mysite.com/auth/index.php -- Default Receipt URL

http://mysite.com/auth/index.php -- Default Relay Response URL

Then for my Relay Response part in my settings i have

http://mysite.com/auth/index.php

then in my actual form i have

The code that i have at http://mysite.com/auth/index.php appears in the browser, but the browser is still at https://test.authorize.net/gateway/transact.dll. No redirection occurs. Have any idea?

Re: SIM questions

WHeisenberg — Tue, 19 Jul 2011 16:23:39 GMT

Strange..

In my own code I dont use the same page the form is on as the x_relay_url.

You might try changing the x_relay_url to a different page (???)

Maybe, since AuthNet is basically firing up "http://mysite.com/auth/index.php" to get to the form, it is confused and says "Oh, I'm already here anyway".

Not sure, but that's the first thing I'd change.

WHeis

Re: SIM questions

dadamssg — Tue, 19 Jul 2011 16:38:16 GMT

Tried changing x_relay_url to a different page and it threw an error. Then i removed the hidden x_relay_url input from the form to see what happenned and it still worked like it was(displayed my page but with the auth url).

I guess it doesn't really matter as long as i use absolute url links in my response/relay page and i can still use my server to handle the POSTs...