I'm configuring FEDEX shipping in Magento website. I got test account number, password, API key and meter number by login in test FEDEX account. I configured myself in Magento. Looks like everything fine. But I don't know how to test is Track Order.
So where can I get tracking number for shipping methods? Should I enter randomly or how can I get that? I tried some forum suggested numbers. But I got below error in my popup:
Tracking information is currently not available
I also checked my shipping_fedex log file in Magento. got logged some error codes in printed array. That's I give in below.
**ERROR log**
[result] => stdClass Object (
[HighestSeverity] => ERROR
[Notifications] => stdClass Object (
[Severity] => ERROR
[Source] => trck
[Code] => 6035
[Message] => Invalid tracking numbers. Please check the following numbers and resubmit.
[LocalizedMessage] => Invalid tracking numbers. Please check the following numbers and resubmit.
)
[Version] => stdClass Object (
[ServiceId] => trck
[Major] => 5
[Intermediate] => 0
[Minor] => 0
)
)
FEDEX help:
What Numbers Can I Track?
Track by Tracking Number: You can enter
up to 30 tracking numbers at a time. You can enter any combination of
FedEx Express, FedEx Express Freight, FedEx Ground, FedEx SmartPost,
FedEx Freight, or FedEx Custom Critical tracking numbers. Please
ensure that you enter only one tracking number per line.
Edit: I used "99999999999" as per Derek suggestion. But I got below response. Still same error in pop up. What does mean __pid =>2432?
Array
(
[request] => <?xml version="1.0" encoding="UTF-8"?>
<FDXTrack2Request xsi="http://www.w3.org/2001/XMLSchema-instance" noNamespaceSchemaLocation="FDXTrack2Request.xsd"><RequestHeader><AccountNumber>510087062</AccountNumber><MeterNumber>0</MeterNumber></RequestHeader><PackageIdentifier><Value>999999999999</Value></PackageIdentifier><DetailScans>1</DetailScans></FDXTrack2Request>
[result] =>
[__pid] => 2432
)
Your question is not at all stupid. I upvoted it.
The fedex documentation is horrible and doesn't mention how to use their services while testing and after moving to production. Their support is worse.
While I was rambling in the internet, I found a page mentioning the tracking number 123456789012 as a test number. Use it with your test credentials (key, password, account number and meter number), while you're setting your service path to https://wsbeta.fedex.com:443/web-services/track, and the request will return a valid response that you can build on.
Here’s a list of static tracking numbers that can be used in the FedEx test environment:
449044304137821 = Shipment information sent to FedEx
149331877648230 = Tendered
020207021381215 = Picked Up
403934084723025 = Arrived at FedEx location
920241085725456 = At local FedEx facility
568838414941 = At destination sort facility
039813852990618 = Departed FedEx location
231300687629630 = On FedEx vehicle for delivery
797806677146 = International shipment release
377101283611590 = Customer not available or business closed
852426136339213 = Local Delivery Restriction
797615467620 = Incorrect Address
957794015041323 = Unable to Deliver
076288115212522 = Returned to Sender/Shipper
581190049992 = International Clearance delay
122816215025810 = Delivered
843119172384577 = Hold at Location
070358180009382 = Shipment Canceled
In addition to: 123456789012
You can also use: 111111111111
** Every carrier (UPS, USPS, etc...) has lots of tracking numbers for lots of use-cases, but not FedEx... I find that very strange.
* Also... I am guessing FedEx expects you to use real tracking numbers even in their test environment. It's how I have been testing for multiple use-cases.
I hope this helps anyone, I have spent a while digging around.
On their website they list the tracking numbers you can use:
https://www.fedex.com/en-us/developer/web-services/process.html#develop
Expand the Testing Environment and Mock Tracking Numbers subheading.
Short answer
Use one of the tracking numbers from the table below (copied from Mock Tracking Numbers for FedEx Express and FedEx Ground) or number 123456789012, but mind that the FedEx Sandbox environment might be unstable during your testing and you might need to use FedEx API mocks instead (either built in-house using Wiremock or ready-made by a vendor).
Scan Event
Tracking Number
Track By Reference Info.
Shipment Account Number
Ship Date
Destination Postal Code
Shipment information sent to FedEx
449044304137821
Customer Reference: 115380173Ground Shipment ID: DMWsGWdnNN
510088000
15-08-2020
33126
Tendered
149331877648230
Ground Shipment ID: 149331877648230
510088000}]
15-08-2020
28752
Picked up
020207021381215
Ground Shipment ID: 53089528
510088000
15-08-2020
30549
Arrived at FedEx location
403934084723025
Ground Shipment ID: 403934084723025Department: 31826722
510088000
15-08-2020
99206
At local FedEx facility
920241085725456
Customer Reference: 0014243047/34684523 Ground Shipment ID: 920241085725456
510088000
15-08-2020
19720
At destination sort facility
568838414941
Shipper Reference: P218101_004154359Purchase Order: P218101_004154359
510088000
15-08-2020
85388
Departed FedEx location
039813852990618
Customer Reference: 4631962Ground Shipment ID: THE HOUSEDepartment: McGeePurchase Order: 3385158
510088000
15-08-2020
24740
On FedEx vehicle for delivery
231300687629630
Customer Reference: W62283340102Ground Shipment ID: 231300687629630Purchase Order: 6228334
510088000
15-08-2020
33126
International shipment release
797806677146
N/A
Customer not available or business closed (Delivery Exception 007)
377101283611590
Ground Shipment ID: 377101283611590
510088000
15-08-2020
95815
Local delivery restriction (Delivery Exception 083)
852426136339213
Customer Reference: 118402713013
510088000
15-08-2020
11375
Incorrect address (Delivery Exception 03)
797615467620
Shipper Reference: OTHER-TK104
510088000
15-08-2020
70810
Unable to deliver (Shipment Exception 099)
957794015041323
N/A
Returned to sender/shipper
076288115212522
Invoice: 81909
510088000
15-08-2020
50323
Clearance delay (International)
581190049992
N/A
Delivered
122816215025810
Customer Reference: PO#174724
510088000
15-08-2020
24273
Hold at location
843119172384577
N/A
Shipment canceled
070358180009382
Customer Reference: 15241402Ground Shipment ID: 070358180009382
510088000
15-08-2020
94545
Duplicate Tracking Number
713062653486
Unique Identifier 1: 2457821000~713062653486~FXUnique Identifier 2: 2457835000~713062653486~FX
Long answer
The FedEx Sandbox has numerous stability and test data problems. For example, if you use tracking code 123456789012 you will get a different response status depending on the state of the FedEx Sandbox environment.
If you are performing a one-off manual test of your Magento integration with FedEx API, then using the FedEx Sandbox should be sufficient, and you can go ahead and use one of the codes provided above.
If however, you are running automated regression or integration tests on a schedule or per commit then the instability of the environment might cripple your testing. For example, you might see flaky tests and flaky builds and have to spend time investigating them even though there is nothing wrong with your code or tests, it's just an issue with the FedEx Sandbox API.
To resolve the issue with FedEx Sandbox environment stability you have three options, which are essentially about using test-doubles instead of the real FedEx Sandbox API:
Create and use mocks in your code instead of using the FedEx Sandbox. For example, Mockito in Java or uniuttest.mock in Python. This means you will have to write the FedEx Mockito mocks yourself. And it comes with several tradeoffs.
Create over-the-wire mocks with tools like Wiremock or Mountebank instead of using the FedEx Sandbox. There is a list of tools like that on Wikipedia. The issue here again is that you have to build those over-the-wire mocks yourself, which can be problematic if it's more than one API and you have a lot of work on your plate anyway.
Use ready-made FedEx API mocks like the one from Traffic Parrot instead of using the FedEx Sandbox. The advantage is they are created by experts and you can use them within minutes, just copy their mock API URL and use it instead of the FedEx one. You will have to pay for using them, which can sometimes be a downside of this option.
Here is a good one I pulled out of a code sample in the developer docs.
797843158299
The above list of tracking numbers will indeed work when pointed to the following server endpoint:
https://wsbeta.fedex.com:443/web-services/track
Note that the only time these numbers will not work is during FedEx's scheduled maintenance windows.
You may try getting the ship functionality working first. That will provide you a tracking no that can be used in testing tracking. I did it this way and it works for me!
We're trying to understand FEDEX tracking number testing too. I found this resource. But so far I'm not sure if the numbers work.
We'll update the answer later if we determine it helped or delete it if it does not:
https://www.fedex.com/us/developer/webhelp/ws/2019/US/index.htm#t=wsdvg%2FAppendix_F_Test_Server_Mock_Tracking_Numbers.htm
Related
Is it legal and possible to:
1. Get PKPaymentToken in iOS app
2. Send this token to server side
3. Decrypt this PKPaymentToken (ex. based on many available GitHub libraries)
4. I have now:
{
"applicationExpirationDate": "190131",
"applicationPrimaryAccountNumber": "370295XXXXX5435",
"currencyCode": "840",
"deviceManufacturerIdentifier": "XXXXXXXXXX",
"paymentData": {
"emvData": "nycBgJ82AgDCnyYIG2vuQydGkMafEAcGhgEDoLABXzQBAJUFgAABAACCAhzAnwMGAAAAAAAAnxoCCECaAxQQBJwBAJ83BLnvab4="
},
"paymentDataType": "EMV",
"transactionAmount": 100
}
5. Use this data to make transaction in such way:
Here I have doubt!
To make transaction I can use only this EMV or 3DS cryptogram in paymentData -> emvData (or 3dsecure)
Or I can use applicationPrimaryAccountNumber as casual Card Number (or maybe this is different from Card Number printed on physical plastic Card?)
Why I am asking? On the server, I have integration with another external system that handles transactions. And there is a library that takes credit card information (card number, expiry date, cardholder) to make the transaction.
Will I be able to use this decrypted data to pass raw card number, exp date, cardholder to this library to make transaction payment happen.
Or this library must be able to handle this EMV, 3DSecure cryptograms only?
Thanks for the clarification.
Very confused by the crowd of paypal-APIs, I wonder if I just can fetch the transactions (in and out) somehow, just like I would it export to csv via webinterface.
Here I am:
REST-API seems not working for "non-rest-transactions" Payment.all.size == 0 paypal-rest-api-list-payments-returns-no-entries
Merchant-API does not allow detailed info for specific transactions.
https://developer.paypal.com/webapps/developer/docs/classic/api/merchant/GetTransactionDetails_API_Operation_SOAP/ says:
Note The details for some kinds of transactions cannot be retrieved
with GetTransactionDetails. You cannot obtain details of bank transfer
withdrawals, for example.
I recieved a view transactions via transactionSearch. Took the transactionId from one of the transactions.
api.get_transaction_details(:transaction_id => transaction_id>)
=> #<PayPal::SDK::Merchant::DataTypes::GetTransactionDetailsResponseType:0x007fd3c0f1f8d8
#Ack="Failure",
#Errors=[#<PayPal::SDK::Merchant::DataTypes::ErrorType:0x007fd3c0f379d8
#ShortMessage="Invalid transaction type",
#LongMessage="You can not get the details for this type of transaction",
#ErrorCode="10004",
#SeverityCode="Error">]
Adaptive-API (PaymentDetails with transactionID) throws an "internal error 520002" with no details. (And I found no specification if it could fetch all transactions)
Ok, it's Paypal. But there must be a simple solution they forgot to mention. (?!) Or what did I miss?
Thanks and regards, Phil
I don't know where you're seeing info that the merchant API won't provide details about transactions, but that's simply wrong.
You you can use TransactionSearch to obtain a list of transactions within a given time period, and then you can loop through those results and use GetTransactionDetails to obtain the details for each individual transaction.
I am getting transaction declined errors (The transaction was Declined (BH)) when using a test with DPS Payment Express account (PxPay 2.0) for processing credit cards on a website.I am using test credit card no 4111111111111111, expiry date is any future date ,any name for card holder name and 3 digit csv numer.
I am getting following error(response)
Response:DECLINED
Response Code:BH
Currency:USD
Amount: 2016.92
Card:411111........11
Card Holder:MANISH KUMAR
Card Type:Visa
Date:20141007
Time:060747
Transaction Type:Purchase
Help Text:The transaction was Declined (BH)
Can any one please help me....
It is solved by change the currency to NZD.
For others that are using PXPOST "The transaction was Declined (BH)" means that the port is not configured for the Currency you are trying to charge in.
In our case we already had a multi-currency merchant account with our bank but we had to call Payment Express and ask them to enable the new currency we were sending.
We offer 2 type of delivery to uk customers
spend over £100 and get it free special delivery
spend under £100 and get it free 1st class record but option of Special Delivery for extra £3.
Cannot work out how to enable to in Magento (1.7.0.2)
So how can I add the free with £3 option for carts less than £100?
So I found this extension: http://www.webshopapps.com/uk/free/matrixrate-shipping-extension.html
This is the table I used:
"Country","Region/State","City","Zip/Postal Code From","Zip/Postal Code To","Order Subtotal From","Order Subtotal To","Shipping Price","Delivery Type"
"GBR","","","","","0","99.99","0","Free 1st Class Recorded"
"GBR","","","","","0","99.99","3","Upgrade to Special Delivery Next Day before 1pm"
"GBR","","","","","100","9999","0","Free Special Delivery Next Day before 1pm"
Which works like a charm - hope this helps
For some reason order ID's (increment_id on sales_flat_order table) are not incrementing subsequently on my Magento 1.6.1. This is how it looks after a number of live orders placed:
increment_id created_at updated_at
100000001 2011-12-14 12:35:24 2011-12-14 12:35:25
100000002 2011-12-14 13:02:39 2011-12-14 13:02:39
100000003 2011-12-14 13:04:18 2011-12-14 13:04:18
100000004 2012-02-01 16:54:58 2012-02-01 16:54:58
100000005 2012-03-14 12:22:35 2012-03-14 12:22:35
100000006 2012-03-20 13:10:48 2012-03-20 13:10:48
100000011 2012-03-29 20:58:48 2012-03-29 20:58:48
100000012 2012-03-29 21:06:43 2012-03-29 21:06:43
100000013 2012-03-30 10:48:20 2012-03-30 10:48:21
100000014 2012-03-30 13:05:40 2012-03-30 13:05:41
100000015 2012-04-03 15:51:01 2012-04-03 15:51:02
100000016 2012-04-19 15:00:49 2012-04-19 15:00:50
100000017 2012-05-09 12:09:21 2012-05-09 12:09:22
100000019 2012-05-24 05:35:35 2012-05-24 05:35:36
100000020 2012-05-24 05:41:11 2012-05-24 05:41:12
100000008 2012-05-24 05:48:52 2012-05-24 05:48:53
My question is why is Magento jumping increments sometimes? And worse yet, in my example order with increment 100000008 goes after 100000020. Does someone know why this is happening and if there's a way to fix it?
This is normal, albeit understandably disconcerting.
When Magento enters the checkout process it 'reserves' an increment_id and places it on the quote (cart) object. You can see the code that gets an increment id at:
Mage_Eav_Model_Entity_Type::fetchNewIncrementId()
The last used ID for each store is stored in eav_entity_store. If a customer abandons their cart (ie the quote object) before completing the checkout process, the reserved increment_id will never show up on an order. You can see this effect sometimes in the order numbers as they come in on a busy store - occassionally a really old order id comes through in the day's orders from a customer that is checking out an old cart.
This behaviour exists to allow Magento to send payment gateways the final order id (increment_id), before the order is completed allowing the gateway to associate the order id with the order. If the customer abandons the payment process in the gateway, the order id is dead (or more correctly still attached to the quote).
You can see this happening in the PayPal express module at:
Mage_Paypal_Model_Express_Checkout::start()
which calls
Mage_Sales_Model_Quote::reserveOrderId()
If you want to find your 'missing' increment_ids, take a look in sales_flat_quote under the field reserved_order_id. You should see them attached to unconverted quote objects (carts).
This behaviour can create issues with some payment gateways; Moneris comes to mind. When you send Moneris' hosted paypage the same order id twice, it chokes and creates a cryptic error state for the customer. This condition occurs when the customer visits the hosted pay page, backs out and re-visits the page. Hence in some cases, it is necessary to re-generate the order id associated with the quote object programmatically.
I was facing the same issue but it was only when the server was hit with a huge amount of load. This issue occurs because the db goes into the lock state while converting quote into order. On further inspection, I found out that the issue was that it tried to write into sales_flat_order_grid table within transaction right after insert into sales_flat_order table. With concurrent queries it caused locking collisions. The real solution is to move stuff of sales_flat_order_grid out of the transaction.
The link helped me understand the issue
The patch resolved the issue for me.
You have to remove function _afterSave from the Mage_Sales_Model_Abstract and add
public function afterCommitCallback(){
if (!$this->getForceUpdateGridRecords()) {
$this->_getResource()->updateGridRecords($this->getId());
}
parent::afterCommitCallback();
}
Let me know if it solves the problem for you.
We have had this same issue multiple times over the past couple of months. Upon checking our payment service provider transaction list we see 1000's of low value (micro) transactions being declined due to potential fraud issues. My opinion is that a fraudster is trying to use our checkout process to probe the list of cards they have to find out what cards are valid and what cards are dead. I have reported it to action fraud, our web host and our payment provider.
In summary, my advise would be for you to check your PSP list of transactions for the same time period.
Good luck with it,
Brisc.