Add 'captureOnlyTransaction' type about omnipay-authorizenet HOT 11 CLOSED

Hi Jason (@judgej), (and also @samlitowitz)

captureOnlyTransaction and priorAuthCaptureTransaction are two very different beasts.

priorAuthCaptureTransaction is just an instruction to Authorize.Net to say "Hey, you remember that transaction I sent you for authorization earlier? The one with transaction ID XXXXXXXXXXX? Let's go ahead and move that ahead to clearing and settlement."

captureOnlyTransaction is telling Authorize.Net "Hey look, I got authorization for this transaction somewhere else (like another gateway, or by voice auth or something). I want you to take care of the settlement for me. So, since you've never seen this transaction on your system before, I'm going to give you all of the transaction information so you can pass it all along to clearing and settlement. That includes the card number and expiration date of course, as well as any other data I might have used in the authorization like tips or employee ID. And of course, I'll send you the auth code so when you send this for clearing you can pass that auth code along to the issuer so they can see that they previously authed this."

If you intend to auth first and capture later, the proper way on Authorize.Net is to do an authOnlyTransaction followed later by a priorAuthCaptureTransaction referencing the original authorization request's transaction ID. The captureOnlyTransaction method is only for those scenarios where the original authorization comes from outside the Authorize.Net system (like from another gateway).

It would be technically possible to do a authOnlyTransaction at Authorize.Net followed later by a captureOnlyTransaction using the same information from the first request and passing back the auth code from the first request. That's an extraordinarily bad idea, though, for a few reasons (Authorize.Net doesn't know the second request has anything to do with the first, so reporting is all messed up since you'll see two separate entries for each transaction, plus there's a greater risk of double charging someone since the original authorization remains "active" in the Authorize.Net system, so can be manually captured in the interface or with a priorAuthCaptureTransaction at any time). So, don't do that. If you're going to auth and capture on the Authorize.Net system, always do an authOnlyTransaction followed later by a priorAuthCaptureTransaction referencing the original authorization request's transaction ID.

You're right that the Capture Funds Authorized Through Another Channel documentation is inconsistent with the sample. It's the documentation that's messed up, though (not the sample), and the "Request" tab should definitely document the need for payment information (like CC number).

During my time at Authorize.Net, the doc team had touched literally all parts of the documentation, improving it massively in a lot of areas. I know this particular section had been touched at one point as well, so I don't know if the missing info is a reversion, or just slipped through the cracks. I'll contact my former colleagues (I no longer work there) and let them know to bulk it up.

In the meantime, refer to the Charge a Credit Card documentation. The allowed/required fields for captureOnlyTransaction should be identical to that entry except with captureOnlyTransaction you send the transactionType as captureOnlyTransaction instead of authCaptureTransaction, and you're required to send an authCode in after the payment block of information.

from omnipay-authorizenet.

Do you have any further details of what you believe is missing?

from omnipay-authorizenet.

Here's the link to their docs. Currently the library is unable to "[c]apture [f]unds [a]uthorized [t]hrough [a]nother [c]hannel".

from omnipay-authorizenet.

Okay, I see. Apart from the transaction type name (captureOnlyTransaction instead of priorAuthCaptureTransaction), it differs from a standard capture by only one field name change: authCode instead of refTransId.

The Capture request uses the transactionReference to map onto the refTransId. Is it worth using the transactionReference for this transaction too, for Omnipay consistency? You may not agree (and I'm not fussed) but just asking in case it makes sense.

from omnipay-authorizenet.

Actually, since I last looked at these two messages some eight months ago, they seemed to have diverged somewhat, with the captureOnlyTransaction now including tips and an employee ID and a few other fields. The docs also includes the CC number in the "try it" data, but I wonder if that is a mistake, since it is not documented in the request data but is in the sample code?

        "transactionRequest": {
            "transactionType": "captureOnlyTransaction",
            "amount": "5",
            "payment": {
                "creditCard": {
                    "cardNumber": "5424000000000015",
                    "expirationDate": "2020-12",
                    "cardCode": "999"
                }
            },
            "authCode": "ROHNFQ"
        }

from omnipay-authorizenet.

Thanks, that's a great explanation - very useful. The main difference here seems to be that in one case Authorize.Net is handling the authorization for you, and in the other the authorization is being done via a different channel and Authorize.Net is just acting as the proxy to pass that on without question.

I'll try to get this PR merged tomorrow.

from omnipay-authorizenet.

@samlitowitz Just tried your latest change on the sandbox. If the authCode is tagged onto the end, then I get this error:

The element 'transactionRequest' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'authCode' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List of possible elements expected: 'employeeId, transactionSettings, userFields, surcharge, merchantDescriptor, subMerchant, tip' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'.

It doesn't like the order. It needs to go immediately after terminalNumber. Doing that, I get this:

The authorization code is invalid.

Which means I've given it a rubbish authCode but it does accept the format of the message. If you move the authCode setting to the AIMAuthorizeRequest then that should fix it. It's just a couple of lines to move, with the base class staying much the same. Great job so far - almost there :-)

The field order is a damn annoying "feature" of Authorize.Net IMO, but we have to play the game :-)

I'm using the JSON format for the API, but it seems to go through the same validation as the XML data format. I suspect the API just converts the JSON to XML internally and carries on as before JSON was supported.

from omnipay-authorizenet.

Just to note: There is no online verification of the value sent as authCode. The Authorize.Net system's not doing some sort of call to the issuer to see if that auth code matches what you got when you authed the transaction on another system.

The only verification that Authorize.Net does is to verify that the string you send is more than 0 characters and not more than 6. If you do send a null string, you get error 12. If you do send more than six characters, you get error 72. Anything else will be accepted and passed with the transaction details for clearing and settlement.

from omnipay-authorizenet.

Ah, thanks. I was sending 'AUTH1234'. Cutting that down to 'AUTH12' and I get this more reassuring message:

This transaction has been approved.

That's a capture-only sent with ALL the auth-only supported fields (names, addresses, custom fields, order numbers, employee, etc). I say "all", but noticed there are a few more now.

from omnipay-authorizenet.

And yes, the order always matters on this XML API. Every element in the request has to match the constraints in the schema, including the order of elements.

from omnipay-authorizenet.

Addressed in PR 94

from omnipay-authorizenet.