Error when issuing refund

1. +++ b/src/Plugin/Commerce/PaymentGateway/AuthorizeNet.php
   @@ -329,15 +329,15 @@ class AuthorizeNet extends OnsitePaymentGatewayBase implements AuthorizeNetInter
   +      'expirationDate' => 'XXXX',
   

   This will break non-sandbox, yes? Can you use the "Is sandbox?" flag to toggle whether to pull expiration date from the $payment_method?

2. +++ b/src/Plugin/Commerce/PaymentGateway/AuthorizeNet.php
   @@ -329,15 +329,15 @@ class AuthorizeNet extends OnsitePaymentGatewayBase implements AuthorizeNetInter
   +    $transaction_request->refTransId = $payment->getRemoteId();
   

   If moving this out of the constructor is to control the order of parameters, I don't think this solution is best. Ordering restrictions should be seamless to the caller of the AuthorizeNet.php class--i.e. can we put ordering logic into the class?

So the API documentation is conflicting.

For the root payment entry

When issuing a credit card refund, the request must include either a full card number and expiration, or previous transId and last 4 digits of the card number. If you don't have the last 4 digits, you can use getTransactionDetails to get the payment object needed to issue a refund.

But for

expirationDate

inside of it

The expiration date should be submitted masked as simply "XXXX"

Also

If moving this out of the constructor is to control the order of parameters, I don't think this solution is best. Ordering restrictions should be seamless to the caller of the AuthorizeNet.php class--i.e. can we put ordering logic into the class?

As painful as it sounds, it seems like there needs to be a serializer class which puts properties where they are expected to belong when a request is fired.

I've updated the SDK to provide property mapping which fixes the refTransId issue. I also added refund tests. Passing XXXX or 1234 didn't matter.

Can you run composer update commerceguys/authnet and see if the latest commits fix refund issues? I'm thinking it might not need changes in the module itself.

I just tried out the latest from commerceguys/authnet and I'm getting this error now:

The 'AnetApi/xml/v1/schema/AnetApiSchema.xsd:expirationDate' element is invalid - The value XX is invalid according to its datatype 'String' - The actual length is less than the MinLength value.

Thanks.

The test code in the SDK is

        $request = $this->xmlRequestFactory->createTransactionRequest();
        $request->setTransactionRequest(new TransactionRequest([
            'transactionType' => TransactionRequest::REFUND,
            'refTransId' => $response->transactionResponse->transId,
            'amount' => 5.00,
        ]));
        $transactionRequest->addPayment(new CreditCard([
            'cardNumber' => 'XXXX1111',
            'expirationDate' => 'XXXX',
        ]));

The module

    $request = new CreateTransactionRequest($this->authnetConfiguration, $this->httpClient);
    $transaction_request = new TransactionRequest([
      'transactionType' => TransactionRequest::REFUND,
      'amount' => $payment->getAmount()->getNumber(),
      'refTransId' => $payment->getRemoteId(),
    ]);
    /** @var \Drupal\commerce_payment\Entity\PaymentMethod $payment_method */
    $payment_method = $payment->getPaymentMethod();
    $transaction_request->addPayment(new CreditCardDataType([
      'cardNumber' => $payment_method->card_number->value,
      'expirationDate' => $payment_method->expiration_month->value . $payment_method->expiration_year->value,
    ]));

From #10 it looks like a string less than four digits was passed. Not sure how, especially if just XX.

Can someone just try manually changing the code to pass XXXX instead of the payment method's expiration information?

Ok, so the error returned from Auth.net is adding the XX for some reason. The actual request was sending an empty expirationDate. I tested with both the actual expiration date, and XXXX and both seemed to work in the Sandbox (which lines up with what mglaman found in #8).

I also found a related bug having to do with the amount refunded. The attached patch for the module fixed things for me.

Sweet! Thanks so much for the find. I want to just see another +1 from other users here then I'll commit. Won't tag a new beta, though, as we'll be rolling Commerce RC1 soon and need a new beta just for that.

Thanks, everyone!