AUthorize.net SIM - relay-response implementation

Hello there!

We configured the** Authorize.net SIM** module, and did a test checkout: it looked like the Authorize.net request sent by ZEN was a** relay-response** (with x_relay_response=TRUE) with a certain hard-coded x_relay_url of

http://...../zen-cart/index.php?main_page=checkout_process

So we configured Authorize.net to accept this as a ** x_relay_url **

Question 1. Is this value documented anywhere?

Then the Authorize.net relay-response worked from the Authorize.net end, but Zen-cart didn't provide a useful receipt page. Looking through the code we found

Line 19 of file includes/modules/checkout_process.php :

// if the customer is not logged on, redirect them to the time out page
if (!$_SESSION['customer_id']) {
zen_redirect(zen_href_link(FILENAME_TIME_OUT));
} else {

Surely the Authorize.net server is not going to send a **cookie **with the relay-response request?

Question 2. Did we miss a step to get Zen-cart to work with Authorize.net SIM ?

Thanks a lot!

Stephan

What version of Zen Cart are you using?
Did you configure the SIM module to use "offsite" or "onsite" mode?

Yes, I forgot to mention the version. We extracted the file

zen-cart-v1.3.8a-full-fileset-12112007.zip

We are using offsite; we want the Authorize.net server to collect the credit card numbers.

Thanks --

Stephan

swehner:

We configured the** Authorize.net SIM** module, and did a test checkout: it looked like the Authorize.net request sent by ZEN was a** relay-response** (with x_relay_response=TRUE) with a certain hard-coded x_relay_url of

http://...../zen-cart/index.php?main_page=checkout_process

So we configured Authorize.net to accept this as a ** x_relay_url **

Question 1. Is this value documented anywhere?There is no need to "configure" it ... Zen Cart sends it for you, overriding whatever you've put in your account settings.

swehner:

Then the Authorize.net relay-response worked from the Authorize.net end, but Zen-cart didn't provide a useful receipt page.What do you mean by "useful receipt page" ?
What did happen?
What didn't happen?

I thought according to the SIM specification that the relay-response URL needs to be registered with Authorize.Net through the Merchant Interface.
They write

"The gateway will reject the transaction if the URL sent in the transaction is not configured through the Merchant Interface. " (page 11, Simple Integration Method (SIM) Implementation Guide)

At any rate, what does happen for us is that when the Authorize.net server (after processing the credit card transaction) sends a relay-response request to Zen-Cart, it posts to the URL

http://...../zen-cart/index.php?main_page=checkout_process

However Authorize.net doesn't have a cookie to send along, so the SESSION is going to be empty, and we tracked down that the response by Zen-cart to the Authorize.net request is a

302-Redirect to http://..../zen-cart/index.php?main_page=time_out&zenid=4d5e...02fc

I called that not a useful receipt page, plus the order is not processed by Zen-cart, although it would have been paid for.

Is there any other information we could provide?

Stephan

swehner:

I thought according to the SIM specification that the relay-response URL needs to be registered with Authorize.Net through the Merchant Interface.
They write

"The gateway will reject the transaction if the URL sent in the transaction is not configured through the Merchant Interface. " (page 11, Simple Integration Method (SIM) Implementation Guide)

Good point. I'd forgotten about that. I seldom use SIM because AIM is much more robust and secure.

swehner:

At any rate, what does happen for us is that when the Authorize.net server (after processing the credit card transaction) sends a relay-response request to Zen-Cart, it posts to the URL
http://...../zen-cart/index.php?main_page=checkout_processThat is the correct return URL.

swehner:

However Authorize.net doesn't have a cookie to send along, so the SESSION is going to be empty, and we tracked down that the response by Zen-cart to the Authorize.net request is a
302-Redirect to http://..../zen-cart/index.php?main_page=time_outThe redirect to the timeout page is a result of the browser losing the session cookie originally set before going to authorize.net.

Before you were redirected, was there a zenid showing in your browser URL?
Do you have cookies disabled in your browser?

The redirect to the timeout page is a result of the browser losing the session cookie originally set before going to authorize.net.

Before you were redirected, was there a zenid showing in your browser URL?
Do you have cookies disabled in your browser?

Well, according to the Gateway Response API

The gateway response to a transaction submitted via SIM is either a Receipt Page
that is displayed to the consumer or a POST string to a site designated by the merchant. The
merchant can then parse the POST string, customize a response, and submit it back to the
gateway. The gateway will then relay the response to the customer’s browser.
(page 31, Simple Integration Method (SIM) Implementation Guide)

So we thought that the Authorize.net server (not the browser) sends a POST to the merchant server (Zen-cart), records the response, and then displays that to the browser. The Authorize.net server doesn't send a cookie to Zen-cart (since it wouldn't have access to the Zen-cart cookies), only the other fields listed on the same page 31 refered to above.

