#blkprnt-checkout-customer

1 messages · Page 1 of 1 (latest)

split cragBOT
limber salmon
#

blkprnt-checkout-customer

#

what do you call "my own customer id"? Like some kind of internal reference to your own database?

cerulean flume
#

yea an internal reference to my db

#

for creating a customer portal i need the customer ID used when creating a checkout session

limber salmon
#

Sorry you meant your own id but now you mean another id? I don't really grasp what you mean. Do you mean the Stripe Customer id that looks like cus_123 or something else?

cerulean flume
#

The documentation states "Define an endpoint that creates the customer portal session for your frontend to call. Here CUSTOMER_ID refers to the customer ID created by a Checkout Session that you saved while processing the checkout.session.completed webhook. You can also set a default redirect link for the portal in the Dashboard." Any way i can supply my own CUSTOMER_ID when creating a checkout session?

limber salmon
#

I mean that's the same question with not much more details

#

Stripe generates the Customer id. You have no control over this no. Yes you can pass your own id for reconciliation in metadata for example. But we will create a cus_123 for you and you have to store this information in your own database

cerulean flume
#

okay you answered my question. thank you

#

Also, i was wondering, in the subscription object, what field represents the name of the subscription plan that the user sees?

limber salmon
#

So when the Checkout Session completes, usually you store information about that customer's payment in your database and you'd store the cus_123 with it so that you can use it when creating the Portal Session

cerulean flume
#

that makes sense. also in addition to storing my own id in metadata, i can also store it as the client_reference_id field correct?

#

i'm still having trouble understanding which field is the name of the subscription. I looked through all the fields already. For example, if i name my subscription Yearly Access where is this info

limber salmon
#

I would solely use metadata personally, easier to scale over time, handle in reports and such, but yes you can use client_reference_id if you prefer

#

And a Subscription has no name, that doesn't make sense. A subscription can have multiple separate Prices. Each Price is linked to a parent Product. And a Product has a name.

#

You'll want to read about the Expand feature in our API https://stripe.com/docs/expand that lets you retrieve a Subscription and expand the underlying Product associated to a Subscription's Prices by passing expand: ['items.data.price.product] and then you can access the name for each price via mysub.data[0/1/2/...].price.product.name] for example

cerulean flume
#

I don't see a Metadata field in the CheckoutSessionParams object

#

i think that makes sense. if i am getting events from the webhook, do i still need to use this expand feature?

limber salmon
#

Events won't help. The Product is not expanded by default, so you will have to use the API to retrieve the information and expand. Or just cache this information in your database based on your product catalog

cerulean flume
#

all of that makes sense, thanks

#

for the metadata... when i'm creating a new CheckoutSession the CheckoutSessionParams isn't showing a MetaData object.

limber salmon
#

did you read the doc I sent you to?

# 
  Amount: stripe.Int64(2000),
  Currency: stripe.String("usd"),
}
params.SetSource("tok_visa") // obtained with Stripe.js
params.AddMetadata("order_id", "6735")
charge.New(params)```
#

it has an AddMetadata method, all params classes do

cerulean flume
#

i did, must have missed that. got it now. thank you for all your help 🙏

#

any downsides to using client_reference_id as opposed to the metadata?

limber salmon
#

mostly that this is purely internal to Checkout and you will have to use metadata if you want to pass your own customer id on other objects. So personally I'd just always use metadata

cerulean flume
#

not sure what you mean by that

covert quarry
#

Hi there 👋 taking over, as my colleague needs to step away

I believe what they meant was: since client_reference_id only exists on the Checkout Session object (and metadata exists on virtually every Stripe object) it would be cleaner and less complicated to only use metadata

cerulean flume
#

ahhh i see, so for consistency gotcha

#

had just a couple more questions

#

the CheckoutSessionParam has a field AutomaticTax: wasn't sure if i should set that to True or False. i want the tax to be inclusive

covert quarry
cerulean flume
#

i read through it a couple of times. this part kept confusing me If you don’t want to create your products and prices upfront, you can pass the price_data.tax_behavior and product_data.tax_code parameters in your Checkout session.

#

i already created my products and prices in the dashboard

#

so is the price already inclusive for me

covert quarry
#

That essentially allows you to create Price and Product objects in-line with the Checkout Session. Since you have yours up front, you don't need to do that

cerulean flume
#

so i don't need to include the AutomaticTax field when creating a new checkout session?

covert quarry
#

You should include it if you want tax to be calculated automatically

cerulean flume
#

is tax calculated automatically the same as inclusive tax?

covert quarry
#

I don't understand the question

cerulean flume
#

when you said "if you want tax to be calculated automatically" what does that mean

#

i just want the customer to see the total without an taxes. so inclusive tax

covert quarry
#

If you set your price/product to be inclusive of tax, then it will be inclusive of tax. Automatic tax is just there to tell the Checkout Session whether or not to calculate tax