Re: [stripe-api-discuss] Subscription failed payments

[Jamin Benjamin]

About testing situations:  You can find a bunch of CC numbers on the following linked page that will cause various situations.  

https://stripe.com/docs/testing

On Sun, Feb 15, 2015 at 3:26 AM, Simon Canning <cannin...@gmail.com> wrote:

Hi,

I am coding a MVC 5 internet application and am choosing to use Stripe as the payment service.

My question is this: After I have added a Subscription to a Customer, how can I check if this Subscription is now not active, because of a failed payment? Is there a specific attribute in the Customer object that holds this value? Is there an attribute in another object that holds this value? Also, how can I test this situation? By that, I mean, I wish for a subscription payment to fail, so that I can write some code to handle this situation.

Thanks in advance.

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at http://groups.google.com/a/lists.stripe.com/group/api-discuss/.

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Jamin Benjamin]

These fuzzy questions are the reason I started moving responsibility from Stripe into my own application as much as I could.  What you are trying to do (nothing wrong with it) let's the responsibility of subscript, charging, suspending, cancelling....etc...rest in Stripe application's scope.  It wouldn't take much to write your own methods to handle subscriptions in-house.  

In mine (and I'm not necessarily recommending this as correct) I wrote a little background windows service that watches for upcoming subscriptions due (among quite a few  other things it does)  When the datetime hits, the service kicks out a worker thread that does the renewal process.

The end result, using your question as a case: I would always know the state of a customer's subscription...even if Stripe was completely offline!  In-house data...I love it.  I got trust issues when it come to inbound data I guess :)

[Matthew Arkin]

 Jamin pointed to the link on testing cards, a free trial (even for just a minute) with the card that attaches but decline is quite useful.

A subscription has multiple statuses, trialing, active, past_due, and unpaid. Note, a ton of crazy stuff happens with unpaid subscriptions, so unless you have a really good reason, I recommend sticking to canceling a subscription after the 3 failed attempts as opposed to marking it as unpaid.

When a subscription is up for renewal, Stripe will send you an invoice.created webhook. 1 hour later, Stripe will attempt to charge that invoice resulting in an invoice.payment_succecced or invoice.payment_failed. Normally you’ll want to send an email on payment_failed and update your code so that during the next login your customer is prompted to update their card.

After the failed attempt, Stripe will attempt to charge the invoices pursuant to your retry schedule (as set in your account settings), or when you update a customer’s card (customer.card = “tok_”, not customer.cards.add(“tok_)). 

Once its billed successfully you’d get a invoice.payment_succeeded. 

You also get a customer.subscription.updated (status would become past_due) and customer.updated (if they become delinquent) if the payment fails and again when it unfails, but in most cases people listen to the invoice.* web hooks.

And Pete Keen has a great guide on all the hooks you can listen to and which series of events cause which webhooks: https://www.masteringmodernpayments.com/stripe-webhook-event-cheatsheet

--

Matt Arkin

Kollective Solutions

http://kollective.it

http://mattarkin.com