#cornonthecob

1 messages · Page 1 of 1 (latest)

static axleBOT
spare moon
woven flame
#

ahh okay so ill have to figure out some way to deal with them in the order that I want

#

and in terms of what kind of information is most commonly useful for storing? And if theres some way to pass my user_id from the create checkout session to the other webhooks?

spare moon
#

you would typically use the API to retrieve the relevant object data to write to your DB if you receive an event out of order

#

and in terms of what kind of information is most commonly useful for storing?

This really depends on your application and the information that you want to display or use.

woven flame
#

I noticed if I sent metadata: {} in the session checkout it shows up in the checkout.session.succeeded but not if i use subscriptiondata.metadata: {}...if i do the latter it shows up in the invoice.payment_succeeded so its one or the other...

spare moon
#

And if theres some way to pass my user_id from the create checkout session to the other webhooks?

It sounds like you want the metadata to show up in the corresponding subscription also. If that's the case, you'll want to pass that into this parameter here too : https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-subscription_data-metadata

Stripe API reference – Create a Checkout Session – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

woven flame
woven flame
spare moon
#

we have members that register on our webapp and then there is a subscrioption page for them to simply start paying us monthly...thats about all there is to it, as long as they are paying they will be able to access our venues

I can't really comment on what you need. It's ultimately a product design decision, you're going to need to sit down, look at your requirements for how the app is designed, and list out all the information that you'll need

#

would you say as long as the checkout session succeeds is all i need? or is the invoice also necessary to make sure

this depends - are you only going to accept card payments? Or will you be accepting async payments like example : bank debits?

#

Since it's subcriptions, you can listen for the invoice.paid

#

invoice.paid covers the scenarios where an invoice payment attempt succeeds or an invoice is marked as paid out-of-band.

invoice.payment_succeeded only occurs when an invoice payment attempt succeeds. What this means is that if you mark an invoice as paid out-of-band, you won't get this event

woven flame
#

interestinggg okay, I mean im assuming we'd want credit card payments and bank debits too and probably more I suppose...so it seems like checkout succeeeded and invoice paid could be the two main ones taht I use to update my DB

#

sorry ive only been coding for about a year and ive had to create this whole application on my own with no help so its been quite a struggle having to learn so much so quickly i might be a bit slow understanding these things

spare moon
#

no worries, happy to help with your questions here

woven flame
#

currently where im at is

  • im creating the stripe checkout session okay and users are being redicrected to the checkout page properly

  • when i test 4242 4242 4242 4242 visa card the payment goes through and users are successfully redirected to the success page

  • Im passing client_reference_id into the checkout session so I can have the user_id available so that when I get the checkout_succeeded webhook I can update that user_id to is_subscribed=True

  • I also want to take the stripe customer id and put that in another table associated to the user_id

  • With the invoice.paid webhook I suppose ill need to create another db table to store the invoice id and the invoice URL associate to that stripe user ID or just the user_id

#

sorry i know its a lot but what do you think? Does that sound sensible?

spare moon
#

I think you might want to create the Stripe Customer upfront before the Checkout Session and link that to your user_id before hand

#

this way, everytime that particular user_id creates a Checkout Session, you would pass in the Customer id

woven flame
#

say they cancel the payment and move away from that the checkout session

spare moon
#

to clarify, do your users have to login to your site before making payment?

woven flame
#

yes correct

#

bearer token required

spare moon
#

if you're already saving a user_id, it doesn't seem like too big a stretch to create a Customer for them at the same time too

#

in any case, your original idea is fine too.

woven flame
#

wait with your suggestion, are you saying when the user gets created, to create a stripe customer id for them at the same time?

#

irregardless of if they subscribe or not?

spare moon
#

i guess it would depend on how many of your users eventually go on and pay for a subscription. If only a small percentage does so, then it probably wouldn't make sense

woven flame
#

we're thinking 90% or so will subscribe

#

the only reason for them to register an account will be for them to subscribe to the main product

#

so im guessing theres some stripe function to create a customer

spare moon
woven flame
#

im not very familiar with curl commands...is there some documnetation out there for creating it programmatics in IDE? Im using python

spare moon
#

you can change the programming language in the example

#

click on cURL and there should be a dropdown list

woven flame
#

oh fuck you're right

#

thank you so much

#

the docs were stressing me out because I didnt understand how to use curl in my app haha

#

thats so much better

spare moon
#

this is just my personal opinion, but your logic would possibly be simpler if you created the customer upfront, instead of waiting till the payment succeeds. It's ofc totally fine if you choose to depend on the Checkout Session to create the Customer too and then implement the logic to map that newly created Customer back to your DB

woven flame
woven flame
spare moon
#

You would pass in that Customer's id when creating the Checkout Session. So Stripe can easily identify it's the same person trying to pay the Subscription from that

#

you should try it out

woven flame
#

i think i get it...

#

