#votsircp-checkout

1 messages ยท Page 1 of 1 (latest)

abstract aurora
#

Hi. generally speaking Checkout is a convenience way to integrate with Stripe, but it has some limitation on its own. You would want to integrate yourself if you want more control over small options here and there

#

And about the legacy code, yes Charge is an old API, and we recommend to use PaymentIntent instead nowsaday

echo laurel
#

i'm just feeling overwhelmed by the amount of options available

#

seems like Checkout would take a huge burden off my dev shoulders

abstract aurora
#

It depends on what you would like to achieve. Normally using Checkout is easier than building by yourself

echo laurel
#

for example, we have a backend function that calculates discounts after the user inputs a discount code. these discounts are implemented by our backend, not on stripe. would we be able to dynamically change the price being charged by Checkout?

abstract aurora
#

Have you considered to map your discounts logic to Stripe's Coupon or promotion code?

#

Or do you prefer to not using our Coupon and Promotion Code object?

echo laurel
#

good question

#

dealing with legacy code is no fun ๐Ÿ˜„

#

to answer your question, i haven't

abstract aurora
#

With a Stripe's Coupon, you can attach it to Stripe Checkout

#

we automatically manage the logic for you

echo laurel
#

right

#

i'm trying to build something new without changing too much of the current system

#

so i'd like to integrate what we have with Checkout

#

not completely sure of the implications of completely rebuilding our discounts api

#

regarding current and old customers, old database data, etc

abstract aurora
#

okie, then what data outcome that your discount api is providing?

#

like, what data structure?

echo laurel
#

input: plan id, discount code
output: price after discount

abstract aurora
#

Is it an one-time discount?

echo laurel
#

hmmm, good question, i think not

#

multiple users can apply the code to their order

#

not sure i understood your question correctly

#

can you clarify please?

#

if you're referring to subscriptions, the discount applies to first payment only

abstract aurora
#

I think that sounds like a Promotion Code more than a Discount

#

yeah

#

I am just imaging, passing the output of price after discount to the Checkout Session should work, no?

echo laurel
#

we have fixed amount discounts, % discounts

#

the users inputs the code and we calculate the final price in the backend

#

and return to frontend

echo laurel
abstract aurora
#

yeah after calculate the final price in the backend, you create a Stripe CheckoutSession with that price. Is that working?

echo laurel
#

like this interaction with the server side before hitting "pay"

abstract aurora
#

ah

echo laurel
#

not sure we're on the same page

abstract aurora
#

you want the user to see the Checkout page

#

and input the code

#

intercept it and manipulate the final price

echo laurel
#

user selects a plan and wants to pay for it, and has a code for a discount

#

there needs to be an input where to insert said code

#

and after inserting the code the price should be updated

narrow flicker
#

then you want promotion codes!

echo laurel
#

then hit submit and proceed with checkout

#

with whatever payment method the client wants

echo laurel
#

my issue is we have built and entire system to generate discounts

abstract aurora
#

yeah

echo laurel
#

it's our legacy code, my colleague built it

#

can we integrate that with Stripe Checkout

#

?

abstract aurora
#

the problem is, you want to control over the promotion configuration

echo laurel
#

i know, it's a nightmare situation

#

not pleased with it myself

#

not sure if i made my point across

#

the user would input the code to calculate the price he needs to pay, and only then proceed to checkout

abstract aurora
#

How many patterns of final price that your system can output?

echo laurel
#

i'm sure we can tell checkout how much to charge

#

i think we have at least 2, % and number

abstract aurora
#

It's very similar to Stripe's Coupon then

echo laurel
#

wait, what do you mean patters of final price?

#

patterns*

abstract aurora
#

sorry, patterns of discount

echo laurel
#

orakaro, i understand that Stripe does all this. but we don't want to completely redo our system

#

i didn't build the current system

abstract aurora
#

yes, I mean, you can try to map from output of your system, to Stripe's Coupon

