Declined credit cards are still allowed access

[vx0]

We went live with this system tonight and the first thing we are getting is that declined credit cards from authorize.net are still able to get in by re-entering their username and password. I suspect this is related to the fact that the system complains about missing cookies and requires the user and pass to be entered again that I mentioned in another thread.

We are in trouble tonight. I hope someone is the there that can help us.

Mark

[vx0]

Additional information. The user gets a "declined" screen that is only displayed for a second before the "Cookie warning" page displays. The log under Credit Cards shows the transaction status as FAILED. However, when the user re-enters their username and password, FirstSpot allows them access.

I have remote desktop on this machine if someone from PatronSoft tech support wants to remote in and see how we are set up.

[vx0]

Even more info:

The txn.log also shows the transaction declined. However, after further testing, we have found that a user can create a username and password, choose the shopping cart item and be directed to authorize.net. However, even without entering any credit card info at all, they can go straight back to the login page and enter the user/pass they created and are granted access with the plan attributes of the plan attached to the shopping cart item as a legacy plan.

I am not seeing anything obviously wrong, but the configuration of FirstSpot is a bit arcane, so I may be missing something.

[vx0]

"Please select "Self Sign-up for After X Minutes" Plan in Self sign-up Plan if you use the self sign-up function." What does this mean?

I am losing a lot of money right now, so if I sound a bit frantic, that is why.

[alan]

Don't use the legacy plan within Shopping Cart. Use the Shopping Cart items instead.

You might want to setup a seperate testing FirstSpot to get familar with the behavior of the Shopping Cart first before moving the cofiguration live.
_________________
~ Patronsoft Limited ~

[vx0]

After working with this for several hours, I have the following set up:

I am not using a legacy plan in the shopping cart. I have a self-sign plan set up with initial time assign = 0 with no other attributes set. I have a shopping cart plan with "after 3 days". I have the self-sign plan set in the authentication server with self-sign redirect option to shopping cart. The problem now is that after credit cart authentication, the user is not getting the three days.

I was unaware that this was not working before we went live today since we didn't test a failed credit card transaction. I do not have the option to build and run a test environment at this time.

[vx0]

Alan, you can disregard for now. I think I have it working. Minutes have to be blank, not 0. I set the expire date time to last year to disallow the self-sign access before going through the shopping cart.

I will have to submit that with as much as this software costs, and as arcane as the operation and configuration is, the documentation needs to get a whole lot better. I have to say that this has been an extraordinary pain in the butt to get working properly. We lost a significant number of paid subscriptions tonight.

[vx0]

Another question... Is there an automated way to remove users that have never logged in? We have a number of users that created accounts but never completed the shopping cart, thus never logged in that we would like to remove after a certain number of days.

[alan]

You need to create a SQL script for that. Please note the following:

1) The field signuptime records the sign up time.

2) One way to detect whether a username ever logs in is to check the reserved2 (or reserved3) field. Username that never logs in should have both fields as null.

Refer to http://patronsoft.com/forum/viewtopic.php?t=1514 for a guideline to manipulate the default dbf datasource.
_________________
~ Patronsoft Limited ~

[vx0]

Well that is a bit involved. I will just manually delete them in the user manager.