Payment/Registration Take 4 Mins

We have setup s2member with authorize.net proforms. The actual processing time is taking about 2 minutes.

When we submit the payment we receive (as the merchant) an email confirmation/receipt for the transaction within 5-10 seconds of pressing the submit bottom. After that the button continues to show “Processing…” for several minutes before returning a success message. Here are a couple of examples:

Authorize.net processed at 15:57:54 User was added (based on user table) at 16:00
Authorize.net processed at 15:41:25 User was added at 15:43
Authorize.net Processed at 15:36:36 User was added at 15:38

Is there a way to speed this up?

Also the email almost always ends up in the spam folder. Is there something we can do to improve that?

I found some additional information:
The authnet POST returns quickly but a then a paypal URL is processed about 2 minutes later. The URL that’s getting hit is:
/?s2member_paypal_notify=1&s2member_paypal_proxy=authnet&s2member_paypal_proxy_use=pro-emails,subscr-signup-as-subscr-payment&s2member_paypal_proxy_verification=481d60f981ce2aa2b41dbb96494a8252&s2member_paypal_proxy_return_url=

This corresponds to the one on the paypal options page IPN w/ Proxy Key ( optional, for 3rd-party integrations )

Is there a setting we are missing?

Hi Rich.

The PayPal URL is part of the processing routine s2Member does for Authorize.Net transactions. [hilite path]Dashboard -› s2Member® -› Log Files (Debug) -› s2Member® Log Viewer -> Debugging -> s2 Core Processors[/hilite]

In your log files, what are the times for the entries of the same transaction? [hilite path]Dashboard -› s2Member® -› Log Files (Debug) -› s2Member® Log Viewer[/hilite]

Could it be that Authorize.Net is notifying s2Member after that long?

Here is the log file information from one of the transactions. It maybe important to note that we thought we would only use authorize.net (we don’t offer paypal as an option), so we do NOT have a paypal account.
On a separate issue, your response seemed to indicate that we should be able to access the log file from the WP dashboard ( Dashboard -› s2Member® -› Log Files (Debug) -› s2Member® Log Viewer) We don’t seem to have the options to view log files from the dashboard.

:
Here’s the first log from authnet-ipn.log

(I’ve also deleted out my personal information from each lo)

PHP v5.3.2-1ubuntu4.17 :: WordPress® v3.5 :: s2Member® v130207 :: s2Member® Pro v130207
Memory 34.84 MB :: Real Memory 35.25 MB :: Peak Memory 34.93 MB :: Real Peak Memory 35.25 MB
wp.saleskatz.com/?s2member_pro_authnet_notify=1
User-Agent:
array (
‘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’ => ‘289549’,
‘x_trans_id’ => ‘5024219845’,
‘x_method’ => ‘CC’,
‘x_card_type’ => ‘American Express’,
‘x_account_number’ => ‘XXXX3007’,
‘x_first_name’ => ‘R’,
‘x_last_name’ => ‘H’,
‘x_company’ => ”,
‘x_address’ => ”,
‘x_city’ => ”,
‘x_state’ => ”,
‘x_zip’ => ”,
‘x_country’ => ‘US’,
‘x_phone’ => ”,
‘x_fax’ => ”,
‘x_email’ => ‘,
‘x_invoice_num’ => ‘s2-5123fe9be3d6f’,
‘x_description’ => ‘1 Month @ $54.90 / then $24.95 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’ => ‘54.90’,
‘x_tax’ => ‘0.00’,
‘x_duty’ => ‘0.00’,
‘x_freight’ => ‘0.00’,
‘x_tax_exempt’ => ‘FALSE’,
‘x_po_num’ => ”,
‘x_MD5_Hash’ => ‘D6F17BAB4F1AB091C7CB93C8B9124AEE’,
‘x_cvv2_resp_code’ => ‘M’,
‘x_cavv_response’ => ”,
‘x_test_request’ => ‘false’,
‘s2_initial_payment’ => ‘1’,
‘s2_invoice’ => ‘2’,
‘s2_custom’ => ‘wp.saleskatz.com’,
‘s2member_log’ =>
array (
0 => ‘IPN received on: Tue Feb 19, 2013 10:37:17 pm UTC’,
1 => ‘s2Member POST vars verified with Authorize.Net®.’,
2 => ‘Ignoring this IPN. The transaction does NOT require any action on the part of s2Member.’,
),
)

