Home → Problems →

Gettting 500 errors when I try to used a delayed error

• Edit

dirk

19 Jun, 2010 01:47 AM

result = @cg.send(:post, "/customers/edit/productCode/TEST_PRODUCT/code/#{@c.subscription.cg_id}", {:body => :subscription => {:ccFirstName => "First", :ccLastName => "Last", :ccNumber => "4111111111111111", :ccExpiration => "01/2020", :ccCardCode => "123", :ccZip => "96000", :planCode => "PAY_TEST_PLAN"}}})

<HTTParty::Response:0x8 @parsed_response=nil, @response=#<Net::HTTPInternalServerError 500 Internal Server Error readbody=true>, @headers={"x-powered-by"=>["PHP/5.2.4-2ubuntu5.10"], "expires"=>["Thu, 19 Nov 1981 08:52:00 GMT"], "connection"=>["close"], "content-type"=>["text/html"], "date"=>["Sat, 19 Jun 2010 01:44:39 GMT"], "server"=>["Apache"], "content-length"=>["0"], "set-cookie"=>["CHEDDARGETTER=a4b6eced964aa00be8085a13ce61e15b; expires=Fri, 17 Sep 2010 01:44:39 GMT; path=/; domain=.cheddargetter.com"], "cache-control"=>["no-store, no-cache, must-revalidate, post-check=0, pre-check=0"], "pragma"=>["no-cache"]}>

Nothing shows up in the error logs on the product. Before this code would trigger a declined delayed error. Now it just gives me athat 500 server error.

Has something about the call changed or have I hit a bug in the system?

1. Support Staff 1 Posted by Marc Guyer on 19 Jun, 2010 11:22 AM

   

   Hmm... We're not seeing this in our logs either. Can you post the raw xml returned from the API?
   

   • Edit

2. 2 Posted by dirk on 19 Jun, 2010 01:26 PM

   

   I removed my userid/password - but other wise this is the debug output.

    "POST /xml/customers/edit/productCode/TEST_PRODUCT/code/TEST-T-3294 HTTP/1.1\r\nContent-Type: application/x-www-form-urlencoded\r\nConnection: close\r\nAuthorization: Basic *****==\r\nContent-Length: 230\r\nHost: cheddargetter.com\r\n\r\n"
   <- "subscription[ccFirstName]=First&subscription[planCode]=PAY_TEST_PLAN&subscription[ccLastName]=Last&subscription[ccNumber]=4111111111111111&subscription[ccExpiration]=01%2F2020&subscription[ccCardCode]=123&subscription[ccZip]=96000"
   -> "HTTP/1.0 500 Internal Server Error\r\n"
   -> "Date: Sat, 19 Jun 2010 13:25:07 GMT\r\n"
   -> "Server: Apache\r\n"
   -> "X-Powered-By: PHP/5.2.4-2ubuntu5.10\r\n"
   -> "Set-Cookie: CHEDDARGETTER=4867f97027a112b831c6a9e3ec3a6771; expires=Fri, 17 Sep 2010 13:25:08 GMT; path=/; domain=.cheddargetter.com\r\n"
   -> "Expires: Thu, 19 Nov 1981 08:52:00 GMT\r\n"
   -> "Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0\r\n"
   -> "Pragma: no-cache\r\n"
   -> "Content-Length: 0\r\n"
   -> "Connection: close\r\n"
   -> "Content-Type: text/html\r\n"
   -> "\r\n"
   reading 0 bytes...
   -> ""
   read 0 bytes
   Conn close
   

   • Edit

3. 3 Posted by dirk on 19 Jun, 2010 01:44 PM

   

   I can give the earlier output if it helps?

   • Edit

4. Support Staff 4 Posted by Marc Guyer on 19 Jun, 2010 10:30 PM

   

   Ok -- we were able to replicate. We've deployed a patch that fixes the error. Please let us know if you have further difficulty. Thanks for the report!

   • Edit

5. Marc Guyer closed this discussion on 19 Jun, 2010 10:30 PM.

6. dirk re-opened this discussion on 21 Jun, 2010 01:03 AM

7. 5 Posted by dirk on 21 Jun, 2010 01:03 AM

   

   Ok so I'm confused. Now when I run the code I immediately get at

   CheddarGetter::Error: The transaction was declined

   That's neat an all - but the whole point of using the zip codes is to trigger a "delayed" error. Like one that happens at the gateway.
   http://support.cheddargetter.com/faqs/api-8/error-simulation

   It says I use a zipcode that starts with 0 to do a real time error and a 9 if I want it to be delayed.

   I'm using a 9 - it should return succesfully and show the error later - or has the api changed?

   • Edit

8. Support Staff 6 Posted by Marc Guyer on 21 Jun, 2010 03:52 PM

   

   Delayed Error is a bit of a misnomer under your configuration. Your pricing plans are configured to bill immediately on signup and you are not configured to execute a validation transaction. Real-time error simulation occurs either on the validation transaction or on the transaction the runs immediately on signup. Delayed error simulation occurs if an account was successfully created and then declines later (e.g, on the next invoice.).

   I suppose the relevant part of the doc is:

   Realtime errors are those that occur when a customer's credit card is initially validated.

   Under your config, the credit card is initially validated with the first full invoice transaction (bill immediately on signup). If your plans were configured to bill one billing cycle after signup, or the initial bill date was overridden to be a future date, a delayed error could be simulated.
   

   We'd have to do some research to be 100% sure but off the top of my head, you may be able to simulate a delayed error under your config by first creating a customer with a good credit card (no error simulation zip) then changing the billing information for the customer to include a delayed error zip. Then, the next invoice should generate the desired error.

   • Edit

9. Marc Guyer closed this discussion on 21 Jun, 2010 03:52 PM.

10. dirk re-opened this discussion on 22 Jun, 2010 01:50 AM

11. 7 Posted by dirk on 22 Jun, 2010 01:50 AM

    

    I'm confused now. Before this worked now it doesn't. I'm trying to make sure that when you reject a card because it is processed on your end I can look at their invoices and see a declined transaction. I don't want to use the call back system - I should be able to look at their invoices and see that there is a declined transaction.

    I changed one of the plans to bill later - and it doesn't seem to process it.

    So how do I configure the plan so that I can subscribe to a paid plan, and then have your system reject the credit card later for a valid error (like no balance available)? I'll change the plan however I need to - but I can't seem to get it to be "delayed"
    

    • Edit

12. Support Staff 8 Posted by Marc Guyer on 22 Jun, 2010 03:43 PM

    

    Maybe I'm misunderstanding your question but I believe I already answered it:

    We'd have to do some research to be 100% sure but off the top of my head, you may be able to simulate a delayed error under your config by first creating a customer with a good credit card (no error simulation zip) then changing the billing information for the customer to include a delayed error zip. Then, the next invoice should generate the desired error.

    I see that you have created a plan called "Pay More Plan" that has a delayed initial bill (1 month later). If you create a customer under that plan with a zip of 96000, the initial bill (1 month later) will be declined. If you want to speed that up, you could set the plan to bill 1 day after signup.

    • Edit

13. Marc Guyer closed this discussion on 22 Jun, 2010 03:43 PM.

14. dirk re-opened this discussion on 22 Jun, 2010 08:24 PM

15. 9 Posted by dirk on 22 Jun, 2010 08:24 PM

    

    So do you mean I have to wait in real time for a day to pass? Before it happened right after I submitted the request?

    • Edit

16. 10 Posted by dirk on 23 Jun, 2010 02:35 AM

    

    I tried to do exactly what you said. When I do that - all that happens is an invoice is queued to bill again at some point in the future.

    Previously, when I used a "delayed" error - I was able to see the "declined" transaction moments later. It seems like the delay is now at least 24 hours - which is a big shift from how the simulator used to work. That breaks my tests completely.

    Here's what I'm trying to work through - I had a bunch of tests to make sure that we were processing information from CheddarGetter correctly. Now it seems like the "delayed" error that allowed me to confirm that some of the payment corner cases are handled correctly on my end has disappeared.

    How do I get that back?
    

    • Edit

17. Support Staff 11 Posted by Marc Guyer on 23 Jun, 2010 12:49 PM

    

    If you were getting a delayed error in real-time they you were unfortunately experiencing a bug which has since been fixed. We regret that your tests have failed as a result. The good news is that you should have less corner cases to test and experience many less possibilities altogether. In other words, you will only experience real-time errors. It shouldn't be necessary for your app to test transaction failures on future invoices unless you're doing something special. Happy to help in any way we can.

    • Edit

18. Marc Guyer closed this discussion on 23 Jun, 2010 12:49 PM.

19. dirk re-opened this discussion on 23 Jun, 2010 01:09 PM

20. 12 Posted by dirk on 23 Jun, 2010 01:09 PM

    

    Ok so how do I test that your call back works correctly with my system? Is there some way to force your system to make the callback so I can verify that when you have declined a card - our system updates its records

    • Edit

21. Support Staff 13 Posted by Marc Guyer on 23 Jun, 2010 01:46 PM

    

    If you mean automated functional tests, then it may not be possible since the process is asynchronous. If you want to manually test some call backs we can speed up the process for you. If you create some accounts and then change their billing zip to an error simulation code, we can change the next bill date and run the transactions for you. You then should see the callbacks come in.
    

    • Edit

22. Marc Guyer closed this discussion on 23 Jun, 2010 01:46 PM.

23. dirk re-opened this discussion on 23 Jun, 2010 02:08 PM

24. 14 Posted by dirk on 23 Jun, 2010 02:08 PM

    

    So would ya'll consider adding something to the api to allow this to be tested. I bring this up for two reasons - one making sure that the call back is processed correctly is really important because it if it doesn't work - someone who isn't paying could still access the product :( two - if you look at what started this discussion - I found a bug in the system you weren't aware of. Also, in the process of "fixing" bugs the format of the responses changed - for example now if you ask for an invoice and the plan has additional items but the customer doesn't have any - they now show up on the invoice transaction whereas before they didn't. Since I coded to the old behavior - my code no longer works. That's fine since our tests flagged that there was a problem and I contacted you. If I follow your methodology when the code on your end changes I'll have no idea there is a problem until someone complains (or in the case of a non-payer getting access - I'll never know).
    

    • Edit

25. Support Staff 15 Posted by Marc Guyer on 23 Jun, 2010 02:46 PM

    

    someone who isn't paying could still access the product :

    If the customer accesses your app, you can do a lookup at login or otherwise to see if their account is in good standing.

    We fully intend to maintain backward compatibility in all cases. In the cases you mention, we believe we have. Eliminating the possibility of some edge cases is a good thing. You no longer have to be concerned if a customer subscription can be created in an initially declined state. It sounds like you wrote some tests to check this functionality (and presumably some logic). That is regretful. It sounds like you can remove some code. We love to remove code.

    As for testing future failed transactions, we do have plans to enable you to change the current invoice bill date to now, for example, so that you may test future declined transaction callbacks (and for other reasons). However, the recurring engine currently runs transactions only periodically so we also need to change it's behavior. Both features are on our todo list. In the meantime, testing future callbacks must either be done manually through coordination with us or delayed as in waiting until the future transactions run.

    • Edit

26. Marc Guyer closed this discussion on 23 Jun, 2010 02:46 PM.

27. dirk re-opened this discussion on 23 Jun, 2010 03:30 PM

28. 16 Posted by dirk on 23 Jun, 2010 03:30 PM

    

    First - you aren't maintaining backward compatibility on two fronts -

    you eliminated the behavior of delayed errors - without providing a replacement method of functional testing.

    You modified the return values of the invoices - now they actually return data in a different format than they did before - there is now an array of charges in the case that they do not have any additional items.

    I understand that in your mind were just correcting bugs, but you should understand that by "fixing" those bugs you are changing behavior which isn't "backwards compatible". I'm going to go fix the invoice processing code on my end (which I'm fine with), but I'm disappointed that I lose an easy way to know everything works.

    As to your point about looking at their account - that is the problem I'm trying to solve. I'm not worried about an initial declined state (that's easily tested using the real time errors) - I only care about the later decline - for example a card that expires before the second transaction.

    I need to be able to create a customer in real time that has a declined transaction on their account so I can validate that the code can see the declined flag. There doesn't seem to be a way to do that other than waiting for the billing system to process 24 hours later.

    So based on what you said - that used to work - but you fixed it so it doesn't now. You plan at some point in the future to add it but until then it is either a manual (process on your part) or a really long wait on my part. Bummer :(
    

    • Edit

29. 17 Posted by dirk on 24 Jun, 2010 02:49 PM

    

    Good news - after a good night of sleep I figured out a way to solve my problem given the constraints - once I confirm it works - I'll add a note here in th event anyone else has the same problem

    • Edit

30. Support Staff 18 Posted by Marc Guyer on 24 Jun, 2010 08:19 PM

    

    Our intention certainly wasn't to cause any headaches. In fact, in removing the possibility of a customer being created in a declined state was causing headaches for many. It sounds like you were working with that which is unfortunate and we regret that you had to take the time to figure our that weirdness.

    I'm curious to learn what workaround you've come up with... Alternatively, we're willing to fast-track an initially api-only function to override the billing date for the current invoice which would trigger an immediate callback. I'd venture to say that we could have that done and deployed within the next couple of weeks.

    • Edit

31. Marc Guyer closed this discussion on 24 Jun, 2010 08:19 PM.