New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Credit card authorization fails after first failed attempt on account #2652

Closed
rterbush opened this Issue Mar 4, 2013 · 11 comments

Comments

Projects
None yet
4 participants
@rterbush
Contributor

rterbush commented Mar 4, 2013

I've written pages on tracking this issue in spree-users...

I'm using 1-3-stable

Attempting to configure a payment method to use the Authorize.Net API at EProcessing Network(EPN). Using non-CIM Authorize.Net gateway.

If a new account is created, one payment can be processed without issue.

Subsequent attempts to process a transaction on the same account fails, Spree redirects back to the payment step with a flash error "Payment could not be processed, please check the details you entered"

I've noted that somewhere, some invalid card info is getting persisted as I have seen it on the confirm page when I force a confirm step. I've also confirmed that on failed attempts, the card number is zero length on the processing end of the transaction.

Huge show stopper here. Please let me know what I need to do to help fix this.

@rterbush

This comment has been minimized.

Show comment
Hide comment
@rterbush

rterbush Mar 6, 2013

Contributor

More info to help recreate this:

Create a new spree store with no added extensions
Remove all payment methods (not known if this is required)
Create a new Authorize.Net payment method (not CIM)
As a user, add items to cart and then checkout.
Create new user account
First payment attempt, use all one number (ie 4x16) this is a bogus number and should fail
First attempt with that number fails
Try entering a real card number or a valid test number like 4111111111111111
That too will fail. No card entered after the first failure will succeed

To prove the problem, create a new user account and on first payment attempt, use a valid number. It will succeed.

Contributor

rterbush commented Mar 6, 2013

More info to help recreate this:

Create a new spree store with no added extensions
Remove all payment methods (not known if this is required)
Create a new Authorize.Net payment method (not CIM)
As a user, add items to cart and then checkout.
Create new user account
First payment attempt, use all one number (ie 4x16) this is a bogus number and should fail
First attempt with that number fails
Try entering a real card number or a valid test number like 4111111111111111
That too will fail. No card entered after the first failure will succeed

To prove the problem, create a new user account and on first payment attempt, use a valid number. It will succeed.

@radar

This comment has been minimized.

Show comment
Hide comment
@radar

radar Mar 6, 2013

Member

@rterbush So I can reproduce this issue, how did you sign up for an Authorize.net account? What were the options that you selected within the form? Card Present?

Member

radar commented Mar 6, 2013

@rterbush So I can reproduce this issue, how did you sign up for an Authorize.net account? What were the options that you selected within the form? Card Present?

@rterbush

This comment has been minimized.

Show comment
Hide comment
@rterbush

rterbush Mar 6, 2013

Contributor

Signed up for AN test account here: https://developer.authorize.net/testaccount/

Chose "card not present".

Note that I have the same behavior against the EPN gateway using AN which is my ultimate goal.

Contributor

rterbush commented Mar 6, 2013

Signed up for AN test account here: https://developer.authorize.net/testaccount/

Chose "card not present".

Note that I have the same behavior against the EPN gateway using AN which is my ultimate goal.

@rterbush

This comment has been minimized.

Show comment
Hide comment
@rterbush

rterbush Mar 6, 2013

Contributor

I'm able to duplicate this behavior using the Bogus gateway. This is apparently related to the other issues I mentioned with Bogus gateway in spree-user.

Same deal. If you enter an invalid card number the first attempt on the account, subsequent attempts will fail.
New account and correct number will successfully authorize payment.

Other hint that I have mentioned in spree-user is that in the confirm screen, if you look at the payment information, the last 4 digits displayed for the card never change after the first attempt.

Contributor

rterbush commented Mar 6, 2013

I'm able to duplicate this behavior using the Bogus gateway. This is apparently related to the other issues I mentioned with Bogus gateway in spree-user.

Same deal. If you enter an invalid card number the first attempt on the account, subsequent attempts will fail.
New account and correct number will successfully authorize payment.

Other hint that I have mentioned in spree-user is that in the confirm screen, if you look at the payment information, the last 4 digits displayed for the card never change after the first attempt.

@radar

This comment has been minimized.

Show comment
Hide comment
@radar

radar Mar 6, 2013

Member

Hi again @rterbush.

This issue is very complex. I've spent an hour and a half on it already today and haven't been able to solve it. My work is in radar/spree@377253b6ac060a63895778bfd49a5df581d88553, the payment_tracking branch.

What I can see are two distinct problems here.

The first problem is that the checkout isn't acknowledging there could be multiple payment attempts for an order. It only sees the first. By removing Spree::Order#payment and Spree::Order#payment_method methods and replacing what they were doing with something better, all payments for an order will be acknowledged during checkout.

The second problem is more... "interesting". When Spree processes payments for an order, it processes them through the registered gateway and then that gateway is supposed to give a response back. If that response is a "successful" response, then everything is fine and we all go home happy. However, if the response is "failed", then a Core::GatewayError exception is raised and the entire transaction is rolled back and aborted, leaving the payment in the state of "checkout", which is wrong. The correct state should be "failed".

This last problem is what I spent the majority of the time looking into and I couldn't solve it at all. It needs to be solved because if a payment fails, we shouldn't redirect people back to the confirm screen, but rather the payment screen again so that they can make another payment. This issue also means that we're not tracking any failed payments in Spree whatsoever. Failed payments are in the "checkout" state, and (again), that's just plain wrong.

Member

radar commented Mar 6, 2013

Hi again @rterbush.

