academe / omnipay-authorizenetapi

Omnipay 3.x implementation of Authorize.Net API
MIT License
14 stars 11 forks source link

Transaction ID not populating #12

Open jeffsta9 opened 5 years ago

jeffsta9 commented 5 years ago

I'm using a sandbox acct in auth.net and sending a customerId, like so...

$response = $gateway->purchase([ ... 'transactionId' => '12345', 'customerType' => \Academe\AuthorizeNet\Request\Model\Customer::CUSTOMER_TYPE_INDIVIDUAL, 'opaqueDataDescriptor' => $opaqueDataDescriptor, 'opaqueDataValue' => $opaqueDataValue, ... ])->send();

...but the value transactionId is not populating in auth.net in the transaction details (neither is the customerType value). Is this a known issue or is there anything I am missing?

Any assistance is appreciated :)

judgej commented 5 years ago

It should be working. The transactionId is sent as the refId to the gateway. What the gateway calls "Transaction ID" is what Omnipay calls the transactionReference, generated by the gateway and not the application.

Do you have any further details that would help me reproduce this issue? I assume you are using the AJAX front end to get the opaque data?

judgej commented 5 years ago

@jeffster9 did you get an email linked to this issue from Vlad Lesovskiy at github with the text:

Hello, Thanks for your feedback! We review this issue and give you the answer

I got one and have no idea why.

jeffsta9 commented 5 years ago

Yes, I am using AcceptUI.js within a Vue app. All the data is being sent as expected from the Vue app to the Symfony API. However... | The transactionId is sent as the refId to the gateway ...I may have misunderstood what I should be seeing in Auth.net. I'll have another look this evening.

judgej commented 5 years ago

In the Omnipay world:

So both point to the same transaction, but are IDs owned by different systems.

Now, every gateway gives these things different names, but the idea of Omnipay is to normalise them for your merchant application.

That's a bit of background, and does not discount any bugs you may have possibly found. We just need something that is reproducable.

jeffsta9 commented 5 years ago

So, I looked

The request:

'request' => 
  Omnipay\AuthorizeNetApi\Message\PurchaseRequest::__set_state(array(
     'endpointSandbox' => 'https://apitest.authorize.net/xml/v1/request.api',
     'endpointLive' => 'https://api.authorize.net/xml/v1/request.api',
     'parameters' => 
    Symfony\Component\HttpFoundation\ParameterBag::__set_state(array(
       'parameters' => 
      array (
        'authName' => '.....',
        'transactionKey' => '.....',
        'mobileDeviceId' => NULL,
        'refId' => NULL,
        'testMode' => true,
        'signatureKey' => NULL,
        'disableWebhookSignature' => false,
        'amount' => '140',
        'currency' => 'USD',
        'customerId' => '12345',
        'customerType' => 'individual',
        'transactionId' => 962058365,
        'description' => 'payment for inv #40',
        'opaqueDataDescriptor' => 'COMMON.ACCEPT.INAPP.PAYMENT',
        'opaqueDataValue' => 'eyJjb2RlIjoiN...',
      )
    )),
    ...
))

The Response:

'transactionResponse' => Academe\AuthorizeNet\Response\Model\TransactionResponse::__set_state(array(
   'responseCode' => '1',
   'rawResponseCode' => NULL,
   'authCode' => 'K6GP9X',
   'avsResultCode' => 'Y',
   'cvvResultCode' => 'P',
   'cavvResultCode' => '2',
   'transId' => '60120875895',
   'refTransID' => NULL,
   'transHash' => '',
   'testRequest' => '0',
   'accountNumber' => 'XXXX0027',
   'entryMode' => NULL,
   'accountType' => 'Visa',
   'splitTenderId' => NULL,
   'prePaidCard' => NULL,
   'transactionMessages' => 
  Academe\AuthorizeNet\Response\Collections\TransactionMessages::__set_state(array(
     'items' => 
    array (
      0 => 
      Academe\AuthorizeNet\Response\Model\TransactionMessage::__set_state(array(
         'code' => '1',
         'text' => 'This transaction has been approved.',
         'objectName' => NULL,
         'objectNameSuffix' => '',
         'data' => 
        array (
          'code' => '1',
          'description' => 'This transaction has been approved.',
        ),
      )),
    ),
     'objectName' => NULL,
     'objectNameSuffix' => '',
     'data' => 
    array (
      0 => 
      array (
        'code' => '1',
        'description' => 'This transaction has been approved.',
      ),
    ),
  )),
   'errors' => NULL,
   'splitTenderPayments' => NULL,
   'userFields' => NULL,
   'shipTo' => NULL,
   'secureAcceptance' => NULL,
   'emvResponse' => NULL,
   'transHashSha2' => NULL,
   'profile' => NULL,
   'objectName' => NULL,
   'objectNameSuffix' => '',
   'data' => 
  array (
    'responseCode' => '1',
    'authCode' => 'K6GP9X',
    'avsResultCode' => 'Y',
    'cvvResultCode' => 'P',
    'cavvResultCode' => '2',
    'transId' => '60120875895',
    'refTransID' => '',
    'transHash' => '',
    'testRequest' => '0',
    'accountNumber' => 'XXXX0027',
    'accountType' => 'Visa',
    'messages' => 
    array (
      0 => 
      array (
        'code' => '1',
        'description' => 'This transaction has been approved.',
      ),
    ),
    'transHashSha2' => '',
    'SupplementalDataQualificationIndicator' => 0,
  ),
   'refTransId' => NULL,
))

