#djc
boreal otter
winter yoke
hi! what sort of metadata exactly? metadata in the API at least is not customer-visible
misty siren
we have a domain registrar business, so we sell yearly subscription for a particular domain
more context:
We want to expose the domain a subscription is related to at the subscription and generated invoices.
What we currently do:
We use CheckoutSessions using price_data and product_data to create inline prices and inline products.
Problems with that approach are that inline products cannot be reused, e.g., in the case of moving a subscription for a domain to a different customer. You cannot create new subscriptions using IDs of inline prices or inline products, nor can you create new inline prices or products using the API.
Thus, we need to use a single Domain Registration product. But using this, it is hard to relay the related domain to the user paying the invoice.
Other options to fulfill the needs:
- Use custom fields to add a domain reference to the generated invoice (PDF only). This is shown at the top of the PDF. This is not shown on the payment page for an invoice as far as I can tell.
- Using the webhook to modify the invoice item description before finalizing the invoice. This way the domain is visible at both places.
Ideally, we should be able to set a sub-description for products on a per-subscription basis. This should be customer facing and shown below the product description. I guess this would be one of the ideal solutions to be able to support subscriptions with multiple products.
Alternatively, subscriptions have a description field. As far as I can see, this is only shown at the dashboard but not printed at invoices. If we stick to one product per subscription, it would be nice if this would be printed somewhere on the invoice.
winter yoke
yep there's not really any perfect solution here
I suppose you could create a new Product/Price for the specific domain(the description on the Product is what is shown in the Checkout page and in invoice line items) before creating the CheckoutSession with it
misty siren
that would get pretty messy
in many ways the 1-year .com domain is a generic product
which we'd like to manage as such (for example, on a price change)
winter yoke
you could also pre-create a Customer object with certain custom fields(https://stripe.com/docs/api/customers/create#create_customer-invoice_settings-custom_fields) and pass that customer into Checkout
misty siren
but a customer might have multiple domains (in fact, many do)
and this wouldn't give us the option to show a different domain on different invoices for the same customer (short of temporarily changing the Customer object whenever we want to show/generate an invoice), right?
winter yoke
correct