#reyanchougle
compact sage
steel oyster
Yes, you can create as many prices as you would like for a product
stark slate
Is there any limit on number of price records there can be in system?
steel oyster
Nope, you can make as many as you want
stark slate
ok
I am trying to create a session using SessionService in my .net core app.. before doing this, I am manually creating customer, product and price. Is this really needed?
steel oyster
That depends on your needs, you can do all of those or none of them.
- Using a Customer is helpful if you want to save payment method info for later use or if you just want to track multiple payments between a user
- Prices and Products can be created on the fly if you don't want to create them beforehand https://stripe.com/docs/api/checkout/sessions/create?lang=node#create_checkout_session-line_items-price_data
https://stripe.com/docs/api/checkout/sessions/create?lang=node#create_checkout_session-line_items-price_data-product_data
If you are asking about creating many prices, I am guessing that your users will often be paying custom amounts instead of you just having some $5 product that many people subscribe to?
stark slate
Yes you are right. There will be custom amounts for each user
dim fern
Hi 👋
@steel oyster had to step away so I'm taking over.
As my colleague mentioned you can use the line_items.price_data.product_data parameters to create dynamic prices/products for each Checkout Session
dim fern
That is correct
stark slate
ok.. And in this case the Quantity will be 1 right?
dim fern
If that is what you set it to be.
dim fern
You can. You configure Customer record creation with this parameter: https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer_creation
stark slate
ok.. So if I try to send same customer data in multiple session creation then will it throw error or update it or ignore it?
dim fern
What do you mean? "send same customer data". What data are you providing when you create the Checkout Session?
stark slate
Can I share the piece of code here?
stark slate
ok
I first initialize the ApiKey then below code checks if the customer exists. If not then create it:
var customerService = new CustomerService();
var customer = customerService.Search(new CustomerSearchOptions
{
Query = $"email~'{subscription.User.Email}'",
}).FirstOrDefault();
if (customer == null)
{
customer = customerService.Create(new CustomerCreateOptions
{
Name = subscription.User.Name,
Email = subscription.User.Email,
Phone = subscription.User.Mobile
});
}
Below code then checks and creates product:
var productService = new ProductService();
var product = productService.Search(new ProductSearchOptions
{
Query = $"name~'{subscription.Plan.Name}'",
}).FirstOrDefault();
if (product == null)
{
product = productService.Create(new ProductCreateOptions
{
Name = subscription.Plan.Name,
});
}
Below code then creates the main session which I will use to redirect the user using url:
var sessionService = new SessionService();
var session = sessionService.Create(new SessionCreateOptions
{
SuccessUrl = configuration.GetValue<string>("BaseUrl") + "Payment/StripeSuccess",
CancelUrl = configuration.GetValue<string>("BaseUrl") + "Payment/StripeFailed",
LineItems = new List<SessionLineItemOptions>
{
new SessionLineItemOptions
{
Quantity = 1,
PriceData = new SessionLineItemPriceDataOptions
{
Product = product.Id,
UnitAmount = Convert.ToInt64(subscription.Plan.Cost),
Currency = "usd",
Recurring = new SessionLineItemPriceDataRecurringOptions
{
Interval = "year"
}
}
},
},
Mode = "subscription",
Currency = "usd",
Customer = customer.Id,
CustomerEmail = subscription.User.Email
});
I want to implement recurring payment for every year
dim fern
Okay so in that case it looks like your CustomerService will handle looking up a Customer by their email first and then create a new one if you don't find them
All the Checkout Session cares about is the customer.Id to assign the transaction to
stark slate
ok so is it ok if I check the customer and create if not exists and use its id in session creation?
dim fern
Yes, that is recommended
Some users don't bother and they wind up with a bunch of Customer records that all represent the same person. That can get messy
dim fern
Not necessarily. You can create multiple Customer records with the same email
But you can use the email parameter when getting a List of Customers. Then if the API response contains a Customer, you would use that record instead of creating a new Customer: https://stripe.com/docs/api/customers/list#list_customers-email
stark slate
ok
In the above code I am doing this to get the customer if exisst. Is it fine:
var customer = customerService.Search(new CustomerSearchOptions
{
Query = $"email~'{subscription.User.Email}'",
}).FirstOrDefault();
Yes that will work just fine
dim fern
No I think it's looking good
stark slate
ok
So in the success and failed calls what data will I get? How to know for which subscription it has failed
dim fern
I think you should test this flow under various conditions to see what will happen under different circumstances
stark slate
ok.. But what data will I get from the callback to success and failed cases?
dim fern
That depends entirely on where it fails
stark slate
ok but I will get some data right? Is there any json schema of that data?
stark slate
Both success and failure callbacks. I need to know it so that I can update the record at my end
dim fern
If your create call is successful it will return a Checkout Session object: https://stripe.com/docs/api/checkout/sessions/object, if not it will return an error
The stripe-dotnet library has custom objects created for each
stark slate
ok got it..
Do I need to crate the subscription or it will be created when I create session?
dim fern
The Session will create it as a result of successful payment
stark slate
ok got it. Then after that I do not need to worry.. Stripe will do recurring payment right?
dim fern
Yup