Then two minutes later, we get the following two log messages, in paypal-ipn.log and authnet-api.log respectively

PHP v5.3.2-1ubuntu4.17 :: WordPress® v3.5 :: s2Member® v130207 :: s2Member® Pro v130207
Memory 41.91 MB :: Real Memory 42.75 MB :: Peak Memory 42.04 MB :: Real Peak Memory 42.75 MB
wp.saleskatz.com/?s2member_paypal_notify=1&s2member_paypal_proxy=authnet&s2member_paypal_proxy_use=pro-emails,subscr-signup-as-subscr-payment&s2member_paypal_proxy_verification=481d60f981ce2aa2b41dbb96494a8252&s2member_paypal_proxy_return_url=
User-Agent: WordPress/3.5; https://wp.saleskatz.com
array (
‘txn_type’ => ‘subscr_signup’,
‘subscr_id’ => ‘15971932’,
‘custom’ => ‘wp.saleskatz.com’,
‘txn_id’ => ‘5024219845’,
‘period1’ => ‘1 M’,
‘period3’ => ‘1 M’,
‘mc_amount1’ => ‘54.90’,
‘mc_amount3’ => ‘24.95’,
‘mc_gross’ => ‘54.90’,
‘mc_currency’ => ‘USD’,
‘tax’ => ‘0.00’,
‘recurring’ => ‘24.95’,
‘payer_email’ => ”,
‘first_name’ => ‘R’,
‘last_name’ => ‘H’,
‘option_name1’ => ‘Originating Domain’,
‘option_selection1’ => ‘wp.saleskatz.com’,
‘option_name2’ => ‘Customer IP Address’,
‘option_selection2’ => ”,
‘item_name’ => ‘1 Month @ $54.90 / then $24.95 USD / Monthly ( recurring charge, for ongoing access )’,
‘item_number’ => ‘2’,
‘proxy_verified’ => ‘authnet’,
‘s2member_log’ =>
array (
0 => ‘IPN received on: Tue Feb 19, 2013 10:39:29 pm UTC’,
1 => ‘s2Member POST vars verified with a Proxy Key’,
2 => ‘s2Member originating domain ( `$_SERVER[“HTTP_HOST”]` ) validated.’,
3 => ‘s2Member `txn_type` identified as ( `web_accept|subscr_signup` ).’,
4 => ‘s2Member `txn_type` identified as ( `web_accept|subscr_signup` ) w/o update vars.’,
5 => ‘Signup Confirmation Email sent to: “Rob Heinen” .’,
6 => ‘User exists. Handling `payment` for Subscription via ( `subscr-signup-as-subscr-payment` ).’,
7 => ‘Storing IPN signup vars now. These are associated with a User\’s account record; for future reference.’,
),
‘subscr_gateway’ => ‘authnet’,
‘eotper’ => NULL,
‘ccaps’ => NULL,
‘level’ => ‘2’,
‘ip’ => ‘75.187.215.179’,
‘initial_term’ => ‘1 M’,
‘initial’ => ‘54.90’,
‘regular’ => ‘24.95’,
‘regular_term’ => ‘1 M’,
‘s2member_paypal_proxy’ => ‘authnet’,
‘s2member_paypal_proxy_use’ => ‘pro-emails,subscr-signup-as-subscr-payment’,
‘s2member_paypal_proxy_verification’ => ‘481d60f981ce2aa2b41dbb96494a8252’,
)