#

Let's say you have a set of code pre-generated, that your customer can input, correct?

#

You can map them to a set of Stripe'Coupon/Promotion Code

echo laurel
#

our discounts are dynamically generated

abstract aurora
#

Plan Id + Code -> Discount Pattern, correct?

#

What is this plan id? Is it the same for customers?

echo laurel
#

we sell SaaS, we have 3 major plans, each one has monthly/yearly payment options, so total of 6 plans

#

each plan has an id

abstract aurora
#

Can you simplify the call to your system to (Code) -> (Discount Pattern) ?

#

like, will different Plan Ids affect the output Pattern, within a same Code?

#

Okie, let say you can't. To put thing simple, I assume that you have 6 plans, and 10 pre-generated code

#

With each code, running with 6 plans, you should have 6 final prices. The question is, are those 6 final prices relative to the original prices with a fix percent or amount off?

#

If the answer is YES, you can create a Stripe Promotion Code, and map each of your code to a Stripe Promotion Code, then use Checkout

#

if the answer is NO, then you can't use Checkout. You would need to build the UI yourself, dynamically call you legacy system to define the final price

echo laurel
#

there are 6 final prices, but for some reason we're generating different codes mapped to the same repetitive discounts

#

probably for referrals

#

so one code can only be used once

#

ok, no, we can have an infinity of discounts

#

so an infinity of final prices

abstract aurora
#

with same code, 6 plans, still infinity of final prices?

#

I see

echo laurel
#

yeah

#

no

#

let's see

#

we have 6 plans, each one with a different initial price

#

then we have an infinity of codes which produce different final prices when applied to initial price

#

that's all

abstract aurora
#

I know that sense of infinity, but it's infinity of codes. Let's say you have 100, or 1000, it's all predefined, correct?

echo laurel
#

more can be generated

abstract aurora
#

yes

#

the point is, if for each code, result in a same pattern to all 6 plan with 6 different price, then you can sort of map 1:1, from one of your code to one Stripe Promotion Code

#

then no matter how many code you can generate, infinity, you can generate the same amount of Stripe Promotion Code

#

programmatically

#

but problem is, do we have the map 1:1 or not?

echo laurel
#

when you say map, what do you mean exactly?

abstract aurora
#

yes

echo laurel
#

because in my mind i'm talking about an ajax call to the server before hitting checkout

#

with the plan id and discount code, to get the final price

abstract aurora
#

I got that flow. I am suggesting before all of that, you can predefine Stripe Promotion Code based on all of your possible code, and let your customer use that instead of that flow

#

But if you think it's complicated and not worth the effort, just go with the direction of building your own checkout

echo laurel
#

it's not that i think it's complicated, i just haven't understood what you mean ๐Ÿ™‚

#

you mean when an admin creates a new discount using our system, at the same time we create a stripe promotion code which the user can apply using native stripe Checkout feature?

abstract aurora
#

yes

echo laurel
#

i see, i was missing that part

abstract aurora
#

with the condition, that you can figure it out the discount pattern for each of your new discount, across all plan

echo laurel
#

i see

#

what a horrible system haha

#

have discounts on 2 platforms

#

but i understand your solution

#

not your fault we've this legacy code to deal with

abstract aurora
#

Only if the map is possible. If with a random_code an admin created, it resulted in 20% off for one plan but 30% off for another plan, then it's impossible

echo laurel
#

map is possible

#

but for codes created before we did this, it wouldn't work

#

or we'd have to go back and create promotion codes for those

#

not fun

abstract aurora
#

like a batch, but yeah depends on your system

#

Just go for custom checkout flow, in that case

#

Hi @echo laurel I need to run. Hope this gave you some material to decide. Feel free to come chat with other Stripe ppl if you have other questions!

echo laurel
#

cheers orakaro, you were awesome

#

great job, thank you

abstract aurora
#

good luck!