Credit Card Details not getting passed to ActiveMerchant

[Madeindata]

Hi,

I am trying to do some testing with the checkout in dev.

but the CC form details don't seem to be in the active merchant
purchase request, the whole creditcard object seems to be blank? I
have tested on both Eway and Authorize.net. Both are returning error
of no card number?

I manually changed creditcard.rb to have a static creditcard object
and the request worked fine.

Have tested on two different spree installs running v= 0.40.0

Below are Gateway Responses

Authorize.net Gateway Error
--- !ruby/object:ActiveMerchant::Billing::Response
authorization: "0"
avs_result:
code: P
postal_match: Y
street_match: N
message: Postal code matches, but street address not verified.
cvv_result:
code:
message:
fraud_review: false
message: (TESTMODE) Credit card number is required
params:
response_reason_text: (TESTMODE) Credit card number is required.
transaction_id: "0"
response_code: 3
response_reason_code: "33"
avs_result_code: P
card_code: ""
success: false
test: true

Eway Gateway Error
--- !ruby/object:ActiveMerchant::Billing::Response
authorization:
avs_result:
code:
postal_match:
street_match:
message:
cvv_result:
code:
message:
fraud_review:
message: "Error: Invalid credit card provided. Your credit card has
not been billed for this transaction.(Test Gateway)Card Data Sent: "
params:
ewayauthcode:
ewaytrxnerror: "Error: Invalid credit card provided. Your credit
card has not been billed for this transaction.(Test Gateway)Card Data
Sent: " #notice that card data sent is Blank.
ewaytrxnoption1:
ewaytrxnoption2:
ewaytrxnoption3:
ewaytrxnstatus: "False"
ewaytrxnreference:
ewaytrxnnumber: "1010204"
ewayreturnamount: "2999"
success: false
test: true


Am I missing something? it's the stock standard spree checkout

[Ross Ashley]

I've been beating my head against this problem for a week and I'm
getting nowhere. In my case the creditcard object contains all the
stored attributes but the two attributes that don't get written to the
DB, the credit card number and a validation atttribute, are nil. If I
set the number manually from the debugger just before the gateway
authorization, the authorization succeeds.

I just set up a new completely fresh install following the getting
started edge guide, with spree 50.99, rails 3.0.4 and ruby 1.9.2 and the
error through Paypal's Website Payment Pro is the same.

I'm running on a linode slice with Ubuntu 10.04.

This looks like it should work but the order->payment->source never gets
the creditcard number, just the other stored attributes. I still don't
know why. I wish I could see a working system.

[Madeindata]

Kind of good to know I'm not the only one Ross.

What is everyone doing to make the creditcard processing work?

Anyone out there have any examples/advice for 0.40 spree working with
CC processing?

I've built my first shop for a client, now i'm just putting them off
til I can get the money to work.

Thanks

[Laurence Lee]

Are you entering non-digits in your credit card numbers, like dashes?

In my fork of Spree edge, I had to relax the RegEx filter in creditcard.rb's set_last_digits() to allow dashes, instead of just spaces:

  https://github.com/rubyjedi/spree/commit/44d82eaa89764d71485dc9ff70c27fee61983525

Hope this helps.

[Madeindata]

Hi Laurance,

Thanks for your help and suggestion.

I have not been entering anything weird into the form fields, not
spaces or dashes.
Have just been using the test card numbers from the gateway providers

The card number value is not getting sent at all to the gateways, it
is completely blank.

On Feb 16, 10:54 am, Laurence Lee <rubyj...@gmail.com> wrote:
> Are you entering non-digits in your credit card numbers, like dashes?
>
> In my fork of Spree edge, I had to relax the RegEx filter in creditcard.rb's
> set_last_digits() to allow dashes, instead of just spaces:
>

> https://github.com/rubyjedi/spree/commit/44d82eaa89764d71485dc9ff70c2...
>
> Hope this helps.

[Sean Schofield]