Memory 37.71 MB :: Real Memory 38.00 MB :: Peak Memory 37.81 MB :: Real Peak Memory 38.00 MB
wp.saleskatz.com/monthly-plan/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17
——– Input vars: ( Tue Feb 19, 2013 10:37:17 pm UTC ) ——–
array (
‘x_method’ => ‘create’,
‘x_email’ => ‘soccerrob@yahoo.com’,
‘x_first_name’ => ‘R’,
‘x_last_name’ => ‘H’,
‘x_customer_ip’ => ”,
‘x_invoice_num’ => ‘s2-5123fe9be3d6f’,
‘x_description’ => ‘1 Month @ $54.90 / then $24.95 USD / Monthly ( recurring charge, for ongoing access ) ((1363948635:1 M:1 M~wp.saleskatz.com~2))’,
‘x_amount’ => ‘24.95’,
‘x_start_date’ => ‘2013-03-22’,
‘x_unit’ => ‘months’,
‘x_length’ => 1,
‘x_total_occurrences’ => ‘9999’,
‘x_card_num’ => ‘***********3007’,
‘x_exp_date’ => ”,
‘x_card_code’ => ”,
‘x_address’ => ”,
‘x_city’ => ”,
‘x_state’ => ”,
‘x_country’ => ‘US’,
‘x_zip’ => ”,
‘x_login’ => ‘9dF2C7uk’,
‘x_tran_key’ => ‘8JebZt38e4w2Kk7w’,
)
——– Output string/vars: ( Tue Feb 19, 2013 10:39:28 pm UTC ) ——–
s2-5123fe9be3d6fOk

I00001

Successful.15971932
array (
‘response_reason_code’ => ‘I00001’,
‘response_code’ => ‘I00001’,
‘response_reason_text’ => ‘Successful.’,
‘response_text’ => ‘Successful.’,
‘subscription_id’ => ‘15971932’,
)

Then back on the authnet-ipn.log , this is the final message we get 10 minutes later

PHP v5.3.2-1ubuntu4.17 :: WordPress® v3.5 :: s2Member® v130207 :: s2Member® Pro v130207
Memory 34.82 MB :: Real Memory 35.00 MB :: Peak Memory 34.88 MB :: Real Peak Memory 35.00 MB
wp.saleskatz.com/?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 ex
tension (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\’ => \’P\’,
\’x_auth_code\’ => \’289549\’,
\’x_trans_id\’ => \’5024219845\’,
\’x_method\’ => \’CC\’,
\’x_card_type\’ => \’American Express\’,
\’x_account_number\’ => \’XXXX3007\’,
\’x_first_name\’ => \’\’,
\’x_last_name\’ => \’\’,
\’x_company\’ => \’\’,
\’x_address\’ => \’\’,
\’x_city\’ => \’\’,
\’x_state\’ => \’\’,
\’x_zip\’ => \\’,
\’x_country\’ => \’\’,
\’x_phone\’ => \’\’,
\’x_fax\’ => \’\’,
\’x_email\’ => \’\’,
\’x_invoice_num\’ => \’s2-5123fe9be3d6f\’,
\’x_description\’ => \’\’,
\’x_type\’ => \’void\’,
\’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\’ => \’0.00\’,
\’x_tax\’ => \’0.00\’,
\’x_duty\’ => \’0.00\’,
\’x_freight\’ => \’0.00\’,
\’x_tax_exempt\’ => \’FALSE\’,
\’x_po_num\’ => \’\’,
\’x_MD5_Hash\’ => \’FC171ED8EAC679CB8D74B84A31CF93A3\’,
\’x_cvv2_resp_code\’ => \’\’,
\’x_cavv_response\’ => \’\’,
\’x_test_request\’ => \’false\’,
)’,
),
)

Thanks for the data, Rich.

Regarding the logs after 2 minutes, it seems it’s Auth.Net taking that long. From the authnet-api.log entry:

——– Input vars: ( Tue Feb 19, 2013 10:37:17 pm UTC ) ——–

——– Output string/vars: ( Tue Feb 19, 2013 10:39:28 pm UTC ) ——–

Then it gets forwarded to the PayPal routines in s2Member using the proxy key, which is why you got that entry in the paypal-ipn.log.

Can the Auth.Net support guy see in his system what communications happened for the transaction, and their times? I’d like to confirm if Auth.Net was the one contacting s2Member 2 minutes later.

It maybe important to note that we thought we would only use authorize.net (we don’t offer paypal as an option), so we do NOT have a paypal account.