This is my current session

    session = stripe.checkout.Session.create(
        line_items=[{
            'price_data': {
                'currency': 'nzd',
                'product_data': {
                    'name': 'Oyster Membership',
                },
                'recurring': {
                    'interval': 'month'
                },
                'unit_amount': int(price * 100),
            },
            'quantity': 1,
        }],
        mode='subscription',
        subscription_data={
            'metadata': {
                'user_id': user_id
            }
        },
        client_reference_id=user_id,
        success_url='https://members.oystergroup.org/user/stripe/success',
        cancel_url='https://members.oystergroup.org/user/stripe/cancel',
    )
#

so i can just add

#

customer='<insert_customer_id_from_db>'

spare moon
#

yep

woven flame
#

thats genius

#

wow okay thats a much better workflow

spare moon
#

try creating two checkout sessions, pay both of them, and then look at the customer in the Dashboard, you'll see both payments / subscriptions under that customer

woven flame
#

yeah ive tested it so many times with the same email/customer that thers about 20 subscriptions created from the same person

#

does this mean they'll be paying 20 times every month

spare moon
#

probably 😆

woven flame
#

oh actually

#

they're all different customer ids

#

so they're all different people with the same name and email

spare moon
#

ah, then maybe try with the same customer id and you'll see what i mean

woven flame
#

ooooooh fuck

#

the payment details were saved already

#

it knew who it was

spare moon
#

ah yeah, so https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer

 In subscription mode, the customer’s default payment method will be used if it’s a card, and otherwise the most recent card will be used. A valid billing address, billing name and billing email are required on the payment method for Checkout to prefill the customer’s card details.
Stripe API reference – Create a Checkout Session – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

woven flame
#

yeah so it seems to be working

#

and i think this is the right way to do it

#

im looking atthe customer id on the stripe dashboard and now its showing two subscriptions

#

created at differnt times

spare moon
#

makes it easy for you to track

woven flame
#

heck yeah

#

you better be getting paid good for this you've been so helpful

spare moon
#

glad to have been able to help 😁

woven flame
#

okay my new plan is :

  • Run create stripe customer function when user clicks on the create-checkout-session endpoint (I wont create the stripe user immediately when they sign up to reduce wasted db entries)

  • from there I can extract the customer_id from that user and pass it into the stripe checkout session create function

  • when i get the checkout succeeded webhook I can update the user to subscribed in my db

  • when I get the invoice.paid webhook I can add the invoice ID and URL to the db

spare moon
#

yep, sounds good

woven flame
spare moon
#

you're welcome, feel free to reach out again if you run into any problems or have questions

woven flame
spare moon
woven flame
#

oh

#

this actually look way better

#

that way I dont haev to do the cancel membership code myself

spare moon
#

it displays invoices too

woven flame
#

okay im going to do this instead

static axleBOT
woven flame
#

Hi, one question. Im currently setting itup and i was wondering if its possible to have a subscription have the option of yearly and monthly payments. And if they select yearly then they get a 10% discount on the monthly price

#

is this possibel to be done within one subscription proudct or do i need to create two

#

also its quite a lot of code but ive currently done this:

  • create new stripe and also create new subscription and add the customer_id and subscription_id to the database

  • created stripe portal configuration

  • created stripe billing portal session in which ive passed the customer stripe ID and the configuration id

  • I think finally return the session.url to the front end to access

Does this sound about right?

loud silo
#

I'm taking over this thread.

#

Are you creating two subscriptions, one yearly and one monthly for your customer? or just one, either yearly or monthly?

woven flame
#

thats what id like to decide. On my front end they can click on monthly/yearly. If they click monthly it returns $200 to my backend. If they click yearly it sends $180 to my backend.

From there my idea is depending on what the number is, a different product API ID will be registered to their user_id

#

but I guess im curious if it might be easier to just have one subscription_id/product API ID rather than two separate ones

loud silo
woven flame
#

ahh yes ive been checking this out

#

Before I try that out perhaps you could help me understand how the customer portal works?

#

Im trying to get it working by creating the configurations and then passing that config id to the create customer portal session

#

however how does stripe know what the details of the subscription will be?

loud silo
#

Customer portal is for your customer to manage the existing subscriptions and payment methods.
If you are usingt the no-code portal, your customer will receive an OTP through email in order to log in.
If you create the portal session programmatically, the session is short-lived and your customer doesn't need to log in through OTP.

Stripe will know the list of subscriptions based on the customer ID.

woven flame
#

ohh okay

#

so i cant actually get them to subscribe to a product from this customer portal

loud silo
#

Not really, the customer can update the subscription (i.e., change the price, quantity) but they can't subscribe to a new subscription through customer portal

woven flame
#

Okay ive managed to get something working:

#

im using the recommended create_checkout_session....im curious if theres a way to adjust the styling of the page somewhere?

#

It owuld be nice to have a blue background or something that isnt so bright because it makes my eyes burn I feel like im going blind 😦

loud silo
woven flame
#

THanks ive almost got everything set up

#

one last questino is in my data base in storing the subscription_id is this relevant at all ? or is it useful in any way

loud silo
#

It really depends on your use case. Can you tell me why you store the ID?

woven flame
#

hmm im not sure...I actually dont need to reference it at all i suppose I just thought people would want to keep track of it

#

I was going to store the [price][id] so i could know which product the user was subscribed to that might be more useful