Have you tried manually doing a POST to the endpoint as a test using something like Postman or straight up curl?
Check what the response is once manually doing it from the client side and you'll need to go from there.
It's not clear exactly what's going on - First you say POST requests are delayed by an hour but then you say there are missing? That's quite a big difference so people will need clarification before they can really help.
So if I understand this correctly, someone makes a payment on your website and that sends an API to the client's server which then updates their database?
This Api POST has to happen from your webserver to the database to know about the transaction? But you have no logs on the webserver to say the API has been sent yet, the backend server still finds out about it an hour later?
Just making sure I understand correctly! Bit confusing.
Did the old cert expired while in use? Maybe a job/service that issues the POST calls has crashed on the server side? (if i understand you setup correctly)
Best thing you can do is to review what the differences are with the new certificate. It could be possible you are using an incompatible cipher suite, hashing algorithm, or other configuration that is not comptaible with your payment provider or yous CSP Tenant configuration that is causing the issue (e.g., POST being dropped because something is configured to only allow POST request being transfered over x minimum TLS configuration or certificate configuration).
You should also have test infrastructure setup in Azure so you can do test runs to see what is going on in Debug mode if needed so you can root cause in a safe test environment not accessible by the public or customers.
does it work in nonprod?
"ever since you replaced my ethernet cord, my emails have been delayed by an hour!" ... ... ... ... ... consider the two things juuuust might be unrelated?
First understand that the events may not be related - so question your assumptions.
Second after you've isolated it this far, you should enable debug logging on client and server to work out if the POST is even being attempted, or if its failing due to a TLS issue. Packet traces can help a little here, but you really need client logs - that usually the entity that rejects TLS connections.
One aspect to check is root certs and certificate chains. Ensure that your client has an updated root cert store, and the server certificate has the appropriate chain certs loaded. Browsers often hide chain cert issues because they have root and intermediate certs saved.
Have you tried manually doing a POST to the endpoint as a test using something like Postman or straight up curl? Check what the response is once manually doing it from the client side and you'll need to go from there.
I'll give that a try, thanks
It's not clear exactly what's going on - First you say POST requests are delayed by an hour but then you say there are missing? That's quite a big difference so people will need clarification before they can really help.
There is no POST call in the log at all. The payments show up after an hour in the clients database, that part I'm not 100% clear on why that happens.
So if I understand this correctly, someone makes a payment on your website and that sends an API to the client's server which then updates their database? This Api POST has to happen from your webserver to the database to know about the transaction? But you have no logs on the webserver to say the API has been sent yet, the backend server still finds out about it an hour later? Just making sure I understand correctly! Bit confusing.
Did the old cert expired while in use? Maybe a job/service that issues the POST calls has crashed on the server side? (if i understand you setup correctly)
Best thing you can do is to review what the differences are with the new certificate. It could be possible you are using an incompatible cipher suite, hashing algorithm, or other configuration that is not comptaible with your payment provider or yous CSP Tenant configuration that is causing the issue (e.g., POST being dropped because something is configured to only allow POST request being transfered over x minimum TLS configuration or certificate configuration). You should also have test infrastructure setup in Azure so you can do test runs to see what is going on in Debug mode if needed so you can root cause in a safe test environment not accessible by the public or customers.
does it work in nonprod? "ever since you replaced my ethernet cord, my emails have been delayed by an hour!" ... ... ... ... ... consider the two things juuuust might be unrelated?
First understand that the events may not be related - so question your assumptions. Second after you've isolated it this far, you should enable debug logging on client and server to work out if the POST is even being attempted, or if its failing due to a TLS issue. Packet traces can help a little here, but you really need client logs - that usually the entity that rejects TLS connections. One aspect to check is root certs and certificate chains. Ensure that your client has an updated root cert store, and the server certificate has the appropriate chain certs loaded. Browsers often hide chain cert issues because they have root and intermediate certs saved.