You don’t need a PayPal account for this to work, they’re just the original PayPal routines in s2Member which were then used for the gateways added later. It should have a more generic name, but it was named like that originally and we just never renamed the whole thing after adding gateways.

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 ex
tension (usually) does NOT support SSL connections on a Windows® server.’,

Did you double check that your Auth.Net settings are all correct? [hilite path]Dashboard -› s2Member® -› Authorize.Net® Options[/hilite]

Could you check your server using this? Knowledge Base » Common Troubleshooting Tips » Server

By the way, are you in sandbox mode, or doing live transactions?

We don’t seem to have the options to view log files from the dashboard.

The interface was added in a recent release. If you update s2Member to the latest release, you should see the new logs entry in the navigation. [hilite path]Dashboard -› s2Member® -› Log Files (Debug)[/hilite]

By the way, are you in sandbox mode, or doing live transactions?

We spoke to authorize.net 3 times and submitted an e-ticket. The response so far is that nothing on the authorize.net server is causing the delay. We also created a manual ARB transaction on the authorize.net and it responded with a second or 2. The supervisor at authorize.net indicated that if they were having this problem on all ARB transactions, they would have many phone calls and they are not.

We are running these as live transactions.

The initial transaction is fine. The second transaction is the ARBCreate and this is where the hangup is. Could there be problem with our settings/or the call itself?

We need to have this live and working (2 minute delay in processing cannot be considered working) we would like a refund and then we’ll move on and try another solution

Response received from Authorize.net

Do you have any ideas?

Hi Rich,
In regards to payment gateway ID 1108118, we spoke earlier about the amount of time for the response back on transactions /recurring subscriptions that you?re creating.
I was unable to get any sort of a log to forward to you but our production specialists did state that there is no possible way that it would be taking that long for US to send the response back. They suggested that you work with your developer and/or site provider to find the cause of that delay as it?s not something on our end.
Thank you for your time & have a great Thursday!

Thank you for contacting Customer Support.

Regards,

Shawna T
Authorize.Net Customer Support

Here is a sample of what we are seeing on the transactions:

Authorize.net payment transaction sent at 4:32:01
Response from authorize.net received at 4:32:01
Sent ARB to authorize at 4:32:01
Added subscription in authorize.net 4:32:02

Received the return form ARB 4:34:13
Added Member 4:34

The problem is clearly AFTER the subscription is added in authorize.net ARB. Is there a setting or something else that could delay s2member from receiving the success transaction? Is there a possible setting we could have wrong?

Additional information provided by authorize.net support:

Greetigs Richard,

Thanks for your inquiry regarding ARB API requests to create ARB Subscriptions taking 2 minutes to take place.

This means the ARB Subscription was created within 10 seconds and there’s a delay getting the response back to your website. If the subscription didn’t get created within 10 seconds, we’d relay a timeout. The delay with the response getting to you is going to be related to the possible functions your website is performing as it gets back the ARB Creating request response. There’s nothing on our end that can be changed to reduce this time on our end. This will be something your web developer will have to investigate within your website ARB script.

If the information provided above satisfies your needs, please close this ticket. Otherwise, please send me a reply message with your follow-up questions so I can further assist you. For your convenience the Authorize.Net Knowledge Base, located at http://www.authorize.net/help, is available 24×7.

Regards,

Cameron H
Authorize.Net

Thanks for all the extra info, Rich.

I’m forwarding this to Jason to look into. Could you please submit your site’s info so he can investigate it? Thanks! s2Member® » Private Contact Form

We were able to solve the problem. In working on another issue we found that cURL was installed in a standalone mode on the server. Once we enabled it in PHP the problem was solved.

Oh, that’s great! Thanks for the update. I’m very glad you solved it. :)

I’ll tell Jason too, maybe our Server Check tool can have a way to tell what mode it’s in and warn based on that too… Could you tell me what mode it was in and which you changed it to now?

I really don’t know the exact details, our programmer made the change. He explained it as the cURL was installed on the server in a “standalone” mode. He needed to turn cURL on in the PHP installation.

I hope this makes some sense.

Thanks!