zenith pumice
I have a customer with an ancient implementation using the v1 API. When creating a payment, we receive a HTTP 400 response with a HTML payload, but when looking in the dashboard, the payment is created none the less. Could somebody at Mollie enlighten me on what has changed on the v1 API? This "used to work" 🙂
I was able to reproduce using org id #4554074, payment tr_4dY3Qu85vY.
NB we're already working on a replacement, but it would be nice if we can help the customer in the mean time.
unborn walrus
Hey @zenith pumice 🙌 This is not an easy one, as I guess lots of things were changed since v1. Let's see if @still blade @zenith pumice could advise!
zenith pumice
We don't really make any active changes on the V1 anymore. There might be changes to the platform which affect V1 unintendedly.
I can not reproduce this btw, would you mind sending me the exact payload you are using in a DM?
zenith pumice
Hi Tim, I'll try to get a full payload
zenith pumice
POST https://api.mollie.nl/v1/payments
{ "amount":22.55, "description":"Order 104163", "redirectUrl":"https://www.example.nl/checkout/thank-you/", "webhookUrl":"https://www.example.nl/mollie/webhook/", "metadata":{ "order_nr":104163 } }
zenith pumice
@zenith pumice that's all ^^
zenith pumice
According to feedback from the customer, this might have been an issue since August 2022
zenith pumice
That is so weird. I have tried this multiple times (also for the org attached to the payment you linked) and was unable to reproduce it with Postman or straight our cUrl... Must be something in either the client or in the middle then. (Example I created: tr_NXXrxno3M6)
zenith pumice
Argh, sorry for the mess. I dug into the whole app flow again and it appears that the problem is not in the POST request after all.
The flow is that a payment is created (this works), and the payment id is taken from the response. A bit later in the code flow, the created payment is retrieved again from the API using get payment. This does something weird which I could reproduce with curl. The GET request is performed using the following headers:
"User-Agent": "Mollie/1.2.1 Python/3.9.16 OpenSSL/3.0.2",
"Accept-Encoding": "gzip, deflate",
"Accept": "application/json",
"Connection": "keep-alive",
"Authorization": "Bearer test_XXX",
"X-Mollie-Client-Info": "Linux laptop-van-tom 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 x86_64 x86_64",
"Content-Length": "2",
The key issue here is the Content-Length header here. If I leave it out, the request works (returns the payment in JSON), if I set the value to 0, it also works. But when sending it as 2, the response is a HTTP 404 with HTML payload.
Minimal curl example: curl -v --http1.1 -X GET 'https://api.mollie.nl/v1/payments/tr_fNKRgyExbk' -H "Authorization: Bearer test_XXX" -H "Content-Length: 2"
The reason for the value 2 in the header is a bit ugly: the GET request does not have a user-defined payload, so the Python client injects an empty JSON payload of {}. This payload is probably never sent to the server by the HTTP client, but the Content-Length header apparently is generated and added automatically.
zenith pumice
Wauw! Sorry for the late reply
That is a very interesting find! Must have been a nightmare to walk through that one, many respects.
I actually think our platform responds in the expected way then, as the payloadsize does not equal what is submitted in the header. A 400 would be logical then. Very interesting fringe case though
zenith pumice
Note: I resolved this 'issue' by upgrading the client to a newer version of the Mollie client, which does not generate this weird request. This Content-Length behaviour of the API is also happening on v2 endpoints, btw.