ShareaSale Integration Not Working

Hello s2M,
I am trying to integrate SAS with s2M. My test transaction is not registering with SAS, but the payment goes through. I spoke with the help desk at SAS and they think the issues is the lack of a redirect thank you page.

General Info about SumIgni.com:

• We are using Authorize.net to process payment.
• Once a payment transaction is process on the sumigni.com site, the user is not redirected to a thank you page or login welcome page. Instead the user stays on the Check Out page after processing. A message then appears after the transaction and reads: “Thank you. Your account has been updated. –Please log back in now.” The user is actually already logged in, but the “please log back in now” still appears.
• SAS requires the tracking code to be placed in a thank you page where the user is redirected after processing payment. SAS says:

The code given to you at the bottom of this page, should be placed in the HTML body of your “Thank You” page, which is also referred to as the confirmation, and/or receipt page. This page is on your website – and for Per-Sale programs typically displays a “Thank You” summarizing an order….It is important that this confirmation page can not be accessed without completing a sale or a lead, and also can not be reloaded or refreshed.

• Our site uses an Auto Login hack in h2Hack. Which disables the ability to use the success=”” attribute.
• No Ad Blocker on Firefox or Norton is installed

Questions

• How is the Authorize.net process suppose to work? Is there suppose to be a redirect or just a message?
• How can we disable the message (it doesn’t apply anyway, users are already logged in) and get the user to be redirected to a thank you/summery/etc page? success=”” atr doesn’t work because of the auto login hack.
• How are other s2M Authorize.net SAS users getting this to work?

S2M API/Tracking

Signup Tracking Codes:

<img src="https://shareasale.com/sale.cfm?amount=%%initial%%&amp;tracking=%%subscr_id%%&amp;transtype=SALE&amp;merchantID=45441" width="1" height="1" border="0" />

Modification Tracking Codes:

<img src="https://shareasale.com/sale.cfm?amount=%%initial%%&amp;tracking=%%subscr_id%%&amp;transtype=SALE&amp;merchantID=45441" width="1" height="1" border="0" />

Capability Tracking Codes

<img src="https://shareasale.com/sale.cfm?amount=%%amount%%&amp;tracking=%%txn_id%%&amp;transtype=SALE&amp;merchantID=45441" width="1" height="1" border="0" />

Authnet-ipn.log

PHP v5.2.17 :: WordPress® v3.5 :: s2Member® v130116 :: s2Member® Pro v130116
Memory 35.00 MB :: Real Memory 35.25 MB :: Peak Memory 35.13 MB :: Real Peak Memory 35.25 MB
sumigni.net/?s2member_pro_authnet_notify=1
User-Agent: 
array (
  's2member_log' => 
  array (
    0 => 'Unable to verify POST vars. This is most likely related to an invalid Authorize.Net® configuration. Please check: s2Member -> Authorize.Net® Options.',
    1 => 'If you're absolutely SURE that your Authorize.Net® configuration is valid, you may want to run some tests on your server, just to be sure $_POST variables are populated, and that your server is able to connect to Authorize.Net® over an HTTPS connection.',
    2 => 's2Member uses the WP_Http class for remote connections; which will try to use cURL first, and then fall back on the FOPEN method when cURL is not available. On a Windows® server, you may have to disable your cURL extension. Instead, set allow_url_fopen = yes in your php.ini file. The cURL extension (usually) does NOT support SSL connections on a Windows® server.',
    3 => 'array (
  's2member_pro_authnet_notify' => '1',
  'x_response_code' => '1',
  'x_response_reason_code' => '1',
  'x_response_reason_text' => 'This transaction has been approved.',
  'x_avs_code' => 'Y',
  'x_auth_code' => '044113',
  'x_trans_id' => '4944951595',
  'x_method' => 'CC',
  'x_card_type' => 'Visa',
  'x_account_number' => 'XXXX1815',
  'x_first_name' => 'api-test',
  'x_last_name' => 'api-test',
  'x_company' => '',
  'x_address' => '6210 e 13th ave',
  'x_city' => 'denver',
  'x_state' => 'co',
  'x_zip' => '80220',
  'x_country' => 'US',
  'x_phone' => '',
  'x_fax' => '',
  'x_email' => 'jill@jillmugge.com',
  'x_invoice_num' => 's2-50f97184cc314',
  'x_description' => '$1.00 USD / Monthly ( recurring charge, for ongoing access )',
  'x_type' => 'auth_capture',
  'x_cust_id' => '',
  'x_ship_to_first_name' => '',
  'x_ship_to_last_name' => '',
  'x_ship_to_company' => '',
  'x_ship_to_address' => '',
  'x_ship_to_city' => '',
  'x_ship_to_state' => '',
  'x_ship_to_zip' => '',
  'x_ship_to_country' => '',
  'x_amount' => '1.00',
  'x_tax' => '0.00',
  'x_duty' => '0.00',
  'x_freight' => '0.00',
  'x_tax_exempt' => 'FALSE',
  'x_po_num' => '',
  'x_MD5_Hash' => '7AE78CF79EE99FD5C9DC8AF2A689F4B7',
  'x_cvv2_resp_code' => 'M',
  'x_cavv_response' => '',
  'x_test_request' => 'false',
  's2_initial_payment' => '1',
  's2_invoice' => '1:training_process,training_intro',
  's2_custom' => 'sumigni.com',
)',
  ),
)

