Integration and Testing

[dadamssg]

So i've learned PCI compliance is going to be way too costly for me and i have to figure out a way to re-engineer my payment process to avoid having to be PCI compliant.

I was using the AIM API, but i think i'm going to have to use the Direct Post Method. Let me know if this sounds right.

Basically i'm building a shopping cart for reservations in PHP. So i'd start by the user picking out dates and other things and have everything related to the reservation stored in a session. Then take them to form that i would build that has billing information inputs, a card number input, exp date, etc. The user fills that out and hits Submit. That post goes to the authorize.net server and the authorize.net server sends a response. Based on the response i would decide whether to store the reservation information in the php session(on successful transaction) or display an error. Is that right?

I downloaded the SDK for the direct post method and tried the example and it led to a message displayed by authorize.net's website. Is there a way to only get a response code from authorize.net rather then the user landing on auth.net's website? I read that you can use javascript to redirect the customer to a receipt page on your own hosting website. How do you do that? Where do you put the javascript code?

Also, what information can you get from the response of the transaction? I'll need the Customer name and the transaction id auth.net assigns to store in my database. Can you do that using the DPM?

[WHeisenberg]

According to what I just read in the directPostMethod integration manual at http://developer.authorize.net/guides/DPM/,  this is a 'yes' and 'no' answer.

Yes, you do get a transaction ID number when a payment is made.

If you want to see the spot on the page that describes this happening,  just search the page for this:

if("1".equals(requestParameterMap.get(
ResponseField.RESPONSE_CODE.getFieldName())[0]))

And then the 'no' part of your question.  No, you can't get the buyers name.

Specifically, the document says this:

Merchant-Defined Data fields are not intended, and MUST NOT be used, to capture personally identifying information. Accordingly, Merchant is prohibited from capturing, obtaining, and/or transmitting any personally identifying information in or by means of the Merchant-Defined Data fields. Personally identifying information includes, but is not limited to: name, address, credit card number, social security number, drivers license number, state-issued identification number, passport number, and card verification numbers (CVV, CVC2, CVV2, CID, CVN). If Authorize.Net, a CyberSource solution, discovers that Merchant is capturing and/or transmitting personally identifying information by means of the Merchant-Defined Data fields, whether or not intentionally, CyberSource WILL immediately suspend Merchant�s account, which will result in a rejection of any and all transaction requests submitted by Merchant after the point of suspension.

This information is at the very bottom of the page.

I dont personally use the DPM system,  but I've been swimming through so many instruction docs on this site for the past week that it was pretty easy for me to find this info.

It appears that the DPM system will also send you back an invoice number that you supply through the transaction system.   I suppose you could get all of the customer data you need before or after the transaction is completed,  so long as you aren't trying to 'scrape' that information out of the DPM transaction itself, but that would mean the customer having to fill out yet another form.

And I thought CIM was a strange bird to figure out..

Wheis

[dadamssg]

yeah i guest i'm just really unsure of what i can store from the transaction. It seems like the name of the customer SHOULD be allowed to be stored. I guess to store some of this data i'll need to develop a form that the person fills out(name) and get that information before the transaction takes place. Too bad there isn't a way to pre-populate the input fields in SIM.

Surely, the transaction id and the amount is allowed to be stored..........right?

[WHeisenberg]

Yes,  you'll know the amount because it's tied to your invoice number.

And you CAN prepopulate the fields in a SIM transaction.   I keep reading people saying that you can't.  I do it and I've only been working with AuthNet systems for about a week.  Only worked with the SIM system for a day and got that going.

Easy to accomplish pre-population of the SIM checkout form on AuthNet:

Create the usual form that your customer will use to get to the SIM system on AuthNet.  I can't remember the original example document name because I've renamed mine already, but it's the one that sends the x_login, x_amount, x_fp_hast, etc to https://secure.authorize.net/gateway/transact.dll

Add these fields to the form (as needed):

<INPUT type="hidden" name="x_first_name" value="Joe">
<INPUT type="hidden" name="x_last_name" value="Smith">
<INPUT type="hidden" name="x_company" value="Joe Smith Company">
<INPUT type="hidden" name="x_address" value="123 Prepopulate Drive">
<INPUT type="hidden" name="x_city" value="Lebanon">
<INPUT type="hidden" name="x_state" value="TN">
<INPUT type="hidden" name="x_zip" value="37087">
<INPUT type="hidden" name="x_cust_id" value="123ID">
<INPUT type="hidden" name="x_ship_to_last_name" value="Smith">
<INPUT type="hidden" name="x_ship_to_company" value="Joe Smith Company">
<INPUT type="hidden" name="x_ship_to_address" value="123 Prepopulate Drive">
<INPUT type="hidden" name="x_city" value="Lebanon">
<INPUT type="hidden" name="x_ship_to_state" value="TN">
<INPUT type="hidden" name="x_ship_to_zip" value="37087">
<INPUT type="hidden" name="x_ship_to_first_name" value="Joe">

 Of course you would pre-populate those hidden fields with your own customer data.. but when the form gets passed over to the SIM,  all the fields that you have provided those hidden fields for will be populated with the data you put in the values on your passed form.

 You just have to use the EXACT name that the fields on the resulting form at authorizenet uses and you can pre-populate anything on that form.

 :)

 WHeis

[WHeisenberg]

Oops.. almost forgot..

If you use the method I describe above to pre-populate the fields in the SIM.. do your customers a big favor and dont try to pass the credit card number and expiration date.

Depending on how you do things on your site,  you may or may not have the full credit card number stored for the customer.   You may only have the 'XXXX1234' that AuthNet sends back from any typical transaction.

If you try to use that data to pre-populate the SIM,  the customer will actually see 'XXXX1234' in the card number field on the SIM form when they get there and have to delete the X's.

If you do have the full credit card number stored for the customer on your site,  then you can pass it if you're all PCI compliant in how you do that..  but it's easier just to not send it at all.

If you pre-populate the form correctly,  the only thing the customer will have to do when they get to the SIM form over on the AuthNet site is type in their credit card number,  expiration date,  make any changes to any of the fields that might have changed since you originally stored their info.. and they're done.

Most of the time it will just be cc number and expiration and they're finished with the form.

Once they've completed the transaction,  it's a pretty simple process to reverify all that information for your own records.. so if they changed their address while they were at the SIM payment page,  you can change it on your records as well.

:)

WHeis