I've got a basic POS solution that works for both CP and CNP accounts, and of course I have separate test account credentials for each.
Using the CNP account, I'm able to submit a transaction as well as refund it without any issues.
When I switch to my CP account, though, I'm able to process just fine, but when I go to refund I end up with a ResponseCode of 1 (successful) when really I'm getting error information back. The error I'm getting is about an invalid market type, similar to what I would get if I tried to process a CP transaction using a CNP account. I'm using the same credentials to run the refund as I am to run the original transaction, though.
Here's a full request and response that I just ran on the test server.
Array ( [x_version] => 3.1 [x_delim_data] => TRUE [x_delim_char] => | [x_url] => FALSE [x_type] => CREDIT [x_method] => CC [x_relay_response] => FALSE [x_login] => xxxxx [x_tran_key] => xxxxx [x_test_request] => 1 [x_encap_char] => [x_trans_id] => 6K773918476061213 [x_card_num] => XXXX7360 [x_amount] => 49.99 [x_exp_date] => 022015 )
Array ( [Version] => 3 [ResponseCode] => 1 [ResponseReasonCode] => 87 [ResponseReasonText] => (TESTMODE) Transactions of this market type cannot be processed on this system. [AuthorizationCode] => 000000 [AVSResultCode] => P [CVV2ResponseCode] => 0 [TransactionID] => [MD5Hash] => [UserReference] => 49.99 [NA1] => CC [NA2] => credit [NA3] => [NA4] => [NA5] => [NA6] => [NA7] => [NA8] => [NA9] => [NA10] => [CardNumber] => [CardType] => [SplitTenderID] => [RequestedAmount] => [ApprovedAmount] => [CardBalance] => [ReservedField0] => [ReservedField1] => [ReservedField2] => [ReservedField3] => [ReservedField4] => [ReservedField5] => [ReservedField6] => [ReservedField7] => [ReservedField8] => [ReservedField9] => [ReservedField10] => [ReservedField11] => CFE1E67336D2DD21DCC1E7A2E7CBF383 [ReservedField12] => [ReservedField13] => [ReservedField14] => [ReservedField15] => [ReservedField16] => [ReservedField17] => [ReservedField18] => [ReservedField19] => [ReservedField20] => [ReservedField21] => [ReservedField22] => [ReservedField23] => [ReservedField24] => [ReservedField25] => [ReservedField26] => [ReservedField27] => [MerchantDefinedField0] => [MerchantDefinedField1] => [MerchantDefinedField2] => [MerchantDefinedField3] => [MerchantDefinedField4] => [MerchantDefinedField5] => [MerchantDefinedField6] => [MerchantDefinedField7] => [MerchantDefinedField8] => [MerchantDefinedField9] => [MerchantDefinedField10] => [MerchantDefinedField11] => [MerchantDefinedField12] => [MerchantDefinedField13] => [MerchantDefinedField14] => FALSE )
The documentation shows a response code of 1 means approval, and that's what I've always experienced up until this.
So I'm confused about 2 things: why am I getting this error to begin with, and also, why am I getting a good response code when it's failing?
Any information on what I'm doing wrong here would be greatly appreciated. Thanks!
09-16-2012 02:37 PM - edited 09-16-2012 02:40 PM
I don't think you can just submit a refund like a CNP account. That why it is response like it is a CNP, 3 is the response code for error.
You still need to pass the min CP requirement as stated in Chapter 3 Submitting Transactions.
At page 16 of the pdf. the transaction id need to be in x_ref_trans_id
09-16-2012 04:20 PM
The Card Present guide shows a CREDIT transaction just like the CNP documentation shows.
I did realize that I was leaving out the additional required fields for CP calls. Thanks for reminding me about that.
Now that I have those added back in I'm getting an error that I'm submitting an invalid credit card number, but I'm sending it the way the documentation shows it will accept it, which is the same way I send it for CNP accounts and it works fine. Here's a sample of the request I just ran...
Array ( [x_version] => 3.1 [x_delim_data] => TRUE [x_delim_char] => | [x_url] => FALSE [x_type] => CREDIT [x_method] => CC [x_relay_response] => FALSE [x_login] => xxxxx [x_tran_key] => xxxxx [x_test_request] => 1 [x_encap_char] => [x_trans_id] => 6K773918476061213 [x_card_num] => XXXX7360 [x_amount] => 49.99 [x_exp_date] => 022015 [x_cpversion] => 1.0 [x_market_type] => 2 [x_device_type] => 5 [x_response_format] => 1 [x_track1] => [x_track2] => [x_customer_ip] => 72.135.111.9 [x_description] => Order # )
I do see in the documentation on page 18 where it's explaining the CREDIT transaction type that it shows you have to send x_ref_trans_id, however, that's the only place it shows that. Everywhere else that I see still refers to x_trans_id.
That said, I did try x_ref_trans_id, but I'm getting the same error about an invalid credit card number.
The Issuing Credits Guide specifically shows the format I'm sending, and again, that format works fine when I'm testing against a CNP account.
I'm closer now...thanks for that...but any other info I can get on what's happening now would be greatly appreciated. Thanks!
09-16-2012 05:17 PM
I tried removing the X's from the beginning of the card number value, too, so I wound up sending this:
Array ( [x_version] => 3.1 [x_delim_data] => TRUE [x_delim_char] => | [x_url] => FALSE [x_type] => CREDIT [x_method] => CC [x_relay_response] => FALSE [x_login] => xxxxx [x_tran_key] => xxxxx [x_test_request] => 1 [x_encap_char] => [x_trans_id] => 6K773918476061213 [x_card_num] => 7360 [x_amount] => 49.99 [x_exp_date] => 022015 [x_cpversion] => 1.0 [x_market_type] => 2 [x_device_type] => 5 [x_response_format] => 1 [x_track1] => [x_track2] => [x_customer_ip] => 72.135.111.9 [x_description] => Order # )
I'm still getting the same error, though, that my credit card number is invalid.
09-16-2012 05:34 PM
Try removing the track1 and track2.
Also, I think the transaction id is numeric. And I think the doucmentation is wrong when they print x_trans_id. It should be the x_ref_trans_id for card present.
09-16-2012 05:35 PM
Hmmm...after digging a little deeper I'm discovering that I can't get test refunds to work on either CNP or CP unless I send the full credit card number. I didn't notice it before because I was actually hard-coding a bogus credit card number that was being used for testing within my scripts. I thought I had removed that, but I was wrong, and it was overriding the values I was sending through my software.
That said, now I'm stuck with both of them. The only way it seems to be working for me is if I send the entire credit card number, but the documentation specifically says I shouldn't have to do that, and that would cause me to store the full credit card number at the time the original transaction takes place, which I don't want to do, of course.
Here's the latest one I tried using a CNP account...
Array ( [x_version] => 3.1 [x_delim_data] => TRUE [x_delim_char] => | [x_url] => FALSE [x_type] => CREDIT [x_method] => CC [x_relay_response] => FALSE [x_login] => xxx [x_tran_key] => xxx [x_test_request] => 1 [x_encap_char] => [x_trans_id] => 0 [x_card_num] => XXXX7360 [x_amount] => 29.99 [x_exp_date] => 022015 )
[ResponseCode] => 3 [ResponseSubcode] => 1 [ResponseReasonCode] => 6 [ResponseReasonText] => (TESTMODE) The credit card number is invalid. [ApprovalCode] => 000000 [AVSResultCode] => P [TransactionID] => 0
But then I do the same thing with the full cc number and it works fine...
Array ( [x_version] => 3.1 [x_delim_data] => TRUE [x_delim_char] => | [x_url] => FALSE [x_type] => CREDIT [x_method] => CC [x_relay_response] => FALSE [x_login] => xxx [x_tran_key] => xxx [x_test_request] => 1 [x_encap_char] => [x_trans_id] => 0 [x_card_num] => 4356803931287360 [x_amount] => 29.99 [x_exp_date] => 022015 )
[ResponseCode] => 1 [ResponseSubcode] => 1 [ResponseReasonCode] => 1 [ResponseReasonText] => (TESTMODE) This transaction has been approved. [ApprovalCode] => 000000 [AVSResultCode] => P [TransactionID] => 0
Is this expected behavior in test mode??
09-16-2012 06:48 PM
I'm starting to think maybe the sandbox just doesn't work well with refunds because of how all of the transaction ID's returned are 0..??
If I send a full credit card number, regardless of whether or not it matches the original transaction's card number, I get an approval back. I'm wondering, though, if that's actually just submitting a non-referenced credit as oppose to actually refunding the original transaction..??
Seems like maybe the test server can't handle the 0 as the transaction ID for a refund, so instead it reverts to the non-referenced credit, but in that case it can't accept the partial credit card number so it fails with the error I'm getting..??
Again, this is an assumption as I'm still pretty confused at what's going on here. I'm logged into my test merchant account web panel now, but I'm actually not seeing the transactions show up in here. It's a brand new test account that I just created, ran a sale, then refunded that sale (or possibly just did a non-referenced credit) and now I'm looking at the reports in the control panel but nothing is showing up there.
09-16-2012 10:01 PM
For test account. Turn the test mode off. When it is on, it won't get any transactionID, all it does it validation check. When the testmode it off, it will simulate a real transaction and you can see the transaction in the test merchant account.
It make sense, because the ref transactionID is 0, it is assume it a unlinked credit, which required full credit card number.
09-17-2012 04:19 AM
I'm a little bit confused. When I first created the new test account it was NOT set to test mode in the account, but I was sending x_test_request as true. I tried turning ON test mode in the actual account, but I'm still sending x_test_request as true, so I didn't really see anything different happening that way.
Are you telling me to turn test mode in the account off as well as sending x_test_request as false? If so, would I still hit the test server API endpoint or would I hit the live one? My library is currently setup to use test/live based on the value for x_test_request so I'll have to adjust that, which is fine, but I just want to make sure I understand what you're saying before I start messing with that.
09-17-2012 03:14 PM
Ah, I think I got it. Still hitting the test server endpoint but making sure test mode is off everywhere...now I'm getting an actual ID back. Gonna try refunding this and see what happens. Be back shortly.
09-17-2012 03:21 PM