Generally we use the Authorize.net CIM gateway so we're not
transmitting the number during the final confirmation step. If you do
not have the CIM gateway enabled you should not be seeing a
confirmation step. Can you verify that? I just wanted to make sure
this is not your problem b/c the credit card number is discarded after
you submit the payment screen (since its not safe to keep it in the
database.)

So the idea is to submit the number to Authorize.net and then chuck
it. If you're somehow seeing the last confirmation screen still this
(and you aren't using CIM) this would most certainly be a problem.
Probably not the case but I wanted to make sure.

Sean Schofield

-------------------------------------------
Rails Dog LLC
2 Wisconsin Circle, Suite 700
Chevy Chase, MD 20815
voice: (301)560-2000
-------------------------------------------

> --
> You received this message because you are subscribed to the Google Groups "Spree" group.
> To post to this group, send email to spree...@googlegroups.com.
> To unsubscribe from this group, send email to spree-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/spree-user?hl=en.
>
>

[Madeindata]

Hi Sean,

Thanks for explaining how it should function.

I'm pretty sure there might be a bug, because using the Eway gateway I
still get the confirm step.

I also have Spree::Config[:auto_capture] set to true - Eway supports
purchase method only (no authorize method).

Here is a link to a quick screen capture of the checkout process:
https://bits-n-pieces.s3.amazonaws.com/Spree-checkout-eway.mov

Thanks again
Dave

On Feb 16, 2:34 pm, Sean Schofield <s...@railsdog.com> wrote:
> Generally we use the Authorize.net CIM gateway so we're not
> transmitting the number during the final confirmation step.  If you do
> not have the CIM gateway enabled you should not be seeing a
> confirmation step.  Can you verify that?  I just wanted to make sure
> this is not your problem b/c the credit card number is discarded after
> you submit the payment screen (since its not safe to keep it in the
> database.)
>
> So the idea is to submit the number to Authorize.net and then chuck
> it.  If you're somehow seeing the last confirmation screen still this
> (and you aren't using CIM) this would most certainly be a problem.
> Probably not the case but I wanted to make sure.
>
> Sean Schofield
>
> -------------------------------------------
> Rails Dog LLC
> 2 Wisconsin Circle, Suite 700
> Chevy Chase, MD 20815
> voice: (301)560-2000
> -------------------------------------------
>

[Ross Ashley]

Yeah, I get the confirmation step as well with both my Moneris gateway
and Website Payments Pro.

That certainly looks like the problem.

[Sean Schofield]

Yes I can confirm the problem on this end now as well. Its hard to
believe its taken this long for it to be noticed but that appears to
be the case. I'm looking at how to fix this now.

Sean Schofield

-------------------------------------------
Rails Dog LLC
2 Wisconsin Circle, Suite 700
Chevy Chase, MD 20815
voice: (301)560-2000
-------------------------------------------

[Sean Schofield]

Fixed in edge.[1] Can someone please verify? If there's sufficient
interest we can back port to a 0-40-stable branch (but likely skip a
formal release since you can reference the git repo in bundler and
0.50.0 is coming up shortly.)

Sean Schofield

[1] https://github.com/spree/spree/commit/048475dcbc711e05dd0369c9c52c7fe1ee702b4b

-------------------------------------------
Rails Dog LLC
2 Wisconsin Circle, Suite 700
Chevy Chase, MD 20815
voice: (301)560-2000
-------------------------------------------

[Ross Ashley]

It works like a charm.

Thanks for your help. I'll be pushing my little Moneris gateway in the
next day or so.

[Madeindata]

Thanks for that Sean,

The payments are now getting processed properly, but I get an error
somewhere later in the update action.

Keep getting this in both test installs:

ActiveRecord::UnknownAttributeError in CheckoutController#update

unknown attribute: next_state

Ross seems to have it working, so i'm not sure what the problem is.

Thanks
Dave

On Feb 17, 9:25 am, Sean Schofield <s...@railsdog.com> wrote:
> Fixed in edge.[1]  Can someone please verify?  If there's sufficient
> interest we can back port to a 0-40-stable branch (but likely skip a
> formal release since you can reference the git repo in bundler and
> 0.50.0 is coming up shortly.)
>
> Sean Schofield
>

> [1]https://github.com/spree/spree/commit/048475dcbc711e05dd0369c9c52c7fe...

>
> -------------------------------------------
> Rails Dog LLC
> 2 Wisconsin Circle, Suite 700
> Chevy Chase, MD 20815
> voice: (301)560-2000
> -------------------------------------------
>

> On Wed, Feb 16, 2011 at 2:04 PM, Sean Schofield <s...@railsdog.com> wrote:
> > Yes I can confirm the problem on this end now as well.  Its hard to
> > believe its taken this long for it to be noticed but that appears to
> > be the case.  I'm looking at how to fix this now.
>
> > Sean Schofield
>
> > -------------------------------------------
> > Rails Dog LLC
> > 2 Wisconsin Circle, Suite 700
> > Chevy Chase, MD 20815
> > voice: (301)560-2000
> > -------------------------------------------
>

[Sean Schofield]

Try using your gateway in just the basic Spree sandbox (in other words
isolate all other customizations, extensions, etc.)

Sean Schofield

-------------------------------------------
Rails Dog LLC
2 Wisconsin Circle, Suite 700
Chevy Chase, MD 20815
voice: (301)560-2000
-------------------------------------------

[Madeindata]

Hi Sean,

I Did a complete fresh install of spree and worked fine

Then I discovered my other custom spree shop was not up to date with
db migrations

I did a rake spree:install:migrations and all working now.

Thanks again for your help
Dave

On Feb 17, 1:35 pm, Sean Schofield <s...@railsdog.com> wrote:
> Try using your gateway in just the basic Spree sandbox (in other words
> isolate all other customizations, extensions, etc.)
>
> Sean Schofield
>
> -------------------------------------------
> Rails Dog LLC
> 2 Wisconsin Circle, Suite 700
> Chevy Chase, MD 20815
> voice: (301)560-2000
> -------------------------------------------
>

[Ewen]

Sean,
+1 for port to 0.40
The site I'm working on had to go live without credit card payment
(check only) as I could not get past this problem. They are getting
rather agitated.
Thanks,
Ewen

On Feb 16, 10:25 pm, Sean Schofield <s...@railsdog.com> wrote:
> Fixed in edge.[1]  Can someone please verify?  If there's sufficient
> interest we can back port to a 0-40-stable branch (but likely skip a
> formal release since you can reference the git repo in bundler and
> 0.50.0 is coming up shortly.)
>
> Sean Schofield
>

> [1]https://github.com/spree/spree/commit/048475dcbc711e05dd0369c9c52c7fe...

>
> -------------------------------------------
> Rails Dog LLC
> 2 Wisconsin Circle, Suite 700
> Chevy Chase, MD 20815
> voice: (301)560-2000
> -------------------------------------------
>
>
>
> On Wed, Feb 16, 2011 at 2:04 PM, Sean Schofield <s...@railsdog.com> wrote:
> > Yes I can confirm the problem on this end now as well.  Its hard to
> > believe its taken this long for it to be noticed but that appears to
> > be the case.  I'm looking at how to fix this now.
>
> > Sean Schofield
>
> > -------------------------------------------
> > Rails Dog LLC
> > 2 Wisconsin Circle, Suite 700
> > Chevy Chase, MD 20815
> > voice: (301)560-2000
> > -------------------------------------------
>

[Sean Schofield]

> +1 for port to 0.40
> The site I'm working on had to go live without credit card payment
> (check only) as I could not get past this problem.  They are getting
> rather agitated.

Done.

http://spreecommerce.com/blog/2011/02/17/spree-0-40-3-released/

[Jon]

Will there be a gem for this fix soon?

[Sean Schofield]

> Will there be a gem for this fix soon?

That's what the release means ... its available as a gem.

http://rubygems.org/gems/spree/versions/0.40.3