Best practice for Stripe error handling

[Toshiki Inami]

Hi,

I found the resource about the error handling:

https://stripe.com/docs/api/ruby#errors

Usually in our project, we only rescue Stripe::StripeError like below

def call
   plan = Plan.new(attrs)
   return plan unless plan.valid?
 
   begin
     external_card_plan_service.create(api_attrs)
   rescue Stripe::StripeError => e
     plan.errors[:base] << e.message
     return plan
   end
 
   plan.save
   plan.update(is_active: true, activated_at: Time.now.utc)
   plan
 end

I though this could be enough.

However we could do something;

rescue Stripe::InvalidRequestError, Stripe::AuthenticationError, Stripe::APIConnectionError, Stripe::StripeError => e

Which could be better for the general error handling, and what could we do using the those errors? (maybe emailing, logging or sending notification?)

rescue Stripe::InvalidRequestError => e,  

# do something

rescue Stripe::AuthenticationError => e, 

# do something

rescue Stripe::APIConnectionError => e, 

# do something

Stripe::StripeError => e

# do something

If there are some best practice on it, could you please tell me?

Best,

Toshi

[Jonathan Lomas]

Hi Toshi!

That's a great question!  My general view is that all of these should be logged, but here are my thoughts on the various Stripe errors you might see, and what else you might want to do in each case:

## Stripe::CardError

This is a card-related error that of course only applies for API calls related to Charges and adding Cards to Customers.  You'll want to handle these and provide some feedback to the user to let them know the transaction they were attempting failed so they can address this.  These don't require action on your part, so once you've informed the user and provided them a way to fix this (i.e., entering a different card), I'd just log them and be done with it.

## Stripe::InvalidRequestError

There are three possible causes for this one: your code is providing incorrect or invalid arguments to an API call, your user's (unvalidated) input is incorrect or invalid, or the thing you're trying to retrieve was not found (see below).  The best solution here is to make sure you're validating the input from your users before using it in an API call; once you've done that, you know the only way these will appear is if there's a coding error in your application, so you'll want to log these and also likely send a notification with as much information as possible (via email or otherwise) so the issue can be investigated and fixed.  You'll also want to inform your user that something went wrong, and the transaction wasn't completed.

In addition to the message, you'll also want to pay attention to the HTTP status code for these (which is accessible at `error.http_status`), as you'll find that a '404 not found' error falls into this category.

## Stripe::AuthenticationError

You'll see this error if your API Keys stop working; this usually will only happen when you're initially setting up and provide an invalid API Key string, or if the keys have been rolled, but it's a pretty critical error and if you experience it, you'll want immediate notification of the issue.  You'll also want to inform your user that something went wrong, and the transaction wasn't completed.

## Stripe::RateLimitError

If you're sending too many requests to Stripe's API, you'll end up with one of these.  In most cases you'll just want to log and probably notify; when you get to the point where these start happening, you'll likely want to build in some kind of API call throttling so you don't send too many requests, but that's probably a worry for another day.  You'll also want to inform your user that something went wrong, and the transaction wasn't completed.

## Stripe::APIConnectionError

When your application is unable to connect to Stripe's API, you'll see this error.  If you come upon this error, you should be able to safely retry the request as long as you're using idempotency keys [0] so while you definitely want to log these - and probably notify if you see enough of them - you can likely just use retries to turn them from failures to delays. 

If you're consistently seeing these errors, it's time to investigate the network path between your server(s) and Stripe to see what might be going on.

## Stripe::StripeError

These are Stripe-specific errors that don't fall into any of the above categories.  You'll want to log these, send a notification, and inform your user that something went wrong.

## (regular) Error

Any of these errors are likely caused by something internal to your application, so you'll definitely want to log these and send a notification.

While you could definitely `rescue` each of these error types in each API call, that's a lot of boilerplate code, so another option is to just `rescue` on all of them, and then build a method that can log it, and to a method that will notify if it's the right kind of error, and then finally, if appropriate, provide the user with the appropriate feedback.

Hopefully that'll get you moving forward; if not, or you run into any other integration issues, don't hesitate to let me know!

Cheers,

Jonathan

[0] https://stripe.com/docs/api/ruby#idempotent_requests

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at https://groups.google.com/a/lists.stripe.com/group/api-discuss/.

[Toshiki Inami]

Hi Jonathan,

Thanks for the answer. This is so detailed and I was so surprised.

Every Stripe Errors seem to be inherited from Stripe::Error, but it's always good to handle errors with different operations.

Thank you!

Toshi,

Best

[Jonathan Lomas]

You're very welcome, Toshi!  Don't hesitate to reach out if you run into any more questions or issues!

Cheers!

Jonathan

--