Integration and Testing

[rkieru]

The project I am working on does not store any credit card details locally. For all of their transactions they simply store details returned by Authorize.net: Key, ID, Amount.  I have been tasked with integrating a refund capability into their store (PHP).

By all accounts I should be able to do this as long as the transactions are less than 120 days old:

https://community.developer.authorize.net/t5/Integration-and-Testing/Refund-without-credit-card-info...

The problem I am running into is that to refund a transaction I need to provide the refundTransaction() function with the last 4 digits of the credit card, and the credit card expiration date.  The former is not a problem; GetTransactionDetailsRequest() let's me pull a masked credit card number with the last 4 digits exposed.

But the expiration date is entirely masked and when I try to use that value for the refund I get an error that the card has expired.

Is there any way to obtain the unmasked value? Or a way to process the refund in a manner that does not require this information?

[RichardH Administrator]

Hello @rkieru

A refund currently requires the masked card number to successfully process a refund.  If you first use getTransactionDetails with the transaction ID, the payment object will include the information you need.  Then simply submit the transaction id and masked card details.

Richard

[rkieru]

@RichardH - I believe that is what I am currently doing.  My code currently functions in the followin steps:

(1) Pull up the Transaction details via getTransactionDetails with the ID from the initial transaction.

(2) Store the status, amount charged, card number (partial mask) and expiration date (full mask) into a an array.

(3) Pass that information along with the Transaction ID and amount to refund to refundTransaction()

The end result is that the masked expiration date causes the attempt to fail; the card is considered expired.  If I input any valid expiration date (ex. 1218) it processes successfully.  I am currently testing this in a sandbox environment using testing numbers (Visa: 4111111111111111) and am not sure if that might be a factor in why I'm getting a failed attempt.

[RichardH Administrator]

@rkieru can you please show a sample request and response?  You should not including card details in the refund request.  See the API Live console example here: https://developer.authorize.net/api/reference/#payment-transactions-refund-a-transaction

[rkieru]

@RichardH I have uploaded the relevant code to the following location:

https://codeshare.io/5NgYjJ

So in the sample code we have Sandbox Transaction ID #60107753969.  The getRefundDetails() function would return something like the following:

[status] => settledSuccessfully
[amount] => 45.32
[card] => XXXX1111
[exp] => XXXX

That information is then sent to refundTransaction() so that setCardNumber() and setExpirationDate() have the necessary information.  I grab 'status' and 'amount' for other verification purposes (Like checking the transaction is valid, or that the amount we're refunding doesn't exceed the original transaction amount).

When the Expiration Date is XXXX I get the following output:

Transaction Failed 
Error code : 8 
Error message : The credit card has expired.

But if I set the Expiration Date to 1218 I get a different result:

Transaction Response code : 1 
Refund SUCCESS: 60111190246 
Code : 1 
Description : This transaction has been approved.

Which triggers a merchant email receipt to the email associated to my devleoper account letting me know that the transaction was processed.

========= ORDER INFORMATION =========
Invoice : 
Description : Goods or Services
Amount : 2.23 (USD)
Payment Method: Visa xxxx1111
Transaction Type: Credit

============== Line Items ==============

============== RESULTS ==============
Response : This transaction has been approved.
Auth Code : 
Transaction ID : 60111190246

[RichardH Administrator]

Hmmm.... (scratchhead)

I'll need to check on this, but it may be until Monday before I've got an answer.

Richard

[rkieru]

I wanted to follow up on this as I think I may have discovered the problem.

When this project was first testing its transactions, a CVV was not required as part of the checkout process.  Since a refund needs to pull from a settled transaction I was testing it against previously-settled items, and I wonder if they weren't transactions without a CVV to test against.

Yesterday I created another sandbox transaction and waited until I received the Settled Transactions e-mail (today).  When I first attempted to run my two refund functions I received an error that a Duplicate Transaction was detected.

Re-testing it a minute later and I got the expected results:

Transaction Response code : 1 Refund
SUCCESS: 60111300279
Code : 1
Description : This transaction has been approved.

I'm going to continue testing to figure out what might have caused the duplicate notice but right now I'm operating under the assumption that the core problem was a lack of a CVV stored under the Authorize.net details.