Immediate notification of declined setup charge
If my plan has a setup charge, the card is charged immediately.
If the charge is declined, does CG immediately report that back in
the response to calling API url
/customers/new/productCode/MY_PRODUCT_CODE?
Similarly, what about if a user changes the card in the middle
of a subscription? Will a call to
/customers/edit/productCode/MY_PRODUCT_CODE/code/MY_CUSTOMER_CODE
or
/customers/edit-subscription/productCode/MY_PRODUCT_CODE/code/MY_CUSTOMER_CODE
return a response code of some kind indicating the card was
rejected?
Discussions are closed to public comments.
If you need help with Cheddar please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Marc Guyer on 14 Oct, 2009 02:47 PM
Good questions. Yes, this is the intention thought at this time, a declined setup charge does not return an error when initiated via the API. We are currently working to improve the error reporting and are working with Authorize.Net to determine a reliable way to test this functionality.
Marc Guyer closed this discussion on 14 Oct, 2009 02:47 PM.
Frank Koehl re-opened this discussion on 14 Oct, 2009 05:19 PM
2 Posted by Frank Koehl on 14 Oct, 2009 05:19 PM
So...what do I do right now? I've got to stop bad transactions up front, so I need some kind of yes/no response.
Should I implement the Auth.net AIM API on my end and run an authorize transaction to see if they information provided is legit?
Support Staff 3 Posted by Marc Guyer on 14 Oct, 2009 05:50 PM
Hmm... I misunderstood your question, or rather did not provide enough information to answer it.
There are two payment validation actions taking place when a new subscription is created with a setup fee. The first, and this occurs every time a subscription is created or updated with credit card information, is a basic authorization of the card. Authorize.Net authorizes the cc with a $0.01 transaction. If a customer's card does not pass this authorization step, an error is returned via the API. The second, in the case of a setup fee, is the actual transaction for the setup fee. I think it's 99.9% safe to assume that the only reason why this transaction would fail would be for an insufficient credit balance to support the amount of the transaction. In this case, the error is not returned via the API in the way we intend it to be returned.
In the second case, you will receive a successful response with customer xml. In that xml is a subscription node with a setup fee invoice. If that invoice does not contain an 'approved' transaction, then the setup fee transaction was not successful. At this time, there isn't a way to determine with certainty via the API why the transaction failed.
4 Posted by Frank Koehl on 14 Oct, 2009 06:53 PM
Alright, so where rubber meets the road, I need to look at the following value...
`
`
That will be 'approved' or 'declined', and that won't change with your changes, we'll simply (hopefully) be getting more information.
Support Staff 5 Posted by Marc Guyer on 15 Oct, 2009 10:19 PM
That looks right.
Support Staff 6 Posted by Marc Guyer on 22 Oct, 2009 06:25 PM
Frank -- Error reporting is now more consistent and errors are consumable by standard humans. Error logs are now exposed in a report under the (now) "Reports" tab. You can even simulate gateway errors:
Change Log
Error Handling
Error Simulation
Marc Guyer closed this discussion on 22 Oct, 2009 06:25 PM.
Support Staff 7 Posted by Marc Guyer on 22 Oct, 2009 08:48 PM
Oh, yeah -- Some of the error reporting enhancements require the latest version of the PHP client. That's ready for download as well: http://github.com/marcguyer/cheddargetter-client-php
Frank Koehl re-opened this discussion on 22 Oct, 2009 09:13 PM
8 Posted by Frank Koehl on 22 Oct, 2009 09:13 PM
I'll get to playing with all this stuff tomorrow. On the surface, looks like I can file it all under "awesome."
9 Posted by Frank Koehl on 22 Oct, 2009 09:44 PM
FYI the download link on Git Hub is not grabbing the latest version of the repo. The download I receive doesn't have the changes laid out in the commit log.
Support Staff 10 Posted by Marc Guyer on 22 Oct, 2009 10:04 PM
Good to hear. We think so too.
The latest commit should be "Improved Response_Exception". Are you using
git pullor are you downloading it raw? I just tried a straight download and didn't get the latest code either. Github fail. I'll keep looking into it.Support Staff 11 Posted by Marc Guyer on 22 Oct, 2009 10:19 PM
Yup -- looks like a cacheing issue that they've seen before. I've filed a report here: http://support.github.com/discussions/repos/1774-download-does-not-contain-latest-commit
Support Staff 12 Posted by Marc Guyer on 22 Oct, 2009 10:22 PM
Wow -- that was fast. They've solved it but I had to clear my cache as well.
Marc Guyer closed this discussion on 22 Oct, 2009 10:22 PM.
Frank Koehl re-opened this discussion on 22 Oct, 2009 11:38 PM
13 Posted by Frank Koehl on 22 Oct, 2009 11:38 PM
Cleared cache, got latest version. Thanks!
14 Posted by Frank Koehl on 29 Oct, 2009 05:40 PM
Can I see a list of all possible AuxCode values for 412 errors?
Support Staff 15 Posted by Marc Guyer on 29 Oct, 2009 06:28 PM
Hmmm... That's not easy. The list would be extremely long. A 412 should be a fatal error in your app. In other words, your app should be handling all of the validation necessary. Many are easy: required fields, string length limitations, integers, etc. Email address and credit card number are a bit more involved. We use a regex for email address and then make sure that the hostname is a valid MX. For credit card number, we use the standard Luhn checksum. More specifically, we use the Zend Framework validators, Zend_Validate_EmailAddress along with Zend_Validate_Hostname for email and Zend_Validate_Ccnum for the credit card number.
Validation required for each field is available in the API reference
16 Posted by Frank Koehl on 29 Oct, 2009 07:31 PM
That's all I needed to hear. As long as it's possible for me to completely eliminate these errors with my own error checking, I'm happy.
Support Staff 17 Posted by Marc Guyer on 29 Oct, 2009 08:06 PM
Good to hear. It definitely is possible. The main sticking points are email and ccnum. You can fall back on CG for those if you really need to. The codes for those are:
Marc Guyer closed this discussion on 29 Oct, 2009 08:06 PM.
Frank Koehl re-opened this discussion on 30 Oct, 2009 12:23 AM
18 Posted by Frank Koehl on 30 Oct, 2009 12:23 AM
Good stuff! Can you elaborate on what these two errors mean:
Support Staff 19 Posted by Marc Guyer on 30 Oct, 2009 03:34 PM
I'm not sure. We just consider them all to mean invalid address in general.
Marc Guyer closed this discussion on 30 Oct, 2009 03:34 PM.
Frank Koehl re-opened this discussion on 30 Oct, 2009 03:56 PM
20 Posted by Frank Koehl on 30 Oct, 2009 03:56 PM
Obviously there's something wrong with the address, I get that.
However if you're going to go to the trouble of specifying the different error codes for different situations, obviously they have meaning. I just wanted to know what situation occurs to have these two errors pop up (the others were obvious), so that I can tailor my error reporting if necessary.
Support Staff 21 Posted by Marc Guyer on 30 Oct, 2009 07:57 PM
emailAddressInvalidLocalPart, emailAddressDotAtom, emailAddressQuotedString are all related to the local part. DotAtom and QuotedString both mean that there are illegal characters in the local part. It seems that InvalidLocalPart is thrown in for good measure, presumably to make the other two error messages a little clearer.
You can read the code of Zend_Validate_EmailAddress here. Lines 213-235.
Marc Guyer closed this discussion on 30 Oct, 2009 07:57 PM.