Integration and Testing

[dlakein]

We modified our code using authorize.net to allow for one partial payment (one template that handles the initial payment, and another one that handles the second, if necessary). All went well in testing, but now that we're live we can't get the second payment to register. Second payment always returns transaction ID of 0, even though we're sure we set everything to live mode.

Total amount $11.95

First partial payment with a $10 prepaid card goes through, and shows up in the authorize.net merchant account site, and we get the email.

Second payment (amount 1.95) returns response code 1, but transaction ID 0, and never shows up in authorize.net, and no email

Uses AIM and sending an HTTPS form post

The authorize.net merchant account is set to live mode, Transaction version set to 3.1
We set Partial Authorization in the authorize.net settings, but didn't send in the initial form. Seemed to work, since we got a split auth back from the first tranasction, and the documentation says if you enable in the account, don't need to send. We've since tested with sending x_allow_partial_auth="TRUE" as well (in both).
For second transaction, we set x_type=PRIOR_AUTH_CAPTURE, and send x_split_tender_id from the first

Both use https://secure.authorize.net/gateway/transact.dll , same login, real card and address (first is a $10 prepaid, second is a full card), send x_Test_Request="FALSE", (though the second one used to have that twice), x_allow_partial_auth="TRUE"

We had been sending x_version="TRUE", instead of "3.1", but that seemed to work fine for the first transaction.

For the second payment, we send x_split_tender_id with the split tender ID returned from the first transaction (response value 53), and sending the x_Amount = [first transaction response value 54] - [first transaction response value 10]

Any ideas why the second transaction is still returning like a test transaction?

Thanks.

- David

[RaynorC1emen7 · Accepted solution]

http://www.authorize.net/support/AIM_apiupdates.pdf

From Page 1

You can release all held transactions associated with the splitTenderId by sending a
Prior_Auth_Capture request. This type of request is the same as the existing Prior
Authorization and Capture request, except that x_split_tender_id is used instead of
x_trans_id. Once all held transactions are released, the splitTenderId can no longer be
used.  

It shouldn't be PRIOR_AUTH_CAPTURE unless you don't want to capture the final $1.95.

[RaynorC1emen7 · Accepted solution]

http://www.authorize.net/support/AIM_apiupdates.pdf

From Page 1

You can release all held transactions associated with the splitTenderId by sending a
Prior_Auth_Capture request. This type of request is the same as the existing Prior
Authorization and Capture request, except that x_split_tender_id is used instead of
x_trans_id. Once all held transactions are released, the splitTenderId can no longer be
used.  

It shouldn't be PRIOR_AUTH_CAPTURE unless you don't want to capture the final $1.95.

[dlakein]

So to bill the second transaction (with the remaining amount and a separate card etc, and send x_split_tender_id), it should be type AUTH_CAPTURE just like the first?

(since it does need to check the new card and billing address info)

Thanks

[RaynorC1emen7]

That the way I read it.

[dlakein]

That did it!

Makes sense, now that I think about it.