• This topic was modified 3 years, 11 months ago by  Schott Taylor.
• This topic was modified 3 years, 11 months ago by  Schott Taylor.

Thanks for reporting this important issue.

The Auto-Login hack that you mentioned, I believe, was posted by someone in the forums quite awhile back. Since that time there have been numerous issues reported, which were related to this hack. The hack that I’ve seen some site owners use, will actually prevent s2Member’s post-processing of a transaction from being completed. This can lead to several issues.

If you have a link to the article where you found this hack, please post it in a reply here so we can backtrace that and have it removed and/or post a warning to others.

How is the Authorize.net process suppose to work? Is there suppose to be a redirect or just a message?

In the scenario you’ve described, a customer should receive a message stating, “Thank you. Your account has been updated. – Please log back in now.”. You can modify this by setting up your success="" attribute and redirecting the customer to a message of your choosing.

By default, there is no separate Thank-You page, we handle this dynamically. The Thank-You page, is that message, “Thank you. Your account has been updated. – Please log back in now.”. This is also where s2Member displays your Signup Tracking Codes (or Modification Tracking Codes) in the scenario you described.

See: Dashboard -› s2Member® -› API / Tracking -› Signup Tracking Codes
See also: Dashboard -› s2Member® -› API / Tracking -› Modification Tracking Codes

If you setup a success="" attribute, your Signup/Modification Tracking Codes will be displayed at the bottom of your custom Post or Page, as indicated by the value of your success="" attribute. If these are not working as expected, please remove the Auto-Login hack that you’ve implemented with custom code. Also, please verify that your theme is performing the wp_footer action which is standardized by WordPress. This is what s2Member uses to display your Signup/Modification Tracking Codes.

How can we disable the message (it doesn’t apply anyway, users are already logged in) and get the user to be redirected to a thank you/summery/etc page? success=”” atr doesn’t work because of the auto login hack.
How are other s2M Authorize.net SAS users getting this to work?

This is what the success="" is for. If you’re dealing with a Pro Form for Billing Modifications, then each User/Member will already be logged in, so you could set your success="" attribute to the Login Welcome Page URL, if you like. This way they are taken back to their “My Account” page (aka: Login Welcome Page). Please see also: Knowledge Base » Customizing Your Login Welcome Page

---

Your log file indicates that s2Member is also having trouble verifying $_POST vars. This could indicate that you have an invalid and/or expired Secret MD5 Hash configured with s2Member®. Please see: Dashboard -› s2Member® -› Authorize.Net® Options -› Account Details -› Secret MD5 Hash

---

*Tip* ShareASale® also provides an alternative method, using a 3rd-party call. The alternative 3rd-party call, could be used with s2Member -> API Notifications. A 3rd-party call, is essentially an HTTP connection that runs silently behind-the-scene, as opposed to being loaded in a browser. It’s a bit more powerful (and reliable), but also more advanced.

Please let us know if problems persist :-)

Hi Jason,
Thank you for such a quick and thorough response.
That auto-login hack worked fantastic! I had an earlier post concerning the failure of the success=”” atr in conjunction with the auto-login hack. I gave up hope on a solution.

If you have a link to the article where you found this hack, please post it in a reply here so we can backtrace that and have it removed and/or post a warning to others.

I will look for those articles and post them here. There were actually 2 that were very similar. we were using the older one that caused a the redirect url to end in /?first.

Unfortunately we are still not able to get SAS working.

Now that we have the auto-login AND success=”” atr working, we redirect new users who are just registering to the /sign-me-up page (members option page) and new and existing users who have landed on the checkout page to the /member-pages/login-welcome page after a payment transaction. The redirects work, the tracking codes do not.

Tests

SAS Tracking Codes are the same as above, but with the following adjustments