In Auth.net:

Transaction ID: 60120875895
Transaction Status:   Captured/Pending Settlement
Settlement Information
Settlement Amount:  USD 140.00
Settlement Date and Time:   
Authorization Information
Authorization Amount:   USD 140.00  
Submit Date/Time:   08-May-2019 18:40:32 PDT  
Authorization Code:   .....
Reference Transaction ID:   Not Applicable
Transaction Type:   Authorization w/ Auto Capture
Market Type:  eCommerce
Product:  Card Not Present
Address Verification Status:  Street Address: Match Zip: Matched first 5 digits (Y)
Card Code Status:   Not Processed
CAVV Result Code:   Not Applicable
Fraud Score Applied:  Not Applicable
Recurring Billing Transaction:  N 
Partial Capture Status:   Not Applicable
Customer IP:  ***.***.***.***
Payment Information
Card Type:  Visa
Card Number:  XXXX0027
Expiration Date:  XXXX
Total Amount:   USD 140.00  
Order Information
Invoice #:  
Description:  payment for inv #40
Customer Billing Information
Name:   Sam Smith
Company:  
Address:  
City:   
State/Province:   
Zip Code:   55555
Country:  
Phone:  
Fax:  
Email:  
Customer ID:  12345
Customer Type:  
Customer TaxID/SSN:

I would like to see the following populated (if possible): Invoice # with the provided transactionId (962058365 in this case)

Either way, I do not see the transactionId (962058365) populated anywhere within the transaction details in Auth.net. Any idea what I'm missing?


[JJ: edited for formatting]

judgej commented 5 years ago

Some gateway drivers do put the transactionId into the invoice number field, but I don't think that is the right way to go. The transactionId is a unique ID for the payment attempt as seen from the merchant site. For a single invoice on the merchant store, there may be multiple attempts to pay, and each would get a unique transactionId to track the transaction. However, all would keep the same invoiceId invoiceNumber to track the invoice, which is at a higher level.

A shop may also allow multiple partial payments for a single invoice, or a subscription.

So in short, the transactionId and the invoiceId invoiceNumber are very different things that should be kept apart at the driver level. If you want to join them one-to-one in your merchant store, then that's fine if it works with your data structures.

Now, looking at your data, there are some nulls where there shouldn't be. I'm not seeing that here, so I'll check to make sure in the first instance that I have pushed changes and made all the releases I should have.

judgej commented 5 years ago

If you set the invoiceNumber do you get to see that in the back end?

judgej commented 5 years ago

Have a quick play with this: https://omnipay.acadweb.co.uk/authorizenet-api-3x/test3.php

It uses Accept.JS to make a payment against the sandbox. The card details are already set up to save you some time. The transactionId does seem to be going through end-to-end.

jeffsta9 commented 5 years ago

Many thanks for the assist, JJ :)

So, invoiceNumber does the trick. However, I do not see invoiceNumber in the STD Onmipay options or in the Omnipay-AuthorizeNetApi options; at least, not on the front GH pages.

Regardless, adding the invoiceNumber to the request resolves my issue. I'm not currently concerned w/ the transactionId as you descbibe it above but I understand. I just didn't see the invoiceNumber option; so, I opted for transactionId instead.

jeffsta9 commented 5 years ago

For the record invoiceId does not work the same as invoiceNumber in Auth.net. I just tried using invoiceId instead of invoiceNumber and it didn't populate the Invoice Number in Auth.net.