The only other thing (issue?) I noticed is that the the response is
built with :authorization => @response[:pn_ref] but according to the
XMLPay API (page 38) the AuthCode entity contains the actual
authorization code. For now I'm snagging that from the response
params, but I thought I'd at least bring it up here.
Is this worthy of submitting a patch?
-Russ-
The reason that we return the PN Ref as the authorization is because
that is what is required as a reference when capturing, voiding,
crediting, etc. The actual authcode doesn't serve any later purpose.
I just added the ability to use a :user option, which is basically
what you did, but the reverse. So, by default, the gateway will use
the :login for both the Vendor and User, unless you specifically
override it with the :user option.
--
Cody Fauser
http://shopify.com - e-commerce done right
http://www.codyfauser.com - blog
http://www.oreilly.com/catalog/rjsrails - RJS Templates for Rails
Thanks for the clarification regarding PNRef. I think my primary point
of confusion was that when the response object was returned, and
success was false, there was still an authorization value where I had
expected it to be nil. I'll sort out our requirements with our
accounting department and adjust my code as needed.
Appreciate the quick response and the release of ActiveMerchant to the
Rails community!
-Russ-
On May 7, 7:32 pm, "Cody Fauser" <codyfau...@gmail.com> wrote:
> Russ,
>
> The reason that we return the PN Ref as the authorization is because
> that is what is required as a reference when capturing, voiding,
> crediting, etc. The actual authcode doesn't serve any later purpose.
>
> I just added the ability to use a :user option, which is basically
> what you did, but the reverse. So, by default, the gateway will use
> the :login for both the Vendor and User, unless you specifically
> override it with the :user option.
>