Open jeffsta9 opened 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?
@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.
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.
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.
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]
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 null
s 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.
If you set the invoiceNumber
do you get to see that in the back end?
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.
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.
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.
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 :)