This issue is very complex. I've spent an hour and a half on it already today and haven't been able to solve it. My work is in radar/spree@377253b6ac060a63895778bfd49a5df581d88553, the payment_tracking branch.

What I can see are two distinct problems here.

The first problem is that the checkout isn't acknowledging there could be multiple payment attempts for an order. It only sees the first. By removing Spree::Order#payment and Spree::Order#payment_method methods and replacing what they were doing with something better, all payments for an order will be acknowledged during checkout.

The second problem is more... "interesting". When Spree processes payments for an order, it processes them through the registered gateway and then that gateway is supposed to give a response back. If that response is a "successful" response, then everything is fine and we all go home happy. However, if the response is "failed", then a Core::GatewayError exception is raised and the entire transaction is rolled back and aborted, leaving the payment in the state of "checkout", which is wrong. The correct state should be "failed".

This last problem is what I spent the majority of the time looking into and I couldn't solve it at all. It needs to be solved because if a payment fails, we shouldn't redirect people back to the confirm screen, but rather the payment screen again so that they can make another payment. This issue also means that we're not tracking any failed payments in Spree whatsoever. Failed payments are in the "checkout" state, and (again), that's just plain wrong.

@schof

This comment has been minimized.

Show comment
Hide comment
@schof

schof Mar 6, 2013

Member

Let's start with fixing the second problem which does indeed sound serious. We can write a failing test and work outward from there.

Member

schof commented Mar 6, 2013

Let's start with fixing the second problem which does indeed sound serious. We can write a failing test and work outward from there.

@schof

This comment has been minimized.

Show comment
Hide comment
@schof

schof Mar 6, 2013

Member

@rterbush Do you mind writing us a failing test showing the problem with bogus gateway?

Member

schof commented Mar 6, 2013

@rterbush Do you mind writing us a failing test showing the problem with bogus gateway?

@rterbush

This comment has been minimized.

Show comment
Hide comment
@rterbush

rterbush Mar 6, 2013

Contributor

@schof, I am probably not the most qualified to do this given how green I am. Would be happy to play along with someone to make it a teaching moment, but suspect someone more experienced could make short work of this. I would not know where to start with that task.

Contributor

rterbush commented Mar 6, 2013

@schof, I am probably not the most qualified to do this given how green I am. Would be happy to play along with someone to make it a teaching moment, but suspect someone more experienced could make short work of this. I would not know where to start with that task.

@GeekOnCoffee

This comment has been minimized.

Show comment
Hide comment
@GeekOnCoffee

GeekOnCoffee Mar 6, 2013

Contributor

Randy,

Are you normally available during standard US business hours? You could hop on #spree on irc.freenode.net and Radar or I (GeekOnCoffee) or somebody in the community could walk you through it. There's usually somebody there who could help, but at the moment US business hours are your best bet.

Thanks,
Andrew

On Mar 6, 2013, at 3:53 PM, Randy Terbush notifications@github.com wrote:

@schof, I am probably not the most qualified to do this given how green I am. Would be happy to play along with someone to make it a teaching moment, but suspect someone more experienced could make short work of this. I would not know where to start with that task.


Reply to this email directly or view it on GitHub.

Contributor

GeekOnCoffee commented Mar 6, 2013

Randy,

Are you normally available during standard US business hours? You could hop on #spree on irc.freenode.net and Radar or I (GeekOnCoffee) or somebody in the community could walk you through it. There's usually somebody there who could help, but at the moment US business hours are your best bet.

Thanks,
Andrew

On Mar 6, 2013, at 3:53 PM, Randy Terbush notifications@github.com wrote:

@schof, I am probably not the most qualified to do this given how green I am. Would be happy to play along with someone to make it a teaching moment, but suspect someone more experienced could make short work of this. I would not know where to start with that task.


Reply to this email directly or view it on GitHub.

This was referenced Mar 9, 2013

@radar

This comment has been minimized.

Show comment
Hide comment
@radar

radar Mar 9, 2013

Member

This is also related to #2585.

Member

radar commented Mar 9, 2013

This is also related to #2585.

@radar

This comment has been minimized.

Show comment
Hide comment
@radar

radar Mar 9, 2013

Member

Closing this one in favour of #2616, which I reckon fixes this problem now. Running it over CI.

Member

radar commented Mar 9, 2013

Closing this one in favour of #2616, which I reckon fixes this problem now. Running it over CI.

@radar radar closed this Mar 9, 2013

radar added a commit that referenced this issue Mar 11, 2013

radar added a commit that referenced this issue Mar 11, 2013

jetsgit pushed a commit to jetsgit/spree that referenced this issue Mar 31, 2013

Jerrold Thompson
Maunual patching for issues spree#2616 spree#2570 spree#2678 spree#2585
spree#2652

	modified:   core/app/models/spree/gateway.rb
	modified:   core/app/models/spree/payment.rb
	modified:   core/app/models/spree/payment/processing.rb
	modified:   core/app/models/spree/payment_method.rb
	modified:   core/spec/models/payment_spec.rb

jetsgit pushed a commit to jetsgit/spree that referenced this issue Apr 1, 2013

Jerrold Thompson
Revert "Maunual patching for issues spree#2616 spree#2570 spree#2678 s…
…pree#2585 spree#2652"

This reverts commit 03750ac.

	modified:   core/app/models/spree/gateway.rb
	modified:   core/app/models/spree/payment.rb
	modified:   core/app/models/spree/payment/processing.rb
	modified:   core/app/models/spree/payment_method.rb
	modified:   core/spec/models/payment_spec.rb

alce added a commit to alce/spree that referenced this issue Jun 3, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment