#Dooing-endofinterval-payment

1 messages · Page 1 of 1 (latest)

upbeat peak
#

Hello, metered subscriptions work that way, they're post-paid, that would work for you. You'd create a metered Subscription with a trial. If you need to cancel in the middle of a period, you'd set cancel_at_period_end param to cancel but at the end of the interval.

inland belfry
#

?

#

Are you saying, there is no way for a regular su bscription to be post pod?

#

paid

#

I wa assuming this was just configurable

#

and trial... I am unsure.. I guess this is not a trial.. since the first month WOULD be paid. Just only if the month is finished up

upbeat peak
#

a regular (non metered) sub is prepaid.

#

yeah if the first month is paid, just at the end, then that is just a metered subscription really

inland belfry
#

and if th subscription stops before, will the subscription still be charged?

#

I mean, do I need to stop the charge or will it just not happen?

upbeat peak
inland belfry
#

yeah but will this have to be paid?

#

the idea is, that, for the FIRST cycle, there is no invoice, IF the subscription is canceld before end of period

#

but PAID otherwise

#

like a "100% satistfaction or no charge"

#

which is not a trial

#
  1. Metered subscriptions.. that is a total different model as I checked... usage based... and usage needs to be reported.
    but does this mean, that one month I can use lets say "100 liter of milk" and pay 100 USD, and next month use "50 liters of milk" and pay only half the price... is that flexible as buying gas at a petrol station?
#

So if I want this to be fixed like for normal subscriptions.. would I have to simulate a normal subscription in the way of statically reporting the same number of earch customer subscribed to a metered subscription?

upbeat peak
#

the idea is, that, for the FIRST cycle, there is no invoice, IF the subscription is canceld before end of period
doesn't need to be paid, you can void that Invoice

but does this mean, that one month I can use lets say "100 liter of milk" and pay 100 USD, and next month use "50 liters of milk" and pay only half the price... is that flexible as buying gas at a petrol station?
yes

would I have to simulate a normal subscription in the way of statically reporting the same number of earch customer subscribed to a metered subscription?
could you rephrase? I didn't understand

inland belfry
#

well, my customer just wants subscriptions with a fixed set of features, not really metered.. so if I have to use metered subscriptions for post paid.. I would have to simulate the same kind of usage / customer / period, by reporting the same usage, every month, I assume?

#

and that was just one part of the question.

#

--
Is it possible, with metered subscription or whatever subscriptions, to say the customer pays at the end of the subscription, but, for the first subscription cycle, does NOT pay, if canceled before th end of the period.

#

helloo?

upbeat peak
#

I would have to simulate the same kind of usage / customer / period, by reporting the same usage, every month, I assume?
correct, you have to simulate that, metered is the only way to do post paid billing

#

customer pays at the end of the subscription, but, for the first subscription cycle, does NOT pay, if canceled before th end of the period.
if you cancel in the first interval, and there was no usage reported then the Subscription immediately cancels

inland belfry
#

I see. thanks.

#

Oh.. something else...
I want to create the subscription with as little as possible steps, but with 3d Secure in place.
MY current understanding is, I need to - create a payment card from the client / frontend. Then send the payment ID to the backend, then create a customer, and make the credit card the default card for this customer - then create a subscription with the customer, and then send back a secret from the subscription creation so that the frontend / client can confirm the payment card creation and so that stripe can connect the payment card to the given customer.
__

#

is that flow like that correct?

terse lance
#

It works but it's not the recommended flow and hasn't been for well over a year.
Instead we expect you to
1/ Create a Customer.
2/ Create a Subscription with default_incomplete and expand the underlying Invoice's PaymentIntent to get to the client_secret
3/ Client-side, confirm that PaymentIntent

inland belfry
#

? but isnt that what I just said more or less?

#

I dont understand relaly the differences

#

so the whole flow has to be started by the client / frontend. If they dont ask for the credit card.. how would the client / frontend know that the customer is ready to buy the subscription??

#

so in your flow of 1-3.. who sends the credit card details - when - to stripe. I would assume this happens in 0) - before your step 1)

#

and then your flow is identical to mine IMHO

terse lance
#

I mean it looks similar but it is completely different. I know you think it's the same. But it's not. I work for Stripe and I know those APIs and products inside out.
Your flow works okay for card payments. It doesn't work for many other payment methods that require to know how much to pay before you can do anything.
It's also impossible to use PaymentElement to collect card details without a PaymentIntent.

So really what I outlined is what we recommend. When someone is ready to pay and they click on your pricing plan for example, you do a request to your server and start the process I outlined.

inland belfry
#

I think you do not get my point / question

#

Please answer:
who in your flow of 1-3.. who sends the credit card details - when - to stripe

#

clienty or backend?

#

when?

terse lance
#

3/ Client-side, confirm that PaymentIntent

#

that flow collects card details and send those to Stripe client-side while confirming the underlying PaymentIntent. That's how our API has worked for multiple years

inland belfry
#

so that means, the backend will create a customer and subscription, without knowing if it will ever be started with credit card details?

#

who will clean up those hanging stripe objects?

#

--
SubscriptionCreateParams subCreateParams = SubscriptionCreateParams.builder()
.addItem(SubscriptionCreateParams.Item.builder()
.setPrice(stripePriceId)
.build())
.setCustomer(stripeCustomerId)
.setTrialEnd(endOfTrialTimestamp)
.setPaymentSettings(SubscriptionCreateParams.PaymentSettings.builder()
.setSaveDefaultPaymentMethod(SubscriptionCreateParams.PaymentSettings.SaveDefaultPaymentMethod.ON_SUBSCRIPTION)
.build())

            .addExpand("latest_invoice.payment_intent")
            .addExpand("pending_setup_intent")
            .build();

        Subscription subscription = Subscription.create(subCreateParams);

        SetupIntent pendingSetupIntentObject = subscription.getPendingSetupIntentObject();

        String clientSecret;
        if (pendingSetupIntentObject != null) {
            clientSecret = pendingSetupIntentObject.getClientSecret();
        } else {
            clientSecret = subscription.getLatestInvoiceObject()
                .getPaymentIntentObject()
                .getClientSecret();
        }
#

this is the recommended code I received last week from Tarzan, by the way.

#

There is no notion of "default_incomplete" anywhere 😦

#
  1. so that means, the backend will create a customer and subscription, without knowing if it will ever be started with credit card details?
    who will clean up those hanging stripe objects?
  2. Where to set "default_incomplete" and what does it actuallty do?
terse lance
#

so that means, the backend will create a customer and subscription, without knowing if it will ever be started with credit card details?
Yes, which is the only way to do it for most non-card payment methods. Also helps with metrics, MRR, revenue recovery, etc.

terse lance
#
  1. Where to set "default_incomplete" and what does it actuallty do?
    Please do try and take some time to read our docs. I've given you a lot, it's all in our canonical example https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements
    For example step 5 https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements#create-subscription shows exactly where to set default_incomplete in all languages .setPaymentBehavior(SubscriptionCreateParams.PaymentBehavior.DEFAULT_INCOMPLETE)
#

yeah I think tarzan gave you almost everything but forgot that line

inland belfry
#

So I still need to read and understand about default incomplete.. but that apart-
Does that mean that, if a customer wants to buy a subscription, I'd need t check in my backend / with stripe, if there is already a hanging subscrption within the 24 hours to continue that?

terse lance
#

Yes, which is a good thing to do overall to track your customer attempts and over time improve your ability to do retention or convert them

inland belfry
#

regaerdind default imcomplete - this seems to be a fix for an issue I had pointed out 1-2 years ago - that subscriptions could start too early. So it seems, this will set the subscription as INACTIVE, and then, at least I assume, once the payment is confirmed with the secret key from the frontend, that will switch payment and subscription on in paralle, in sync at the same timestamp, yes?

terse lance
#

this seems to be a fix for an issue I had pointed out 1-2 years ago - that subscriptions could start too early.
not really. At least that's not why we did this. It's to allow payment methods that require a clear amount to be confirmed or require a next action like doing 3D Secure or approving on a partner's website

#

then, at least I assume, once the payment is confirmed with the secret key from the frontend, that will switch payment and subscription on in paralle, in sync at the same timestamp, yes?
well the subscription would be active, but the period won't change, it's still from subscription creation.

terse lance
#

Does that make sense overall?