cancel
Showing results for 
Search instead for 
Did you mean: 

SIM questions

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

 

dadamssg
Contributor
11 REPLIES 11

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

 

WHeisenberg
Regular Contributor

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.

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

WHeisenberg
Regular Contributor

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 :)

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*

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

 

WHeisenberg
Regular Contributor

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.

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

 

WHeisenberg
Regular Contributor

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

 

<input type='hidden' name="x_relay_response" value="TRUE"/>

<input type='hidden' name="x_relay_url" value="http://mysite.com/auth/index.php"/>

 

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?