#Yul

1 messages · Page 1 of 1 (latest)

fresh canyonBOT
next hedge
#

Hello again 👋
The ideal solution here would be listen to webhook events
Can you specify what exactly are you trying to keep in sync?

devout hedge
#

You again! I'm doubting your approach. The thing is that I can't see anywhere in the docs that you should create customer before checkout session.

#

Your approach was:
1/ Create a customer before creating the subscription and store their customer ID in local database
2/ Listen for subscription related webhook events
3/ When I receive invoice.paid , I'll look at the associated customer ID and look for the same in my local database
4/ Once I find them, I'll provision access.

next hedge
#

You were asking about a subscription, a subscription needs a customer.
You never mentioned that some of them won't have a subscription!

devout hedge
#

yeah

#

Everyone must first create an account and only after creating account they can choose to add a subscription or not...

#

Theres also some other params beside "customer" in the checkout create:
"customer_creation": null,
"customer_details": {
"address": null,
"email": "example@example.com",
"name": null,
"phone": null,
"tax_exempt": "none",
"tax_ids": null
},
"customer_email": null,

if I don't add any myself I kinda let everything to handle about customer to stripe.... And if I add only customer then I kinda mess up with the customer info.

#

Also, what about subscription renewal? Ican handle it with 'invoice.paid' too?

#

Me, personally, I would've passed my local customer id in the session crete metadata and upon receiving webhook, bim bam boom bam! I have my local customer ID and price_ID ... I can upgrade subscription

#

But will I have this metadata on subscription renew?

next hedge
#

Customer information doesn't change on renewal right?
I believe you're confusing two things together. Are you trying to keep the customer in sync OR the subscription?

#

Think of these as separate objects

#

Customer information doesn't change on renewal, subscription's status might (if let's say the payment fails)

devout hedge
#

customer in sync

#

I think

devout hedge
next hedge
#

In that case, all you have to do is listen for customer.* webhook events.
When anything about a customer changes on Stripe, we will send out webhook events for that.

devout hedge
next hedge
#

for subscriptions we have customer.subscription.* events

devout hedge
#

I actually see another approach which a like the most... For all the customers on my website create a stripe customer............... And give every customer in my local DB a cus_xxx ...

This way I will be able to make checkout like in docs. But.. why do I need all these customer in my stripe account which aren't going to pay anything anytime? ... Like, maybe 2% of them are going to pay something

#

Your docs are meant like all the customers on my app are going to pay for subscription! But thats not the case..

next hedge
#

It goes back to your app design

Everyone must first create an account and only after creating account they can choose to add a subscription or not...

devout hedge
#

I can create a 0 eur/year subscription and add these customers to this subscription, but isn't it just dum ?

devout hedge
#

Everyone must first create an account in my local db*

next hedge
#

I can create a 0 eur/year subscription and add these customers to this subscription, but isn't it just dum ?
You can choose to not create a sub but then you won't be able to upgrade to the paid plans without creating a subscription and you'll have to maintain your own history of the subscription up until the time you create a subscription

devout hedge
#

I understood your thought

#

Can I create a 0 eur/year subscription?

#

Without any card details and so on?

#

You think that this would be the best approach for me?

#

I'll be using subscription: new, renew, downgrade, upgrade, unsub events.

next hedge
#

Yes you can create a 0 eur/year subscription as long as you create a 0 eur product

#

You think that this would be the best approach for me?
Only you can decide that honestly 🙂 Its your app

devout hedge
#

If I pass the cus_ID in the "customer" param in the checkout create - new customer is not goind to be create right?

#

Stripe will use the customer provided in the customer field, right?

#

And if I'm not passing anything in this field, customer is going to be created, right?

next hedge
#

Yes, that's correct

And if I'm not passing anything in this field, customer is going to be created, right?
In subscription mode, yes.

devout hedge
#

Does your cus_ID have a static length? Of 18 characters?

novel raptor
#

At the moment they aren't specified to have a specific length, they might be that length now but could be expanded in future

devout hedge
#

All fields on customer->create are optional. Does it mean I can create customer with no data?

#

I'm using php

novel raptor
#

Correct, you can create a customer without providing any data and then fill out whatever you need later

devout hedge
#

How the subscription downgrading/unsub handled? I will get some money back if I downgrade/unsub?

novel raptor
#

I am checking but I think you can partially refund the user if you want

#

It looks like there isn't an argument for that. You would have to create your own refunds separately for that

devout hedge
#

Yeah, so by default if user cancels or downgrades subscription he will not receive any money back and he will just use it until expiry....

Separate question: can I receive a chargeback on my subscription? For example, if I simply don't want to use it anymore?

#

Actually, it's much more easier for me to cancel immediately or downgrade his subscription if he unsubs or downgrades.... Is it an ok way?

novel raptor
#

You can cancel immediately or set the subscription to cancel at the end of the cycle, either are valid

#

Chargebacks are possible on any transaction. Those come from the user reporting charges to their bank

devout hedge
#

It also seems not so easy to get the price_id from the event object on webhook...

event->data->object->lines->data[0]->price->id

... Is it a legit way? Maybe there's a better way?

#

So, it's going to be

// Handle the event
switch ($event->type) {
    case 'checkout.session.completed':
        $subscription = $event->data->object; // contains a \Stripe\Subscription

        $priceId = $subscription->lines->data[0]->price->id;

for me. On the webhook part

#

oh, actually case 'invoice.paid':

bleak mulch
#

Hi there 👋 jumping in as the server is a bit busy today. Yes, that is the correct way to get to the Price ID from an Event containing an Invoice.

devout hedge
#

\Stripe\Checkout\Session::create([ is the same as $stripe->checkout->sessions->create([?

#

Hi

devout hedge
bleak mulch
#

Was the only outstanding question, or is there something else you're looking for assistance with currently?

devout hedge
#

I don't think so