#bazylh - Coupons

1 messages ยท Page 1 of 1 (latest)

spare kernel
#

Hi ๐Ÿ‘‹
How are you attempting to use coupons and what kind of Connect accounts are you using?

silver cedar
#

Express accounts currently

#

We are not in production so it could change if needed

#

Our model is we do not take any commission from our customers (other businesses), and they have end users they need to collect payment systems on. We want to be able to allow our customers to create promo codes (% off products) for their end user promotions.

spare kernel
#

And these are for subscriptions?

silver cedar
#

subscriptions and one off payments

spare kernel
#

Or using Checkout Sessions?

silver cedar
#

End users utilize mobile SDK checkout

spare kernel
#

But what Stripe APIs are you using?

#

Before we get too far down that rabbit hole, let me back up and explain that, yes Coupons will work with Express connect accounts.

#

In any situation where coupons would work directly on your account

#

In Express funds flows all payments, customers, coupons are created on the platform account and can be applied during charge creation

silver cedar
#

Even if all the stripe customers and stripe subscriptions are under the connect account?

spare kernel
#

They won't be. That's not how Express accounts work

silver cedar
#

I see. They're all customers under us then? We want coupons per connect account so that one org can't use coupons from another

#

But we still need to be able to end subscriptions and manage refunds ourselves through our dashboard.

spare kernel
silver cedar
#

Yes I have read through this, express seemed the best route

spare kernel
silver cedar
#

Okay, thanks I did not notice that field before

spare kernel
#

But the Coupon record is a kind of "behind-the-scenes" record. These aren't meant to be customer facing. So in that case you will also likely create Promo Codes

silver cedar
#

So we can create a promo code out of coupon correct?

spare kernel
#

Yes, you use the Coupon to specify the actual discount info as well as duration and and what it applies to

#

You specify the coupon when creating the Promo code.

#

You can restrict a Promo code to a single Customer if you wish, as well as restrict to only first time transactions or transactions above a minimum amount

#

In the case of the Connect integration you were describing, you would create Coupon and Promo codes on your account and they would be submitted by users of your mobile SDK

silver cedar
#

Okay thank you

#

Can we apply a discount on a subscription without a promo code?

spare kernel
#

Sure, you can assign the coupon directly when creating a subscription

silver cedar
#

And will that only be the first payment or last the entire subscription

spare kernel
#

That depends on how you created the coupon, specifically the duration parameter. You can do both

silver cedar
#

Gotcha. Thanks

spare kernel
#

For repeating coupons you can even specify how many months it should repeat for

silver cedar
#

So we are calculating the price based on what the context of the service. We have a model for rentals and we have our own parameters for how a business charges their rentals for different products within our system, then charge the user based on the duration and pricing. So there is no Product/Price model for these currently, they are considered Charges in Stripe which we calculate internally. What is the simplest way to give those across the board promotions only owned by one specific org?

spare kernel
#

If you are using the Charges API you cannot apply Coupons or Promotion Codes. In that case your application would need to handle the business logic of deciding what discounts apply where.

silver cedar
#

Gotcha, we will handle that ourselves then. So subscriptions through stripe will require a Price? Does this logic make sense:
When a user creates a subscription that will apply to their end users we will create a new Price under a Product that will be their organization name. So KFC may have a subscription called Labor Day Sale and Summer Fun. KFC would be one product, and will have prices for each valid subscription. If they deleted one on our page we would archive the price. Then, end users would only be able to access the Prices under the business (this being the Product).

#

Then we could also utilize the coupons and promos for this

spare kernel
#

You don't have to use a Price record if that doesn't fit your use case

silver cedar
#

Well we still need a subscription model that can conduct automated payments

spare kernel
#

If you are not, you will need to complete the price_data attribute

#

Which will auto-generate a Price record

silver cedar
#

Oh my god you're legendary

spare kernel
#

It's a lot of data to fill out which is why Price records make sense if your data doesn't change. But if your use case involves very dynamic pricing and such, the price_data property is your solution

silver cedar
#
  customer="cus_4fdAW5ftNQow1a",
  items=[
    {
      "price": "price_H1y51TElsOZjG",
    },
  ],
  expand=["latest_invoice.payment_intent"],
  stripe_account="{{CONNECTED_STRIPE_ACCOUNT_ID}}",
)```
#

Can the stripe_account attribute still be used if price_data is provided

spare kernel
#

You would swap out the price parameter for a price_data dictionary. Both are labeled optional but you need to use one or the other

silver cedar
#

Okay this was perfect!

#

This was actually I think the root of the issue was, we were trying to force price and products when we dont especially need them.

#

this can be closed

spare kernel
#

Okay in that case your applications business logic will handle all the determinations of how much to charge on each subscription then, correct?

silver cedar
#

Yes

spare kernel
#

Perfect, that should work for you.

silver cedar
#

Well, if someone logs in on connect can they refund, change the price, etc. from the panel?

#

We don't expect many customers will interface this way but we want to keep it an option if they want to go a level deeper in payment processing.

spare kernel
#

What is "the panel" in this case?