1. Ran a transaction with the new auto-login hack | Fail :(

If you setup a success=”” attribute, your Signup/Modification Tracking Codes will be displayed at the bottom of your custom Post or Page, as indicated by the value of your success=”” attribute.

2. I read this to mean that I needed to add the SAS tracking coded to Specific Post/Page Tracking Codes, to which I did. Could there be a conflict if I do not take the Specific Post/Page Tracking Codes out? | Fail :(
3. Then I read it to mean that I needed to add the SAS tracking coded directly into the /member-pages/login-welcome page, to which I did | Fail :(

If these are not working as expected, please remove the Auto-Login hack that you’ve implemented with custom code.

4. I wasn’t sure what ‘these are’. The Tracking Code or the success=”” atr? The auto-login is very important to the sales process, so I ask with trepidation, are you saying here that the auto-login hack and the SAS affiliate tracking code are incompatible?

Also, please verify that your theme is performing the wp_footer action which is standardized by WordPress. This is what s2Member uses to display your Signup/Modification Tracking Codes.

5. WP codex says the wp_footer() is suppose to be located just before the closing body tag. We had a script before the body closing tag, so I moved the wp_footer() below the script and ran a transaction test | Fail :(

Your log file indicates that s2Member is also having trouble verifying $_POST vars. This could indicate that you have an invalid and/or expired Secret MD5 Hash configured with s2Member®. Please see: Dashboard -› s2Member® -› Authorize.Net® Options -› Account Details -› Secret MD5 Hash

6. We have not yet tested the validity of the MD5 Hash. | unknown result

*Tip* ShareASale® also provides an alternative method, using a 3rd-party call. The alternative 3rd-party call, could be used with s2Member -> API Notifications. A 3rd-party call, is essentially an HTTP connection that runs silently behind-the-scene, as opposed to being loaded in a browser. It’s a bit more powerful (and reliable), but also more advanced.

Thank you for mentioning this tip. You actually have to get special permission from SAS to use this method. I’ve inquired hoping this could be a work-around if the issue isn’t the MD5 Hash. I’m also leery of my skills to implement this option.

• This reply was modified 3 years, 11 months ago by  Schott Taylor.

Hi Jason,

UPDATE: Upon the suggestion of SAS, I ran another test and captured the source code after the transaction. The SAS tracking code is showing up, however the replacement codes are not passing through the values:

<img src="https://shareasale.com/sale.cfm?amount=%%initial%%&#038;tracking=%%subscr_id%%&#038;transtype=SALE&#038;merchantID=45441" width="1" height="1" border="0" />

What could be causing this?

In your video, you mentioned that the “amount= ” might have to be %%regular%% vs %%initial%% because the code will choke on a 0 value. But we do not have an amount of 0 (no trial period). About 98% of the users will register before they get to check out, but there is no payment transaction.

We can hard code in the amount=, but doesn’t the tracking= need to be dynamically generated?

please help

• This reply was modified 3 years, 11 months ago by  Schott Taylor.

Jason, Cristian and Raam,
It’s been over 48 hours since I’ve heard from anyone at s2M. Can I please ask you to please help us with our issue?

I just received another notice from the SAS help desk:

1) The ShareASale tracking code pixe should be installed in only 1 location, that being the thank you page a customer is auto returned to when they complete a purchase.
So this tracking code should only display from a completed purchase not from any other action. So you should verify it is not in all 4 boxes you referred to.

I have the SAS pix img located in all of the following API/Tracking boxes: Signup Tracking Code, Modification Tracking Code and Capability Tracking Code (as stated in my first post). The SAS gentleman is suggesting that it should only be in one location. I’m assuming that each of these tracking code boxes only actually puts the code in 1 area of the site, so that it would NOT cause a conflict with the replacement codes.

I searched the message again boards to see what causes a conflict or why the replacement codes are not passing through the data and did not come up with any supporting documents.

Please, we need your assistance.

• This reply was modified 3 years, 11 months ago by  Schott Taylor.

Thanks for the follow-up :-)

Hi Jason,

UPDATE: Upon the suggestion of SAS, I ran another test and captured the source code after the transaction. The SAS tracking code is showing up, however the replacement codes are not passing through the values:

What could be causing this?

This would indicate to me that you have unsupported Replacement Codes in this Tracking Code, based on the type of sale that was completed. I would carefully review this panel in your Dashboard, and be sure that each Tracking Code that you have, contains Replacement Codes listed as supported for that type of event.

See: Dashboard -› s2Member® -› API / Tracking

If everything looks good, please submit a Dashboard login and we’ll take a look at your configuration. Please do that privately through this form. Thanks! See: s2Member® » Private Contact Form

WARNING: Bumping your thread, or creating duplicate threads will reduce your response time from our support staff. We monitor threads by the last reply time. If you continue to reply, it will actually knock you down in the order that we process incoming requests for support.

Our average response time is 24-48 hours.

Any updates on this issue?

“Hello Schott Taylor,

Your request for s2Member® support has been received!
* You will receive a response within 24-48 hours.

Please note the forum thread you gave reference to:”

http://www.s2member.com/forums/topic/modification-tracking-codes-not-working/?qcAC=1#post-40832

Details received. Thank you!

~ Investigating your installation.

Thanks for reporting this important issue.

We’ve identified the underlying cause. This behavior is attributed to a bug in the latest release of s2Member® Pro and its Authorize.Net payment gateway integration. We’re having this corrected and a fix will be pushed out in the next maintenance release.

Until then, we’ve had this file updated on your installation to correct the problem.
/s2member-pro/includes/classes/gateways/authnet/authnet-checkout-in.inc.php

Your Modification Tracking Codes are now working as expected. See attached screenshot.

Please let us know if problems persist :-)

---

For anyone else having this problem, I’m attaching a copy of the patched file.
Please unzip and upload to your site, allowing it override your existing copy of this file.
/s2member-pro/includes/classes/gateways/authnet/authnet-checkout-in.inc.php
http://d1v41qemfjie0l.cloudfront.net/s2member/uploads/authnet-checkout-in.inc_.php_.zip

This fix went out in the release of s2Member® v130207.