error 04 - Error 04 -
vads_trans_date
- an e-mail notification indicating that the transaction is definitively lost in case of an incorrect value of the vads_trans_date field or a major timezone difference with the gateway.You should obtain an error message of the type:
An error occurred during the payment request, please make sure that the posted parameters match the ones specified in the documentation. - a warning e-mail indicating that the difference between the UTC time on our gateway and the UTC time in your payment form was too large. If your shop sends a time that is too far from the real payment time, it can be temporary allowed, then the customer makes the payment on a regular way.However, you receive a warning e-mail explaining the incoherence of the vads_trans_date field (date and time).
It becomes impossible to make the payment and the transaction is definitively lost.
You will receive an e-mail notification containing the form that the gateway was unable to process and the value of the invalid field.
We invite you to check the following reason(s) to resolve the issue:
- Causes of the error in case of an e-mail notification
The date transmitted in vads_trans_date is beyond the tolerated offset. In production mode, the payment gateway tolerates an offset between the time transmitted in vads_trans_date and the UTC time of the gateway that can be 30 min in the past and up to 1:30 in the future.
You will receive a warning e-mail if this offset exceeds 60 min in the past or exceeds 2:30 in the future.
Example:
If the time is 12:00 UTC, you will not receive a warning e-mail if the time transmitted in vads_trans_date is set between 11:30 UTC and 13:30 UTC.
However, you will receive a warning e-mail if the transmitted time is before 11:00 UTC or after 14:30 UTC.
The date has not been submitted in the YYYYMMDDHHMMSS format (year, month, day, hour, minute, second). Example:
On October 17th, 2019 at 8:54:36 am the vads_trans_date field must be 20191017085436.
The date is not based on the UTC time zone (Coordinated Universal Time). The date must imperatively be based on the UTC time zone.
At the top of the e-mail, you can see the UTC date and time when we received the payment request.
In the same e-mail, you can also see the value of the vads_trans_date field received by the payment gateway.
Please make sure that the time difference is not too large compared to the time when we received the payment request.
Time:
The correct time must be between -30mn and +2h30 compared to the time when we receive the payment request.
Example:
If we receive a payment request on July 15th, 2019 at 14:30:00 (UTC time), the DATE field will have to be set between 20190715140000 (July 15th, 2019 at 14:00:00) and 20190715160000 (July 15th at 16:00:00).
Reminder about the UTC time zone:
Depending on the zone and the period of the year, there may be a different UTC time offset.
For example, on July 12th, 2019 at 14:50 in Paris, it is 12:50 UTC because in this period of the year Paris has a +2 hour UTC time offset (summer time). Therefore, in the payment request you should send 20190712 125000 (July 12th, 2019 at 12:50 PM).
However, on January 12th, 2019 at 14:50 in Paris, it is 13:50 UTC because in this period of the year Paris has a +1 hour UTC time offset (winter time).
Therefore, in the payment request you should send 20190112 135000 (January 12th, 2019 at 1:50 PM).
The time must be calculated using the 24h format, not 12h. The date must imperatively be calculated in a 24h format, not 12h.
Example:
If we receive a payment request on July 15th, 2019 at 14:30 UTC (i.e. 2:30 pm), the value of the vads_trans_date field should be 20190715 143000 and not 20190715 023000.
Your customer waited for too long before clicking on the “Pay” button. If this type of error is not frequent, it is possible that the customer has waited for too long before clicking on the “Pay” button.
In this case, the retained date is the one that was calculated based on the display of the page containing the “Pay” button. This is why it is strongly recommended to calculate the date at the moment of clicking on the “Pay” button.
Example:
A customer makes an order at 12:00 and comes back at 14:00 to click on the “Pay” button.
If your form is pre-generated before the click on the “Pay” button, your date will be set to 12:00, but the time of the payment gateway will be set to 14:00. The difference between two dates is too large and the payment gateway returns an error.
Your customer has used his or her browser history. If this error type is not frequent, it is possible that the customer came back to the payment page of your shop (page with the “Pay” button) using their browser history.
In this case, the retained date is the one that was calculated at the time of the first visit on this page. This is why it is strongly recommended to calculate the date at the moment of clicking on the “Pay” button.
- Causes of the error in case of a warning e-mail
The date transmitted in vads_trans_date is beyond the tolerated offset. In production mode, the payment gateway tolerates an offset between the time transmitted in vads_trans_date and the UTC time of the gateway that can be 30 min in the past and up to 1:30 in the future.
Beyond that, you will receive a warning e-mail if this offset is between 30 and 60 min in the past or between 1:30 and 2:30 in the future.
Example:
If the time is 12:00 UTC, you will not receive warning e-mail if the time transmitted in vads_trans_date is set between 11:30 UTC and 13:30 UTC.
However, you will receive a warning e-mail if the transmitted time is between 11:00 and 11:30 UTC or between 13:30 and 14:30 UTC
The date is not based on the UTC time zone (Coordinated Universal Time). The date must imperatively be based on the UTC time zone.
At the top of the e-mail, you can see the UTC date and time when we received the payment request.
In the same e-mail, you can also see the value of the vads_trans_date field received by the payment gateway.
Please make sure that the time difference is not too large compared to the time when we received the payment request.
Time:
The correct time must be between -30mn and +2h30 compared to the time when we receive the payment request.
Example:
If we receive a payment request on July 15th, 2019 at 14:30:00 (UTC time), the DATE field will have to be set between 20190715140000 (July 15th, 2019 at 14:00:00) and 20190715160000 (July 15th at 16:00:00).
Reminder about the UTC time zone:
Depending on the zone and the period of the year, there may be a different UTC time offset.
For example, on July 12th, 2019 at 14:50 in Paris, it is 12:50 UTC because in this period of the year Paris has a +2 hour UTC time offset (summer time). Therefore, in the payment request you should send 20190712 125000 (July 12th, 2019 at 12:50 PM).
However, on January 12th, 2019 at 14:50 in Paris, it is 13:50 UTC because in this period of the year Paris has a +1 hour UTC time offset (winter time).
Therefore, in the payment request you should send 20190112 135000 (January 12th, 2019 at 1:50 PM).
Your customer waited for too long before clicking on the “Pay” button. If this type of error is not frequent, it is possible that the customer has waited for too long before clicking on the “Pay” button.
In this case, the retained date is the one that was calculated based on the display of the page containing the “Pay” button. This is why it is strongly recommended to calculate the date at the moment of clicking on the “Pay” button.
Example:
A customer makes an order at 12:00 and comes back at 14:00 to click on the “Pay” button.
If your form is pre-generated before the click on the “Pay” button, your date will be set to 12:00, but the time of the payment gateway will be set to 14:00. The difference between two dates is too large and the payment gateway returns an error.
Your customer has used his or her browser history. If this error type is not frequent, it is possible that the customer came back to the payment page of your shop (page with the “Pay” button) using their browser history.
In this case, the retained date is the one that was calculated at the time of the first visit on this page. This is why it is strongly recommended to calculate the date at the moment of clicking on the “Pay” button.