That's how I understand this.

Is there anyone who got SIM to work with Zen-cart?

Stephan

swehner:

Is there anyone who got SIM to work with Zen-cart?When I rewrote the SIM module for 1.3.8, it worked just fine for me, and was tested on several servers.

swehner:

Well, according to the Gateway Response API

The gateway response to a transaction submitted via SIM is either a Receipt Page
that is displayed to the consumer or a POST string to a site designated by the merchant. The
merchant can then parse the POST string, customize a response, and submit it back to the
gateway. The gateway will then relay the response to the customer’s browser.
(page 31, Simple Integration Method (SIM) Implementation Guide)

So we thought that the Authorize.net server (not the browser) sends a POST to the merchant server (Zen-cart), records the response, and then displays that to the browser. The Authorize.net server doesn't send a cookie to Zen-cart (since it wouldn't have access to the Zen-cart cookies), only the other fields listed on the same page 31 refered to above.

That's how I understand this.0. While the customer is shopping in Zen Cart, a session cookie is set in their browser, tied to the URL of your store.

1. Zen Cart sends the customer to authorize.net and passes POST info to indicate the transaction data.
2. Authorize.net collects payment from the customer.
3. When payment is approved, authorize.net sends the customer back to the checkout_process page, and picks up the included POST data, which it then processes to determine whether payment was successful or not.
4. Once confirmed, Zen Cart redirects the customer to the checkout_success page, which is essentially a receipt confirming that the payment was accepted and the order completed. They can view their order details by clicking the My Account link provided.

During steps 3 and 4, Zen Cart reads the cookie already set in the browser to know which shopping session it is supposed connect the payment details to.
There is no need for authorize.net to do anything with cookies.

Thanks a lot for your help! **Weekend **has come; more next week..

Stephan

Hi DrByte,

again, thanks so much for working this through. I don't quite understand the last 2 steps of your last post.

3. When payment is approved, authorize.net sends the customer back to the checkout_process page, and picks up the included POST data, which it then processes to determine whether payment was successful or not.

4. Once confirmed, Zen Cart redirects the customer to the checkout_success page, which is essentially a receipt confirming that the payment was accepted and the order completed. They can view their order details by clicking the My Account link provided.
   Here is the sequence according to my understanding of the SIM protocol.

1. User is at the last Zen-cart page with a Checkout button; clicks the button; the form has a POST action to an Authorize.net URL
2. User is on a Authorize.net URL; A form is displayed to collect Credit Card information; the form has a POST action to an Authorize.net URL. User fills out form, and clicks Submit button.
3. Hidden from the user, Authorize.net processes the Credit-Card payment. The result is translated into a POST to the Zen-cart server according to the "Fields in the Gateway Response" secion of Simple Integration Method (SIM) Implementation Guide, page 31. (Let's assume the payment went through)
4. Still hidden from the user, Zen-cart responds to the request POSTed by Authorize.net with HTML indicating its message to the user. ("Payment succeeded; Thanks for your order, shipping soon", etc). Also at this point the user's cart is emptied (all paid for).
5. Authorize.net takes the HTML and sends it back to the user's browser. The user's browser is still at an Authorize.net URL
6. Presumably the HTML produced by Zen-cart has links which are enticing enough for the user to click on them. Each one of these links takes the user back to a Zen-cart URL (they have absolute URL's not relative)

Note also, the Simple Integration Method (SIM) Implementation Guide says on page 15,

When the merchant’s response is relayed back to the customer, anything that is in the
HTTP headers will be replaced. This means if a developer is relying on custom
information to be in these headers, such as cookies, their implementation will most likely
fail.

This elaboration is getting quite a lengthy. Could you indicate the difference in the sequence of events to your previous posting ?

Stephan

Next week's on "Page 2"