Open dgmstuart opened 12 years ago
Actually I think this is an issue at the Spreedly end:
Request:
curl -i -u OUR_API_KEY:X -X PUT -H 'Content-Type: application/xml' -d "`cat speedly.xml`" 'https://spreedly.com/api/v4/dgmstuart-test/invoices/0bda902fc1c0f77b0d45c91a7a5d46778c0100ec/pay.xml'
Response:
HTTP/1.1 403 Forbidden
Server: nginx
Date: Tue, 17 Apr 2012 14:54:30 GMT
Content-Type: application/xml; charset=utf-8 <---- It says it's XML
Transfer-Encoding: chunked
Connection: keep-alive
Status: 403 Forbidden
Cache-Control: no-cache
X-UA-Compatible: IE=Edge,chrome=1
X-Runtime: 2.222238
Charge not authorized <---- But it's not XML
I've emailed someone at Spreedly.
is there any solution for this ??
have anybody responded to you at Spreedly ??
There are a couple of scenarios in which I get the following XML parse error:
Firstly when trying to repeat an action like trying to create a subscriber with a customer ID that already exists. The workaround is for me to make sure that before I try and do Anything, I check that it hasn't already been done, but I'd really prefer RSpreedly to return me something sensible.
The other (and far more worrying) scenario is when sending invalid payment details - e.g. the visa 4012888888881881 example from here: http://spreedly.com/manual/integration-reference/payments-api/pay-invoice
I'm not sure what the expected response should be in these cases, but my guess is that the api call is returning something other than XML.
I'd try and patch this myself, but I fear my Ruby-fu is too weak :(
EDIT: I think this might actually just be a bug in response code handling? Here's the response object I get when creating an invoice with an invalid subscriber record - doing this call results in the XML parse error above: