Carewen-products

[round quarry]

Yes, when you create a Checkout Session you can specify a specific amount in line_items.price_data.unit_amount (see https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-line_items-price_data). This will create an ad-hoc price that will just be used for that Checkout Session

[edgy venture]

Excellent! tyvm for the reference.

So, this allows me to manage discounting and tax my end, and then pass over the final amount for Stripe to process?

Here's the snippet I have so far:

def create_checkout_session(request, booking_form, **kwargs):
    try:
        checkout_session = stripe.checkout.Session.create(
            payment_method_types=[
                'card',
            ],
            line_items=[
                {
                    'price_data.unit_amount': booking_form.instance.stripe_price,
                    'quantity': 1,
                },
            ],
            mode='payment',
            success_url=settings.WHURTHY_DOMAIN + 'event_bookings/',
            cancel_url=settings.WHURTHY_DOMAIN + 'events/templates/events/stripe_cancel.html',
            customer_email=booking_form.instance.event_booked_by.user.email,
        )
    except Exception as e:
        return str(e)

    return redirect(checkout_session.url, code=303)

Django/Python ^

[round quarry]

That's the right idea - but I do think you'll also need to set line_items.price_data.product or line_items.price_data.product_data since the ad-hoc price still needs to be associated with a product. You can either set product to use an already existing Product, or use product_data to pass in additional information about the product and create one specifically for that price

[edgy venture]

Right! 🙂 give me a moment

def create_checkout_session(request, booking_form, **kwargs):
    try:
        checkout_session = stripe.checkout.Session.create(
            payment_method_types=[
                'card',
                # 'acss_debit',
            ],
            line_items=[
                {
                    'price_data.product': booking_form.instance.stripe_product_id,
                    'price_data.unit_amount': booking_form.instance.stripe_price,
                    'quantity': 1,
                },
            ],
            mode='payment',
            success_url=settings.WHURTHY_DOMAIN + 'event_bookings/',
            cancel_url=settings.WHURTHY_DOMAIN + 'events/templates/events/stripe_cancel.html',
            customer_email=booking_form.instance.event_booked_by.user.email,
        )
    except Exception as e:
        return str(e)

    return redirect(checkout_session.url, code=303)```

So, in effect, I'll be creating a new product with the above? Do I even need to be concerned with existing product ids in Stripe with this approach? Or can I pass over a product ID and just associate an ad-hoc price?

In the above, I'm bringing over a product ID. This would be better for longer term accounting reconciliation

[round quarry]

In your above example code wouldn't be creating a new product (since you're passing in an existing Product ID). It would be creating a new Price assocaited with your already created Product.

If you used product_data then yes, that would create a whoel new product

[edgy venture]

Excellent. If product_data has already been used, does Stripe then process a new ad-hoc payment for an already existing product? This may be simpler for the end-user.

[round quarry]

If product_data is used in the creation request then we'd create a new product - we wouln't do any checking to see if it matches an existing product

[edgy venture]

OK. That makes sense. So in effect, using product_data would end up creating a new product for each session, which could get unwieldy. However, using a product_id with unit_amount would ad-hoc payments to be placed against that pre-existing product. That seems much the better approach long term.

[round quarry]

👍 Yup that's how it works! It really depends on your integration - some users have a business model that needs the ad hoc products, but again it all depends on what you need

[edgy venture]

Yes. That makes sense. These end-users would be less likely to need ad hoc products. That should give me what I need to setup a test. Thanks for your time.

[round quarry]

happy to help!