#MarcusStripe-subscription-status

1 messages · Page 1 of 1 (latest)

buoyant widget
#

Hello 👋
Not sure I understand the question fully.

Because of 3D secure, I was told here to set the status of the subscription to ACTIVE once we receive "subscription_create" from the invoice.paid event.
That's correct. This is to make sure that the subscription was paid for prior to going to active state which is where "subscription_create" is important.

WE retrieve the subscription data whenever displayed / used just in time from the api anyway.
So can we simply ignore the "subscription_create" from the invoice paid event and just use the subscription status from the api, "as is"?
I don't understand this piece. Can you expand on this?

onyx merlin
#

SubscriptionCollection subscriptionCollection = Subscription.list(SubscriptionListParams.builder()
.setCustomer(stripeCustomerId)
.build(), requestOptions);

        List<Subscription> subscriptions = subscriptionCollection.getData();
        return subscriptions.get(0);
#

this basically is how wee - just in time - retrieve all data of a customer's subscription, from stripe, just in time.

#

--

#

the subscription object from stripe has a status

#

status enum

Possible values are incomplete, incomplete_expired, trialing, active, past_due, canceled, or unpaid.

#

so in what status is the subscription prior to "subscription_create" received from the invoice paid event?
I assume one of - incomplete, incomplete_expired, past_due, unpaid?

#

And if my assumption is correct - can we SKIP listening to invoice paid "subscription_create" and directly read out the way more accurate subscription status right from the api?

buoyant widget
onyx merlin
#

.setPaymentBehavior(SubscriptionCreateParams.PaymentBehavior.DEFAULT_INCOMPLETE)

#

not sure what this really actualy means.. but that's what we've set

#

.setTrialEnd(endOfTrialTimestamp)

#

we have a 30 day trial... I am just realizing.. wouldnt that mean the invoice paid event would appear 30 days AFTER the subscription was started, anyway?

#

--

#

Use default_incomplete to create Subscriptions with status=incomplete when the first invoice requires payment, otherwise start as active. Subscriptions transition to status=active when successfully confirming the payment intent on the first invoice. This allows simpler management of scenarios where additional user actions are needed to pay a subscription’s invoice. Such as failed payments, SCA regulation, or collecting a mandate for a bank debit payment method. If the payment intent is not confirmed within 23 hours subscriptions transition to status=incomplete_expired, which is a terminal state.

#

--
That anyway is the quite complex explanation of default_incomplete.. don't really get it to be honest.

buoyant widget
#

If you have a trial on the subscription then the first invoice doesn't require a payment, in which case the subscription would move to trialing status

#

With default_incomplete the subscription is only marked as active when the first invoice's PaymentIntent is confirmed (as in the first invoice that requires a payment is paid)

#

which wouldn't be the case with a trial involved

onyx merlin
#

so.... .. does this mean I do need to listen to the invoice paid event subscription_create flag at all.. or not?

#

When I retrieve the subscription status from the api.. I would assume I will directly get trialing?

#

and when it is paid, ACTIVE.

#

and.. if there is a problem with payment, I would probably get one of:
INCOMPLETE("incomplete"),
INCOMPLETE_EXPIRED("incomplete_expired"),
PAST_DUE("past_due"),
UNPAID("unpaid"),

#

right?

#

and CANCELED, if the subscripion was canceled.

buoyant widget
#

I'm not sure we recommended you to listen to invoice.paid event first (I might be missing some context here from your previous threads I guess)

But yes, you can retrieve the status via the API directly.

onyx merlin
#

thanks. And.. what about canceled actually. What if the customer canceled.. but the cancelation is not active yet -

#

in the givne case -it can take 3 subscription periods for the cancelation to be executed

#

would in such a "cancelation about to happen in the far future" situation "ACTIVE" be returned - which I assume - or CANCELED?

#

for the first - how then to know there is a pending cancel ongoing... and for the latter - how to know it is currently still activre?

buoyant widget
onyx merlin
#

ah ok thanks

#

so cancelled really means BYE BYE GONE already

#

And what about those:
INCOMPLETE("incomplete"),
INCOMPLETE_EXPIRED("incomplete_expired"),
PAST_DUE("past_due"),
UNPAID("unpaid"),

Those status are still a bit unclear to me.
Can all those happen in my described scenario?

#

I assume not?

#

and what to do if they do happen?? Cancel the customer, delete the customer? Could this be fixed (by the customer) somehow????

buoyant widget
#

INCOMPLETE("incomplete")
This is when the subscription is created but the first invoice hasn't been paid. Since you have a trail, first invoice doesn't need to be paid. So you won't likely run into this.

INCOMPLETE_EXPIRED("incomplete_expired")
If the first invoice is not paid within 23 hours, the subscription transitions to incomplete_expired. Again with a trial, unlikely to run into this as well

#

PAST_DUE("past_due"),
UNPAID("unpaid"),
This is when either the payment keeps failing in case there's an issue with a payment method OR if you send invoices manually and the customer doesn't pay the invoice. The invoice would move to past_due status after it passes the due date of the invoice

#

More info on the above as docs say

If subscription collection_method=send_invoice it becomes past_due when its invoice is not paid by the due date, and canceled or unpaid if it is still not paid by an additional deadline after that. Note that when a subscription has a status of unpaid, no subsequent invoices will be attempted (invoices will be created, but then immediately automatically closed). After receiving updated payment information from a customer, you may choose to reopen and pay their closed invoices.

onyx merlin
#

--
So PAST_DUE is when payment keeps failing - and UNPAID is only relevant for manual invoices, yes?

buoyant widget
#

yup

onyx merlin
#

ok so past-due will also not happen. But PAST_DUE.

#

thanks