Error Handling - Subsequent charging failures
I really liked your KB article on Error Simulation and am
planning on trying some out.
http://support.cheddargetter.com/kb/api-8/error-simulation
I was wondering if you have a way of making the first payment
from a card work, but subsequent payments fail?
Our application is going to immediately charge the provided card
details, and then a another charge 1 week/month later. I'm wanting
to test what happens with when the card is valid initially, but
when we charge it later it has expired, has insufficient funds or
fails for some other reason.
Are there special zipcodes I could put in that would make this
happen? Would I be better to provide 'good' details to start with
and then go in and edit the zipcode to one that will generate a
failure next time (am I able to edit card details?).
Mope you can help.
Martin.
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
1 Posted by mphillips on 02 Apr, 2012 04:34 PM
As a further question - which of the AUXCODES are appropriate for Delayed vs Real-time errors? e.g. which of the errors would get generated at validatation time, and which would need an actual charge to generate them?
For example, I'm guessing that an actual charge has to be made to get
6003 The transaction was declined due to insufficient funds
but for the following two, I'm not sure if they would come of the system at validation time, or on charge... Any thoughts ?
5001 Credit card number is invalid The credit card number passed all of the sofisticated validation that CG puts it through but the gateway still doesn't like it.
6004 Credit card number is invalid The same as 5001 except this is a declined condition rather than an error condition
Support Staff 2 Posted by Marc Guyer on 02 Apr, 2012 07:04 PM
Realtime errors are simulated with special zip codes which start with a zero (0). Delayed errors are simulated with zips which start with a 9. That's all documented in the article you referenced. This article, which is referenced in that doc, explains the error codes.
There are no error conditions which are specific to real-time vs delayed errors. For example, a 6003 could occur at either time. 5001 could happen either time. 6004 could happen either time.
3 Posted by mphillips on 03 Apr, 2012 10:40 AM
I may have worded my question badly, but I can't work out how an 'insufficient funds' error could be generated during card validation in a real environment. Surely we would need to be making a charge to the card for an 'insufficient funds' error to occur?
I suppose I'm assuming that card validation and card charging are separate steps. That card validation happens when we initially register the card details with CG, even if we don't charge the card at that point.
Support Staff 4 Posted by Marc Guyer on 03 Apr, 2012 01:41 PM
When CG does a card validation, an authorization is executed against the card. This is almost like a full transaction but it will not settle (money doesn't move). So, you can immediately get a decline for insufficient funds.
5 Posted by mphillips on 03 Apr, 2012 02:10 PM
Aha! Ok - that makes sense - thanks :-)
So, any thoughts on the initial question about getting the first transaction to work, but subsequent transactions to fail? I'm guessing I will need to log in and change the details to get that to happen.
Support Staff 6 Posted by Marc Guyer on 03 Apr, 2012 06:49 PM
Error simulation codes which start with a zero will trigger an error/decline at the validation stage. Simulation codes starting with a 9 will cause an error/decline in the first transaction after the customer is successfully created.
mphillips closed this discussion on 05 Apr, 2012 07:59 AM.