Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transaction ID not populating #12

Open
jeffsta9 opened this issue May 7, 2019 · 10 comments
Open

Transaction ID not populating #12

jeffsta9 opened this issue May 7, 2019 · 10 comments

Comments

@jeffsta9
Copy link

jeffsta9 commented May 7, 2019

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 :)

@jeffsta9 jeffsta9 changed the title Customer ID not populating Transaction ID not populating May 7, 2019
@judgej
Copy link
Member

judgej commented May 7, 2019

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
Copy link
Member

judgej commented May 7, 2019

@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
Copy link
Author

jeffsta9 commented May 8, 2019

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
Copy link
Member

judgej commented May 8, 2019

In the Omnipay world:

  • transactionId is the ID generated by the merchant site to identify the payment or authorisation.
  • transactionReference is the ID generated by the payment gateway to identify the payment or authorisation that was made.

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
Copy link
Author

jeffsta9 commented May 9, 2019

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
Copy link
Member

judgej commented May 9, 2019

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
Copy link
Member

judgej commented May 9, 2019

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

@judgej
Copy link
Member

judgej commented May 9, 2019

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
Copy link
Author

jeffsta9 commented May 9, 2019

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
Copy link
Author

jeffsta9 commented May 9, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants