Home → Problems →

Edit subscription does not update the credit card details

• Edit

dira

26 Jan, 2011 11:02 PM

I have a customer with the following CC data:

  <ccType>visa</ccType> 
  <ccLastFour>1111</ccLastFour> 
  <ccExpirationDate>2012-03-29T00:00:00+00:00</ccExpirationDate> 

I call the edit subscription API:
https://cheddargetter.com/xml/customers/edit-subscription/productCo...

With the following parameters:
ccFirstName=4&ccLastName=Paying&ccNumber=378282246310005&ccExpMonth=04&ccExpYear=2014&ccCardCode=123&ccExpiration=12%2F2014

The request works, but in the response I have the old credit card data:

  <ccType>visa</ccType>
  <ccLastFour>1111</ccLastFour> 
  <ccExpirationDate>2012-03-29T00:00:00+00:00</ccExpirationDate> 

I mention that this worked on January 11.

1. Support Staff 1 Posted by Marc Guyer on 26 Jan, 2011 11:33 PM

   

   Hi Dira -- That sounds odd. I've turned on some debug logging on your account. Could you please replicate this and note the time? We'd like to simulate it here.

   • Edit

2. 2 Posted by dira on 27 Jan, 2011 12:13 AM

   

   Hi Marc,

   thank you for your fast reply.

   I tried it again at 2011-01-27 00:10:21 UTC, on customer code 78af4227-c541-4618-b31b-91eb07b3d550.

   Thank you!

   • Edit

3. Support Staff 3 Posted by Marc Guyer on 27 Jan, 2011 02:23 PM

   

   Hi Dira -- We're having a bit of difficulty reproducing this in our simulator but we're still trying. Stay tuned.

   • Edit

4. 4 Posted by dira on 27 Jan, 2011 03:25 PM

   

   Thanks Marc.

   I think the problem might be related with the last release. I have an integration test for changing credit card details, and this has been running fine in December, and the last run was on January 11. We haven't changed the payment-related code since, so did not run the tests in the meantime, until yesterday when the test failed. Hope this helps with investigating the problem.

   • Edit

5. Support Staff 5 Posted by Marc Guyer on 27 Jan, 2011 06:05 PM

   

   You're right. We found it. It's an edge case we didn't have a regression test for. We're preparing a patch for deployment now.
   

   • Edit

6. 6 Posted by dira on 27 Jan, 2011 06:52 PM

   

   Great!

   Thanks for your help with this problem.

   • Edit

7. 7 Posted by dira on 28 Jan, 2011 04:32 PM

   

   Hi Marc,

   Please let me know when the fix is deployed, so I can run again the tests. Thanks!

   • Edit

8. Support Staff 8 Posted by Marc Guyer on 28 Jan, 2011 07:31 PM

   

   You should be good to go.

   • Edit

9. 9 Posted by dira on 28 Jan, 2011 07:52 PM

   

   Thanks Marc. I tried again, but it still does not work.

   My last attempt was:
   2011-01-28 19:48:38 UTC
   customer code: 78af4227-c541-4618-b31b-91eb07b3d550
   I tried to update to the CC number: 4012888888881881

   • Edit

10. Support Staff 10 Posted by Marc Guyer on 31 Jan, 2011 02:59 PM

    

    Dira -- Sorry for the difficulty on this. There may be some small nuance specific to your situation. We will work to more accurately replicate your scenario today and get back to you.

    • Edit

11. 11 Posted by dira on 31 Jan, 2011 04:06 PM

    

    Hi Marc,

    It seems that this is a very complicated bug.

    Today I tried using the 'edit customer and subscription' API instead of 'edit subscription'. My automated integration tests failed again. I tested my app from the browser as well, and it did not work.

    Then, I proxied the requests though Charles to give you guys a session recording.

    1) The first request in the session recording below worked normally. I changed the CC from 4111... to another test visa card. As you can see in the log, the change was recorded and I got the new last four digits back, and the expiration date was recorded as well.

    2) I did the same request with another CC number, this time I got the buggy behavior again. The request returned 200, but the CC last four were not changed, nor was the expiration date.

    I did not manage to get the right behavior again, all the subsequent requests with the same template and different CC numbers/expiration dates resulted in the buggy behavior.

    I hope that the session log below will be helpful in investigating the situation.

    I stress again that this behaved normally (consistently) before January 11.

    • session.xml 18.8 KB
    • Edit

12. 12 Posted by joshua on 02 Feb, 2011 04:42 PM

    

    Any updates on this one?

    • Edit

13. Support Staff 13 Posted by Marc Guyer on 02 Feb, 2011 05:06 PM

    

    Hi Joshua/Dira -- Quite a coincidence, I was composing this comment when I received your update request:

    Thanks very much for the extended information! We're pretty sure we've tracked this down now. We were able to replicate the behavior described and now have a successful regression test for that scenario. A patch was released yesterday which should fix the problem for you.

    It seems that this is a very complicated bug.

    Agreed, and a bit embarrassing. Not only was it strange but difficult to track down. Further, it's unusual for us to cause such a problem as we have extensive regression testing including time passage simulations built into the deployment path. Sorry for the hassles.
    

    • Edit

14. 14 Posted by dira on 02 Feb, 2011 05:29 PM

    

    Hi Marc,

    I'm very happy to hear you could reproduce and fix the bug.

    However, trying to run the tests again, I got a SSL error - OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed).

    Is there something we should change on our side to be able to connect to CG again?

    Thank you!

    • Edit

15. Support Staff 15 Posted by Marc Guyer on 02 Feb, 2011 05:43 PM

    

    Hi Dira -- Nothing SSL related has changed here. Our own tests do not show any SSL problems.

    • Edit

16. Support Staff 16 Posted by Marc Guyer on 02 Feb, 2011 05:48 PM

    

    Can you curl?

    curl -vu username:password https://cheddargetter.com/xml/plans/get/productCode/PRODUCT_CODE
    

    Here's a sample output of the handshake:

    * About to connect() to cheddargetter.com port 443 (#0)
    *   Trying 67.23.4.246... connected
    * Connected to cheddargetter.com (67.23.4.246) port 443 (#0)
    * SSLv3, TLS handshake, Client hello (1):
    * SSLv3, TLS handshake, Server hello (2):
    * SSLv3, TLS handshake, CERT (11):
    * SSLv3, TLS handshake, Server key exchange (12):
    * SSLv3, TLS handshake, Server finished (14):
    * SSLv3, TLS handshake, Client key exchange (16):
    * SSLv3, TLS change cipher, Client hello (1):
    * SSLv3, TLS handshake, Finished (20):
    * SSLv3, TLS change cipher, Client hello (1):
    * SSLv3, TLS handshake, Finished (20):
    * SSL connection using DHE-RSA-AES256-SHA
    * Server certificate:
    *    subject: C=US; ST=Indiana; L=Bloomington; O=CheddarGetter LLC; CN=*.cheddargetter.com
    *    start date: 2010-06-07 00:00:00 GMT
    *    expire date: 2011-07-19 23:59:59 GMT
    *    subjectAltName: cheddargetter.com matched
    *    issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert High Assurance CA-3
    *    SSL certificate verify ok.
    

    • Edit

17. 17 Posted by dira on 02 Feb, 2011 07:05 PM

    

    Hi Marc,

    I confirm that both API calls, edit subscription, and edit customer with subscription, now work as expected. (The SSL problem was from the last version of httparty).

    Thanks for your support with this issue!

    • Edit

18. Marc Guyer closed this discussion on 02 Feb, 2011 08:57 PM.

19. joshua re-opened this discussion on 02 Feb, 2011 11:09 PM

20. 18 Posted by joshua on 02 Feb, 2011 11:09 PM

    

    Thanks, this seems to be working now!

    Joshua

    • Edit

21. Dean closed this discussion on 16 Jan, 2013 04:05 PM.