Encountering Random The value X provided for x-amz-pay-date should not be in future

[adrianpadurean]

Hello,

I'm using the this dependency for a amazonPay instant checkout option. Every now and then some of the payments fail with this particular error (as mentioned in the title).
`
(
[status] => 400
[method] => PATCH
[url] => https://pay-api.amazon.eu/live/v2/checkoutSessions/e73fcfe0-9791-4a99-814a-92d102dbeca1
[headers] => Array
(
[0] => accept:application/json
[1] => authorization:AMZN-PAY-RSASSA-PSS PublicKeyId={}, SignedHeaders=accept;content-type;x-amz-pay-date;x-amz-pay-host;x-amz-pay-region, Signature={}
[2] => content-type:application/json
[3] => user-agent:amazon-pay-api-sdk-php/2.2.4 (PHP/7.3.27-9+ubuntu20.04.1+deb.sury.org+1; Linux/x86_64/5.4.0-1042-gcp)
[4] => x-amz-pay-date:20220131T094401Z
[5] => x-amz-pay-host:pay-api.amazon.eu
[6] => x-amz-pay-region:eu
)

[request] => {"webCheckoutDetails":{"checkoutResultReturnUrl":"{}"},"paymentDetails":{"paymentIntent":"Authorize","canHandlePendingAuthorization":false,"chargeAmount":{"amount":63.03,"currencyCode":"EUR"}},"merchantMetadata":{"merchantReferenceId":"ORD000000070180","merchantStoreName":"{}","noteToBuyer":"","customInformation":""}}
[response] => {"reasonCode":"InvalidHeaderValue","message":"The value 20220131T094401Z provided for x-amz-pay-date should not be in future"}
[request_id] => bb3dde4d-c33f-4452-a1cd-dc88c87395cc
[retries] => 0
[duration] => 112

)
`

I think most of the information needed is there, let me know what else I should provide.

[shangamesh]

Thanks for providing creating the issue, we will check & update the root cause or resolution

[shangamesh]

Can you ensure your server clock is correct?
If on a Linux system you can use the "date" command and check if it is ahead of the actual time. Do let us know if this is the issue. The amazon-pay-api-sdk-php module relies on the standard PHP time() function to create the timestamp for this header; I think the only reason this should be invalid is if the server is providing inaccurate time values

[adrianpadurean]

Hello @shangamesh, thank you for helping me for starters. I have had this exception caught in a log, the time on the log was an hour MORE than the log, so if anything, the request was from the "past", not the "future", the local server time was 10am, the error log showed the time logged at 9am but from the PHP docs, the function is meant to return Greenwich Mean Time (GMT) which would make sense judging on the time zone of the server and the hosting service, in regards to GMT.

Hmm, anyways, I will try the date function as test and see what it shows, but it should be GMT time (a.k.a +0 UK TIME) not the server time, am I correct?

Also, another bit of information, I'm using an older version of the payment module (2.2.4)

I'll be back with more info in the meantime however, the issue is still weird because it only happens SOMETIMES to some orders, not all of them, all the time, how would that even work if there was a clock problem?

Thanks for the answer again and have a great day!

[shangamesh]

For the incoming API request we translate the date time obj passed to API to UTC time & will be validated. We have checked in our backend system & identified that this exception only when date-time is ahead of time. As you also mentioned it happened for some time, can you please check whether any change in your system/server date time has been changed for some period of time which leads to this issue

[adrianpadurean]

I'm coming back after some debugging on Live, So I'm currently in GMT + 2,
the local time was: 20220207T000919Z
the server time was: 20220207T220919Z
the timestamp value was: 20220207T230919Z

So from the perspective of the actual clock in terms of minutes and second, it doesn't seem to be off. Were we actually expecting a difference in the hour/minute or a difference in timezones?

[shangamesh]

Is your server configured with UTC or something else ?
Can you also see your server time is matching with UTC time by Googling for "UTC time" ?
If it is off by a single hour, maybe there is a winter/summer time timezone setting configured incorrectly on the server

[Indianer3c]

@adrianpadurean @shangamesh same problem with my local test environment. My solution was that I enabled external time determination for my operating system.